- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Dec 2010 18:19:05 +0000
- To: public-html-bugzilla@w3.org
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