[whatwg] Proposal for separating script downloads and execution

Tue Feb 8 07:44:30 PST 2011

Jonas Sicking wrote:
> On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> > On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
> >
> >> On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <getify at gmail.com>
> >> wrote:
> >>> ?> One reason I like the noexecute proposal more than relying on
> >>>>
> >>>> readyState is that noexecute can be used in markup. I.e. you can
> >>>> do
> >>>> things like:
> >>>>
> >>>> <html>
> >>>> <head>
> >>>> <script src=a.js noexecute onload="...">
> >>>> <script src=b.js noexecute onload="...">
> >>>> <script src=c.js noexecute onload="...">
> >>>> </head>
> >
> > I think this would be a bad solution, because existing browsers
> > wouldn't honor noexecute, so the solution wouldn't degrade
> > gracefully.
> 
> Actually, that depends entirely on what you're putting in the 'onload'
> handler. If you're simply waiting for all three scripts to download
> and at that point execute all three of them, for example to enable
> some feature in the page, then it would degrade just fine in older
> browsers. It would just load more slowly.
> 
> I don't suspect this is an edge case either, in fact, it's the
> original use case we're trying to address here.

I thought the case being addressed here is fetching scripts early but not compiling or evaluating them until the app knows the functionality provided the script is going to be needed. The degradation story depends on the side effects of evaluating the script.

Aside: It seems like what the mobile Gmail developers are trying to do and what the browser developers are thinking *they* can outsmart the other by doing tricks. On one hand, browser developers want to compile scripts as early as possible before the script is ready to be evaluated. On the other hand, the mobile Gmail developers seem to believe that compiling scripts is too expensive

> > Adopting the readyState / early .src assignment mechanism has these
> > benefits over the proposed alternative:
> >  * Already (reportedly; I didn't test) work in IE. Always a plus
> >  over making up some new stuff.
> 
> That is only the case if there is a readystatechange event. Is that
> so? Put it this way, can people solve the use case originally brought
> up here in IE9 today, without modifications?

Testing this shows that IE9 doesn't fire a progress event for the transition that is of interest for the use case. That is, when the script transitions to "loaded", there's no event. Once the script has been evaluated, there is a (rather useless) progress event for the transition to "complete". The interesting transition to "loaded" can only be observed by polling. Sigh. :-(

Demo: http://hsivonen.iki.fi/test/moz/script-readystate.html

> >  * Authors already have to deal with IE, so the question of opting
> >  in doesn't arise.
> 
> I'm don't understand this.

The behavior of .src setting starts fetch already happens in IE. Even if authors don't like it now, they have to deal with it. There's neither opt-in nor opt-out. (Unless, of course, they are dealing by using browser-sniffed code paths.)

> >  * Sites already have to work when scripts haven't been fetched yet
> >  and when the scripts are already in the HTTP cache. Thus, starting
> >  the fetch earlier than before shouldn't cause breakage since the
> >  "worst" case is that the observable behavior becomes similar to the
> >  script already being in cache by the time the node is attached to
> >  the tree.
> 
> There is the risk that you'll tie up a lot of network connections that
> won't be used if the <script>s never end up inserted into the DOM.
> This doesn't cause site breakage, but performance is also important.

Is there any reason to believe that sites set .src on scripts they don't intend to have fetched?

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