[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

> If browsers processed (parsed & compiled) scripts in a background thread
it would mitigate the problem, but not solve it. Suppose I have 100K of
JS I need right now to generate the DOM for the initial page, and I have
another 500K of JS that's only needed if the user clicks on FeatureX.
Assuming there's only one background thread, I want to prioritize the
first 100K of JS on that thread, and not have it blocked by the
unnecessary processing of the second script. Also, I only want to do the
processing on the second script if the user activates the feature. This
is important on mobile now to reduce power consumption but is also
important on desktops as CPUs become more power sensitive and JS
payloads grow.

Steve's made an excellent point here, which I have failed to as succinctly 
state thus far. What you first have to realize is that there are valid 
reasons why you'd want your code to download all at once up front 
(connection keep-alive, mobile radio power state, etc). But once all that 
code is downloaded, there are also valid reasons why some of that code is 
more important (to parse/execute) than other code. The current technology 
gives us no way to distinguish, and to ensure that the device spends its 
time parsing/executing the important stuff while putting off 
parsing/executing the less important stuff.

And to this use-case, the only suggestions thus far have been:
1. change your code so it doesn't have auto-execute side effects (not 
practical)
2. let the UA manage this with background threads (partially useful, but not 
wholly sufficient given our suggested use-cases)
3. wait to download the less important code until its needed (inefficient 
use of connections, etc)

We need a mechanism that allows an author to explicitly state what of the 
downloaded code it wants executed, and when. That's the only practical way 
to fully serve this performance use-case in *today's* current state of 
JavaScript code patterns. It's simply unacceptable that the only way to 
address this valid use-case (without code modification) is through various 
hacky tricks like "cache preloading".


--Kyle