- From: Getify <getify@gmail.com>
- Date: Tue, 12 Oct 2010 14:13:11 -0500
- 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 this: 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. --Kyle
Received on Tuesday, 12 October 2010 19:13:49 UTC