Re: Executing script-inserted external scripts in insertion order

>>> The problem I have with simply speccing that script-inserted external 
script that don't have the async attribute maintain order among themselves 
is that it gives no way for LABjs to prepare for WebKit and IE implementing 
the spec at a later date.

I agree that avoiding UA sniffing or inferences and getting to a point where 
we can feature-detect on this behavior is the best ultimate goal. However, I 
think the stretch of optimism to suggest that quickly Opera, Webkit/Chrome, 
*and* IE will all fall in line is a bit much -- in fact, I think it may be 
quite awhile before we get convergent behavior. Moreover, the older browsers 
will be around for a long time with the divergent behavior. As such, I think 
browser inferences will be the only practical solution for LABjs (and 
related projects) to pragmatically serve all those browsers.

I don't think that introducing a new property/attribute ("ordered") into the 
mix will ensure any sooner convergence of behavior. While looking for 
"ordered" may provide a shorter-term feature-test, the same inference and 
forking behavior will have to be maintained for quite awhile until we have 
full convergence (and older divergent browsers are practically 
insignificant), and thus the feature-test helpfulness will be diminished.

We could just as easily say that feature-test for `async` (and specifically 
its default value, either true or false) is the feature-test for ordered vs. 
non-ordered behavior. This feature-test will fail for awhile, but once we 
eventually have the convergence (and thus inference forking is moot), that 
feature-test will be just as reliable as a feature-test on "ordered". But 
it'll have the added benefit of better symmetry and simplicity. By symmetry, 
I mean that `async` is fully spec'd out to affect script tags in the HTML, 
but it's not spec'd to do anything (AFAIK) to injected scripts behavior --  
so extending its meaning to injected scripts brings them into more 
consistency with each other.


>>> * The time after the future. We should minimize the cruft accumulated as 
>>> a side effect of getting from the present to the future so that it 
>>> doesn't haunt us after we've gotten to the future.

Agreed. I'd say `ordered` might qualify as future cruft if `async` will do.

>>> <jgraham> Doesn't it make more sense to make preserving order the 
>>> default

It makes more sense to a web performance optimization person like me. It's 
the more ideal of the behaviors as compared to the non-preserving order by 
default in IE/Webkit/Chrome. In fact, I always wanted and assumed that the 
most proper (performance-savvy) behavior would be to have order-preservation 
by default, and then turn disable order preservation with `async`.  This 
constitutes a very ideal scenario for script-loaders.

However, I do not know if there are really other compelling use cases for 
the opposite to be default.  For instance, if jQuery is injecting scripts 
and is bothered by some side-effect of them having order preservation, is 
there REALLY a reason that jQuery couldn't just add the `async` property 
(true) to the injected scripts, and thus opt-in to the behavior desired?

Since injected scripts must always be controlled by some script logic that 
is doing the injecting, it would seem either side of the fence could change 
to start setting the property's value to the opposite of its default, and 
thus achieve what they need.

So in that respect, I'm not sure there's a compelling argument for either 
way to be the default. FWIW, I won't live or die by whichever one turns out 
to be the default behavior, as long as the other behavior is still available 
to me by changing the `async` (or some other, I suppose) attribute.

>>> More seriously, it really doesn't make sense to make script-inserted 
>>> external scripts and parser-inserted scripts to maintain order by 
>>> default (probably not at all). Since WebKit and IE taken together have 
>>> non-trivial market share, Web authors can't rely on the stronger 
>>> ordering provided by Opera and Firefox 3.6.

I don't particularly agree that we should bend spec to the larger market 
share. Those browsers aren't enjoying "better performance" on this topic 
because they chose the better behavior -- in fact, the opposite -- but as a 
side-effect of them supporting another non-standard behavior (the 
"text/cache" thing) they are able to keep pace performance-wise while still 
having the full `async` capability (without the property/attribute itself) 
if the script loader simply doesn't go to extra effort to maintain the 
order.

