[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

>> Sorry for repetition, but we can already preload images and CSS and apply 
>> them to the page at an arbitrary point in time. Why wouldn't we want the 
>> same thing for JavaScript?
>
> I think the question is whether you want _more_ than that for JavaScript.
>
> For images, you can preload them and choose when they're shown, but
> _cannot_ choose when they're decoded.
>
> For CSS, you can preload it and choose when it's applied but _cannot_
> generally choose when it's parsed.
>
> For JS, you want to be able to preload it and control when it's executed
> (in the sense that the side-effects it causes become visible).  The
> question is whether control is also needed over exactly when
> side-effect-free preprocessing of the script happens.

Boris-
The spirit of the proposals is NOT to directly control when parsing happens, 
but seeking relief from the current situation, where execution (and thus 
obviously parsing before it) must happen basically right after download 
finishes. To achieve deferral of execution until a desired time, the current 
UA tech forces an author to perform the download of a script at times when 
it's not necessarily most efficient (such as lazy-loading long after the 
keep-alive is past, or the mobile device's radio has powered down).

We simply want to separate download from execution, so that each can happen 
independently, when a performance optimization expert feels its best for 
them to happen.

Furthermore, if implementations, as a first pass, chose to still insist that 
parsing happened right after download, even though execution could be 
controlled and deferred until later, this would IMHO still solve the 
majority use-case ("deferring execution") and would simply leave the 
minority use-case ("performance of parsing") unaddressed.

BUT, and this is the big key, it would provide a clear future path for 
implementors to improve this performance, by them getting smarter about 
putting off parsing until some later time, because it would stretch out 
(possibly significantly) the time window in which a UA has to parse that 
script. Right now, a UA must parse it nearly immediately as its going to 
then execute it right away. In our proposals, the UA would often have a much 
larger window to find the more optimal time to decide.

And in the worst case scenario, where the author asks to execute a script 
before the UA has elected to passively do the parsing, we're no worse off 
than we are currently, because the UA would simply force the parse to happen 
right away, and then execute. Worst case: no worse; Best case: parsing 
happens at a more optimal/idle time.

We're not seeking to directly control when parsing happens, but seeking to 
indirectly affect it (for the positive) by making it so that it's possible 
(now or in the future) that UA's don't have to bog down a device (main UI 
thread or background thread) *right now* with parsing of a script if I as an 
author have clearly indicated (by not marking the script for immediate 
execution) that I intend to defer its execution until *later* (if ever).


--Kyle