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: Wed, 13 Oct 2010 12:58:14 -0500
Message-ID: <DCAEAA7E2F23449883B2D97485AA75BF@spartacus>
To: "public html" <public-html@w3.org>
?>> Yeah, I don't know.  I don't mean to be negative, it just seems like a
>> really obscure feature.  It's tough enough to educate people to use
>> async or defer (and to get them to understand the difference!), and
>> those have massive performance benefits.

I don't see how this is "obscure". The use-case for downloading multiple 
scripts in order (from HTML <script> tags) is clearly demonstrated... in 
fact, constitutes probably well over 90% of all sites on the internet. 
Extending that use case to suggest that dynamic loading (while preserving 
order) for performance reasons is obviously not as widespread (yet), but 
it's by no means obscure. Script loaders have been around for a long time. I 
think LABjs is one of the first to try from a performance perspective to 
exploit various quirks to squeeze more performance out with parallel 
loading, but ordered execution. But even still, LABjs is not particularly 
obscure at this point, especially if you then add RequireJS (getting lots of 
attention lately) and a few other similar loaders.

Moreover, the desire is to provide a consistent and straightforward 
(non-hacky) way to serve the use case, *so that the use case will get more 
attention and use*. That's what my efforts as an advocate for 
performance-minded approaches to coding are focused around. What we clearly 
have is disagreement between browsers, and what I think is a shortcoming of 
the existing spec, and an opportunity for the spec to forward-thinking about 
the clearly rising attention to performance-savvy coding techniques and 
support the use case directly rather than indirectly.

> I think from a user education point of view, I would actually argue
> that keeping scripts ordered is a better solution. Any time you use
> async script you are exposing yourself to race conditions. If scripts
> load with a different speed at a users computer than at yours, then
> you are running the risk that scripts are running in a different order
> than what you have tested with. This could easily happen if all the
> scripts have been cached in your browser, but won't be for a user that
> visits for the first time.
> So any time async scripts are used, that needs a significant amount of
> understanding and care by the developer. This includes if the script
> is async because it was inserted using the DOM.
> So I'd rather that a user that doesn't understand what async and defer
> is *don't* use them, and that they in that case get ordered, non-racy,
> behavior.

+1 on this perspective. I think that makes a lot of sense. Of course, the 
key point is that a developer *in the know* can opt-in to the other behavior 
as desired.


Received on Wednesday, 13 October 2010 17:58:54 UTC

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