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
