[whatwg] Proposal for separating script downloads and execution

[James Robinson]

On Thu, May 26, 2011 at 3:49 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas <nzakas at yahoo-inc.com>
> wrote:
> > I'm a little surprised that this conversation has swooped back around to
> performance and whether or not there's a valid use case here. In addition to
> standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla
> and Chrome teams were also trying to come up with solutions to enable
> preloading of JavaScript. What I was hoping for was a consolidation of the
> efforts rather than a discussion as to whether or not such efforts should
> continue.
>
> The question isn't whether or not such efforts should continue, it's
> whether any features need to be added to web standards to help the
> efforts continue.  This is a web standards discussion list, after all,
> not a list about user JavaScript library development, or browser
> implementation.  If it turns out that the libraries can be developed
> just fine with existing standard features, like perhaps if browsers
> improve <script async> handling, then no further discussion is needed
> here.
>
> > Moving parts of the JavaScript download/execution process doesn't allow
> me to control when that script will be executed, which as I mentioned in a
> previous email, is really the crux of the issue.
>
> So now we're back to the question of, why can't you just wrap all the
> code in a function, put the function in a <script async>, and not
> execute the function until you want the code to execute?  This is
> assuming that future browsers parse/preprocess/whatever <script async>
> on a background thread.
>

This isn't practical if the contents of the <script> are not under the
author's direct control.  For example, an author that wanted to use jquery
would create a <script> tag with the src set to one of the popular jquery
mirrors (to maximize the chance of the resource being cached), but then have
no control over when the script actually evaluated.  It's easy to imagine a
case where the author wants to initiate the network load as soon as possible
but might not need to actually start using the code until some point further
along in the loading sequence, possibly after a simple form of the page is
made visible to the user.

For this use case I think it would be handy to have a way to express "please
download this script but do not start evaluating it until I'm ready".  As a
straw man, what about using the disable attribute?  When the load completes,
if the disabled attribute is set then the script is not evaluated until the
disabled attribute is unset.  After the script evaluates it goes into a
state where the disabled attribute is ignored.  Browsers that ignored this
behavior would evaluate the script sooner than the author might expect, but
it's usually every easy to detect when this is happening and react
appropriately.

- James