[Bug 11295] Make script-inserted external scripts that have .async=false execute in the insertion order, default to true

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295

--- Comment #3 from Kyle Simpson <w3c@getify.myspamkiller.com> 2010-12-29 18:19:03 UTC ---
@Ian-

> Are there really that many sites that depend on this?

The question you are asking if fair, but it's actually a little bit the wrong
question. Let me explain:

It is undeniable that the vast majority of existing web sites (~95% or
greater?) rely on ordering behavior of markup script tags to ensure that if
they include something like "jquery.js" before "jquery-ui.js", that even if the
browser is smart and downloads them in parallel (which all modern browsers do),
it will execute them in insertion-order, so that dependencies are taken care
of.

This is so common across all browsers and most sites, the "async" attribute was
added specifically to allow markup script tag authors the ability to say that a
certain script DOESN'T have any execution-order dependencies and should
therefore be executed "as soon as possible". While we've seen a fair uptick on
the web of authors using the "async" attribute on some script tags, there
remains a large chunk of web scripts that are still being loaded in such a way
that they execute in insertion-order.

The fact is this: the use-cases for "insertion order execution" AND "as soon as
possible execution" are both valid and quite prevalent on the web.

While we may argue that scripts should never have been designed to rely on
execution order, the fact is that millions of scripts and 10's of millions of
sites DO that, and rely on it. That isn't going to change any time soon. 

**** So to answer the spirit of your original question, there are LOTS of sites
that rely on insertion-order execution. But most of them right now do so with
markup script tags, and NOT by using script loaders. ****

HOWEVER, in the last year or two especially, but even well before that in
certain frameworks, the use of "script loaders" has begun to pop up more and
more frequently. There are several huge noteable sites that are beginning to
employ script loaders, including Twitter, Zappos, Vimeo, Mefeedia, Hotmail, and
many others. They are doing so because they realize several advantages over
regular script markup tags.

Web Performance Optimization experts note a variety of different reasons why
dynamic script loaders offer performance optimization benefits over normal
script tags (even markup script tags where the browser loads in parallel).

Some advantages to dynamic script loaders:

1. Markup script tags *block* many other page-load activities, like
downloading/rendering of images/css/etc, DOMContentLoaded/DOM-ready events,
etc. Even though they may load in parallel to each other, because of
document.write(), the browser must be pessimistic and must force everything
else on the page to wait in case a document.write() is found in one of the
scripts.

2. There are potentially HUGE performance advantages to on-demand or
lazy-loading techniques, where a page-load can be optimized by reducing to the
bare minimum (or none at all!) the scripts that are loaded during the initial
page-load, and instead putting off until later the loading (or execution) of
such scripts. By getting content in front of users quicker, the perception of
page-load speed is greatly improved, which improves user satisfaction on sites.

"defer" helps a little, but there's lots of use-cases that are beyond the
capability of "defer", and thereofre require a script-loader.

Even if you ignore the performance benefits that dynamic script loaders give
sites, there are other use cases why they are important, including module
dependency management, etc.

----------------
So, here's the problem: currently, as the spec reads, a script loader CANNOT
load scripts in parallel (like the browser can with markup script tags) and
*also* execute them in insertion order. 

To TRY do so, many script loaders, including mine (LABjs), have resorted to
ugly and brittle hacks, like cache-preloading. These hacks are obviously
unreliable as browsers continue to change and evolve. If a script loader
doesn't use these hacks (for fear of browser breakage), they are left with ONLY
one choice. They *must* load scripts one-at-a-time (serially) to force the
insertion order execution.

This creates a HUGE frustrating catch-22 for web page authors. They want to
improve the performance of their sites, so they use a script loader. But the
script loader now can't load in parallel if it needs to preserve execution
order. So it has to go back to the really old (IE6/7, FF3) days of serial
one-at-a-time loading, which kills all their performance optimization. 

In fact, they quickly realize that in that situation, they'd be better off
ditching the script loader and just using regular markup script tags. So we're
right back to where we started. 

OR, I am forced to re-organize all of my script content. I'm forced to rewrite
scripts so they don't have execution-order dependencies (like jQuery and
jQuery-UI). Or, I have to self-host all my script code and combine it all into
one big file. Not only do I lose *all* parallel loading benefits with that
approach, but I also lose the shared cache CDN effect across multiple sites.

As a web page author, I can't get the true web performance that I ought to with
existing content. I have to make really unfortunate trade-off choices.

Shouldn't I as a web page author be able to say: "I want to load script
resources in parallel from my own server and/or from a remote CDN location, at
any time in the lifetime of my page, and be able to opt-in to whether I need
those scripts to execute in a certain order or I can declare that they are
independent and should execute 'as soon as possible' instead."

----------------
This WHOLE discussion fundamentally comes down to this: I should be able to,
**if I need it**, get all the benefits of insertion-order execution
preservation that markup script tags enjoy, but ALSO all the benefits of
dynamic script loading that markup script tags can't get (because they have to
be pessimistic about document.write()). 

As a web performance optimization expert, I should not have to choose. And I
definitely shouldn't have to use brittle browser hacks to do it.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 December 2010 18:19:07 UTC