Re: Executing script-inserted external scripts in insertion order

?> He looked at (some of) the sites listed before and didn't see any
> problems.  Maybe we need to study them in more detail.

I understand that several people have pulled up the sites listed and haven't 
noticed right off the bat the breakage. But this is not a valid assertion 
that such breakage is not (or won't be) occurring. I am going to explain 
here *why* such breakage is guaranteed based on logic. That should be 
superior to observed (or unobserved) breakage unless you happen to be an 
expert on all the JavaScript UX that every site you inspect should have --  
if you are that familiar, such breakage will be obvious, but if you're not 
that familiar, breakage can easily be missed.

I am obviously that familiar with my two sites (flensed.com and 
blog.getify.com), and I have tested them both in Webkit nightly and in FF 
nightly, and I can verify they do in fact break. What breaks in FF for 
instance is that the Twitter feed fails to finish loading.

The breakage observation notwithstanding, there is some undeniable logic 
happening here, and I can definitively state based on how I know LABjs works 
(since I wrote it) what usage will in fact break based on the changes by 
Mozilla and Webkit. The sites listed do have patterns of LABjs usage that 
will break. For instance, to illustrate:

$LAB
.script("foo.js").wait()
.script("bar.js").wait()
.script("http://domain.tld/baz.js").wait()
.script("http://another.tld/blah.js")
.wait(function(){
   // do something
});

This chain represents a pattern that is in use on all 3 of the sites I have 
mentioned in this thread. (there are other examples out there, but these 
should be instructive enough). This chain pattern will now break in both FF 
and Webkit. Here's why:

* FF -- there's a race condition that "baz.js" and "blah.js" will, while 
loading in parallel, execute "as soon as possible", meaning that even though 
the .wait() between "baz" and "blah" expresses that there's dependency that 
necessitates them going in order. LABjs has been relying on the ordered 
execution of such scripts in FF (and Opera), and now that this ordering is 
no longer enforced, a race condition *definitely* exists. This is 
unquestionable.

* Webkit -- neither "baz.js" nor "blah.js" will even be fetched in Webkit 
with the new change, because LABjs will try to "preload" them by using a 
<script> with `type=script/cache`, which Webkit will no longer download (as 
it did previously). It's clear (and again, unquestionable) why that will now 
break in Webkit.


> I believe defer doesn't wait until onload.  It just wants for parsing
> to be finished, which is considerably earlier:
>
> http://www.whatwg.org/specs/web-apps/current-work/#attr-script-defer

I never said "onload", I said "waits on the DOM". So yes, this is waiting on 
`DOMContentLoaded`.

However, it's also important to note that `defer` behavior is *not* defined 
by spec for script-inserted scripts. So an on-demand script loader (doing 
script loading either during page load or later) cannot rely on `defer` for 
the desired behavior.


> Honestly, I'm lost w.r.t. all the proposals.

-------------------------------------------------
OK, so there's lots of confusion because the thread has already gotten very 
long and diverted around several rabbit trails. Let me restate the proposal 
clearly:

1. Extend the behavior of the `async` property to script-inserted scripts 
(currently only spec'd for parser-inserted scripts). This means that 
`async=true` on script-inserted script nodes would load all of them in 
parallel and execute each "as soon as possible". This is basically exactly 
like script-inserted scripts work in IE/Webkit right now. `async=false` on 
script-inserted nodes would load them all in parallel, but preserve 
execution order as insertion-order.

2. It is still up for decision what the default value for the `async` 
property should be for script-inserted scripts. For parser-inserted scripts, 
the default is `false`, obviously. I believe that for compat reasons and for 
feature-test reasons, the default makes more sense to be `true`. This would 
mean that by default, script-inserted script nodes in IE/Webkit would 
continue to behave like they currently do, in addition to FF nightlies. But 
the ordered execution would be available to such scripts if the author 
changed `async` from its default of `true` to `false`.
-------------------------------------------------


--Kyle

Received on Monday, 18 October 2010 05:14:37 UTC