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
