[whatwg] Proposal for separating script downloads and execution

[Aryeh Gregor]

On Thu, May 26, 2011 at 7:04 PM, James Robinson <jamesr at google.com> wrote:
> 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.

And here's a more concrete explanation of my previous use-case:
Suppose I have a website with lots of complicated JavaScript.  Some of
it is needed on page load, some is needed only when the user takes
some action (like clicking some button).  I want the JavaScript that's
not used on page load to not have any noticeable performance impact on
the page until it's actually needed.  At the point that it's needed, I
want it to have already been loaded from the network, but need to be
able to invoke it synchronously when the user clicks the appropriate
button.  <script async> doesn't work, because I can't invoke it
synchronously at a later point.

Also, consider a third possibility: currently, the part of <script
async> that's captured by the first timing in Ian's/Boris' example
(whether it's parsing or compilation or whatever) blocks the main
thread in browsers, even though it's async.  (Right?)  Suppose that
for whatever reason, it wouldn't be easy for implementers to move this
work to a separate thread.  (Boris/James/other implementers: is this
true?)  Then Ian's use case A still needs a solution.

> 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.

Some solution like this seems like it would satisfy all three
use-cases that are still open: Ian's use-case A if browsers can't
parse async scripts in the background, my use-case where you need to
be able to invoke the script synchronously, and your use-case of
third-party scripts.