W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: Executing script-inserted external scripts in insertion order

From: Getify <getify@gmail.com>
Date: Tue, 12 Oct 2010 14:13:11 -0500
Message-ID: <845E28881EBA4357A8513DAEFEB73EFE@spartacus>
To: "public html" <public-html@w3.org>
?>> It seems like this is already possible using <script onload> (optionally
>> in conjunction with <link rel=prefetch> to make the UA aware that it can
>> start downloading things early)

<link rel=prefetch> is indeed one way that LABjs could be re-written to 
avoid needing to rely on the ordering of scripts. IMHO, it would basically 
be a regression of behavior back toward the hackiness of the "script/cache" 
approach that LABjs uses for IE/Webkit/Chrome. In addition to non-trivially 
complicating LABjs with different behavior (not just a tweak to existing 
behavior but all new behavior to create <link> tags instead of <script> 
tags), it has the added downside that the "script/cache" has, which is that 
it will fail to work correctly for the intended use case if the script is 
not sent out with proper cache headers. We know from experience that a lot 
(I think Steve Souders once estimated 70%) of scripts are served with 
improper cache headers.

Another such hack has been shown (proof-of-concept) by Nicholas Zakas, which 
is using the <object> tag to fetch scripts but not execute them.

"Preloading" (basically, loading all scripts into cache, and then 
sequentially re-loading them from cache to execute) works but is far from 
ideal and has several potential down-sides. It also forces the script loader 
to be more complex to work around what I think should be a directly 
supported behavior (owing to the importance and wide-spread nature of the 
use case).

What I'm hoping from this discussion process with the standards bodies is 
that a straightforward (non-hacky) way be spec'd and implemented that serves 
the use case, not trying to rely on other hacks.

To make sure we're still on the same page, the use-case simply stated is 

Dynamically loading more than one script (at least one of which is from a 
remote domain like a CDN) where there are dependencies that require (at 
least some of) the scripts to execute in a certain order. The desire for 
performance is that these scripts all be able to be downloaded in parallel 
(as much as the browser can achieve), but that their execution order be able 
to be controlled if necessary.

Again, "preloading" as I described above does accomplish a solution (and is 
the only solution for IE/Webkit/Chrome at the moment), but it's far from 
ideal and definitely not what I would hope would become the "standarized" 
answer to the use case.


Received on Tuesday, 12 October 2010 19:13:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:05 UTC