As I've said, from my perspective, the previous behavior for FF (along with 
`aysnc=true/false` on injected scripts being respected to control ordering) 
is the more ideal and defendable behavior. I think that's what should be 
spec'd, and we should try to convince all the browsers why and to come in 
line with it.

>> >> Whether or not we added Henri's proposed opt-in feature, it seems
>> >> like HTML5 should specify the IE/WebKit behavior for unknown type
>> >> attribute, unless there is some compelling reason to go with the
>> >> Gecko behavior.
>> >
>> > There sort of is... The gecko behavior doesn't involve making a
>> > network request for data you then plan to do nothing with, right?
>> > Whereas the IE/Webkit behavior involves doing just that, as far as I
>> > can see.
>>
>> Is it common to use unknown script types on external scripts for
>> purposes other than preloading the script (as these libraries seem to
>> do)? I guess there might be pages with unconditional includes of
>> vbscript, but I don't know how typical this is.

Actually, there is another interesting use case somewhat unrelated to 
performance-oriented script loaders for why the "text/cache" 
fetching/caching behavior is helpful. Some templating techniques, including 
jQuery's templates as recently being released and made more popular, use a 
script node in the HTML with a fake type to store content such as HTML 
templates, which can later be fetched (by `id`) and used by JavaScript for 
presentation purposes.

If the standard were to be extended that fake mime-types (or even, exactly 
"text/cache") should download the contents into the script element (and the 
cache) but not try to automatically parse them, then users of such 
templating tools could load templates from external resources instead of 
inlining them into the markup. This of course has benefits for caching 
(performance), etc.

To be clear, for that use case to be served, not only would the resource 
need to be fetched by the "text/cache" node, but also made available to 
script via the `text` property of the node.

It's also important to note that the `onload` type events must fire 
(reliably) for these "text/cache" loads for that behavior to be useful, 
either to a templating use case OR to the dynamic script loader "preloading" 
use case.

But keep in mind, the "preloading" use case in LABjs has some problems of 
its own (double-loads of resources if cache headers were sent out wrong, 
etc), and is *really* just a hack to get around that IE/Webkit/Chrome don't 
support the more desired behavior from FF/Opera. I wouldn't argue strongly 
for standardization of that behavior (unless from the templating use case 
perspective), and certainly not to the exclusion of getting a 
straightforward fix for "ordering" of injected scripts that avoids the 
hackiness of this solution.

>>> This was my thinking, yes. It's a rather optimistic approach, since it 
>>> assumes we would be able to get sites to update LABjs and RequireJS 
>>> *and* that in the meantime more JS code relying on UA sniffing and 
>>> ordered execution wouldn't crop up.

Agreed, it's possible the problem may get worse before it gets better. But 
at least with this whole situation the level of awareness has been 
significantly raised. We'd have to hope that due diligence was being done by 
any new script solution's author and that they'd find this discussion and 
not willfully violate the forward progress trying to be made. Big hope and 
assumption, I know... but I don't see any other way to justify proceeding 
with short- and long-term fixes.

>>> It may well be worthwhile to consider a pessimistic approach that starts 
>>> with the assumption that Gecko and Opera won't be able to get rid of 
>>> ordered execution of script-inserted external scripts that don't have 
>>> the async attribute and that IE and WebKit won't be able to get rid of 
>>> supporting preloading text/cache scripts.

I'd say from my perspective the pessimistic approach is as I mentioned 
earlier, which is that we'll have practical real-world divergence for quite 
awhile, even well beyond when the spec is amended to address this problem. 
We should then opt for the smallest change to spec that will eventually 
address the needs, and then hope and advocate for newest generation browsers 
to implement that change as soon as possible. Either way, script loaders 
like LABjs aren't going to be able to retire inference-forking code any time 
soon. :/


Kyle Simpson
Getify Solutions
@getify

Received on Monday, 11 October 2010 14:23:21 UTC