Re: Executing script-inserted external scripts in insertion order

Getify wrote:
> Yes, I agree with this as being the best option. I just want to guard
> against further complicating the (already complicated) issue by
> implementing
> a set of new attributes/features because the train has already left
> the
> station on the `async` feature (FF 3.6).

I didn't suggest "ordered" because of Firefox 3.6 but because async in a reflecting DOM property, so it's false in the absence of a content attribute.

> Yes, sites will
> need
> to keep their LABjs up to date,

In your assessment, would Firefox 4.0 (from the user experience point of view) be able to get away with breaking existing LABjs if there were an update path available for sites to obtain a new version of LABjs that worked with Firefox 4.0? That is, is there a reason to expect enough sites that currently use LABjs and rely on ordered execution to update their LABjs so that users wouldn't be too unhappy about broken sites?

> Also, as far as I can see, all that LABjs needs to do is "sniff" for
> browsers that currently have `async` but who don't yet have the
> ordered
> behavior if its value is `false`. AFAIK, this is only FF3.6 (and FF4
> betas/nightlies), right?

async is present and defaults to false on script-created HTMLScriptElement nodes in Firefox 3.6, in Firefox 4 beta / nightlies and in WebKit nightlies.

> I'm new to this standards body and to
> the process in general, but I feel like both Webkit and Microsoft (with IE9)
> are showing they clearly want to be in line with standards, so the high
> board approach of convincing based on merits of the standard is how I'd
> default to approaching the discussion.

I'm a bit more jaded than that, but if WebKit and IE developers show that they are willing to take a performance hit here in order to for us all to converge on a standard that Firefox and Opera could implement without breaking existing content, I'll apologize for my pessimistic attitude.

> FWIW, there *is* a negative side-effect of IE/Webkit/Chrome forcing
> this use
> case to be solved with the hackish "script/cache" behavior.

It would be worthwhile to measure the performance of preloading followed by loads from the cache to ordered execution without preloads.

Have you measured this (with some preloading mechanism that works in Opera or Firefox 3.6)?

> I guess I was specifically thinking that the default value being added
> to
> the feature-test might help distinguish it. I think currently in all
> `async`
> implementations, the default is `false`. But if we say that in
> order-preserving implementations, the default value is true for
> injected
> scripts (which fits your preference for defaults anyway), then the
> feature
> test can be not only for the presence of the `async` but also for its
> default value to be 'true', which would differentiate it from current
> `async` implementations.

Defaulting to async=true for script-created scripts has two issues:
 1) Implementing that default in Firefox or Opera would break existing content relying on ordered LABjs loads or on the "order" plug-in for RequireJS.
 2) async is a reflecting attribute and it would be radically novel (to the point of probably going outside the comfort zones of many people) to make createElement() return a node that already has an attribute.

For issue #1, I don't have enough data to say if Firefox and Opera would be able to get away with it from the user experience point of view.

To address issue #2, async should become a partially reflecting DOM attribute such that the node returned by document.createElement("script") would have .async return true but .hasAttribute("async") return false and async would start reflecting the content attribute only after .async has been assigned to or .setAttribute("async", "whatever") has been called. Not exactly elegant but possible.

Defaulting to async=false has neither of the above issues but has the issue of getting WebKit and IE to support ordered execution of script-inserted external scripts by default.

> 1. There are far more sites on the web which currently use scripts
> with
> dependencies on each other (right or wrong) than on sites who load
> multiple
> scripts which have no dependencies.
> 2. In the majority of these sites, they are using manual script tags
> in
> their HTML markup, which as I've explained in another email comment to
> this
> thread (to Ian) has some significant performance disadvantages.

Aside: There was a proposal to address this in markup, but the proposal wasn't adopted (see the thread):
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025026.html

> >> Now you are talking about a different thing: Script-inserted inline
> >> script maintaining insertion order relative to script-inserted
> >> external
> >> scripts.
> 
> When I assert the previous behavior of FF/Opera as being desirable, I
> *only*
> mean the ordered part of injected *external* scripts. I have no care
> or
> feeling about the actual motivating behavior problem where the
> ordering had
> effects on injected inline scripts. I *only* am asserting behavior
> regarding
> injected external scripts.

Great.

> >> Maybe they aren't enjoying better performance in the case where a
> >> library
> >> like LABjs emulates in-order execution. However, they might be
> >> enjoying
> >> better performance in other (potentially more common) cases. I
> >> don't have
> >> measurement data, but on the face if things, it seems reasonable to
> >> assume IE and WebKit at least aren't putting themselves at a
> >> performance
> >> disadvantage when the execution order doesn't matter.
> 
> I explained above, but again... yes, there *is* a use-case for dynamic
> loading (with performance optimization in mind) where you don't care
> about
> order. And IE/Webkit/Safari serve that use-case well, and probably on
> purpose.
> 
> But this other use-case, where scripts are loaded that have
> dependencies,
> just seems pretty obvious to me as the more common use case.

How many sites would want to do ordered loading isn't really the question when it comes to motivating a default for IE/WebKit. The default would apply to existing sites while an opt-in would work for sites that want to do something in the future.

> This has to be (in my mind) the reasoning/"carrot" for how to convince
> IE/Webkit/Chrome to make a change to support ordered behavior, however
> we
> decide that should be opted into (or out of).

It would be great if IE or WebKit developers commented on whether this carrot will work. Because if they really consider the carrot compelling, we can standardize that script-inserted async=false external scripts execute in insertion order (relative to themselves only--not relative to script-inserted inline scripts or parser-inserted scripts).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 13 October 2010 08:40:35 UTC