Note that I recently checked in some changes to <script> to expose a readyState IDL attribute and to fire 'readystatechange' events, based on what IE has implemented here.
On Tue, 24 May 2011, Alexandre Morgaut wrote: > > My understanding right now is that: > > - if we want a script to be downloaded without blocking the UI, we > should use "async" Right. > - implementors shouldn't block the UI while parsing the JS (but it > should still respect the order of execution when required) I'd say "need not block", rather than "should not block". The latter is more a judgement call. > Some script are not "required" to be executed until a user action like a > "click", so that's great if their loading, parsing, and execution > doesn't block. For progressive enhancement, I like to run first only > what is mainly required. > > But once the user does this kind of more specific action, the event > handler may not work as a the script providing the required behavior > might not be yet executed. > > Try to resolve this: > > - I consider scripts providing such behaviors as named modules > > - when such user action happens > > - I fix a setTimeout() with a handler showing a "processing" > feed back to the UI if the action takes to much time, as I would if I > need to fetch data > > - instead of invoking my specific behavior, I add its invocation > in a named callbacks list which will be looked by the "module" having > the same name at the end of its initialization > > - Note: the callback will cancel the setTimeout or > remove the "processing" feedback > > So I can already do this without new vendor implementation. Yup, that should work pretty well in the current model. > It just add more asynchronous code in my app to handle But, to be > honest, my first intuition was: > > - change the "async" attribute value of the script element to false to > block the script execution of the "click" (or any other) event handler > until the required script as been executed > > -> it could prevent the requirement of handling asynchronous > code via callback lists, but I'm not sure how much it is acceptable Yeah, I could see how that would be an intuitive way of thinking it would work. It doesn't (as you discovered). Since it would mean the browser just locking up while the download finished, or at least showing its own progress bar UI rather than something that feels like part of the app, I'm not sure how desireable it really would be anyway. On Tue, 24 May 2011, Nicholas Zakas wrote: > > There is a general need on the web for speed (duh). We want not just the > current experience to be fast but the *next* experience to be fast. The > next experience is frequently made up of HTML, CSS, and JavaScript that > isn't needed immediately, and so is deferred. The timing of when to > download these resources is something that we've struggled with due to > the various ways different resources get loaded. > > We did a number of things on the Yahoo! homepage to help the next > experience be fast (note: not all are still deployed): > > 1) After page load, we started to load CSS and JavaScript for the apps > we previously had on the left side of the page. The intent was to make > sure they came up as quickly as possible. > > 2) Preload images that may be needed for the next experience via (new > Image().src = "foo.png"). > > 3) We delayed loading JavaScript for the search assist dropdown until > the user set focus to the searchbox. > > Your assertion that loading a file that simply defines a function will > solve the problem is a bit too simplistic for most web applications. > This is what we did in #1 and it actually caused performance problems as > the browser would stop to execute the script as it came in, interrupting > whatever the user was already doing. Amazingly, delays of longer than > 100ms are actually perceivable by users[1], and small delays interrupt > running animations very noticeably (a common complaint we had while > testing some of the preload strategies). Fixing this latency can be done entirely in the browsers today, by moving compilation off the main thread. We don't have to change the language to support this feature. > Moving parsing and compilation to a background thread solves part of the > problem, the problem where doing so freezes the UI currently. It doesn't > solve what I consider to be the important part of the problem, and that > is the inability to have a JavaScript resource downloaded but not > applied to the page. The best next experience can only be achieved when > the resources are ready and then applied at the right moment. Since the download and compilation can all be done in the background, then, *once browsers do this*, scripts can be structured to do nothing but provide a single callback that "applies" the script, before which the script does nothing. That would do exactly what you describe, as far as I can tell. > To be clear: this is not a problem that is unique to JavaScript. The > same problem exists with all external resources, such as images and CSS. > The difference is that both images and CSS allow you to download the > resource and then apply to the page later when you want (images via new > Image(), CSS via dynamic <link> element that is only applied when added > to the page). Script allows this too, just by having the script do nothing except define a callback. Defining a callback is trivially fast to do (the cost is in the download and compilation stages, which can be done in the background). I recommend approaching the browser vendors directly to convince them that moving compilation to a secondary thread is a worthwhile optimisation. On Wed, 25 May 2011, Nicholas Zakas wrote: > > Parsing and compilation on a background thread removes some of the > problem but not all of it. Ultimately, even if the script is just a > function waiting to be called, the browser still executes it in a > blocking fashion after parsing and compilation. It's the execution that > is troublesome part because it interferes with the UI. The fact that the > script isn't doing much is helpful, but once again, there will be a > non-zero interrupt that can affect user experience. If the script does nothing but define a callback, executing it will take roughly zero time. Certainly far less time than is perceivable or than could interfere with animations. On Thu, 26 May 2011, James Robinson wrote: > > This isn't practical if the contents of the <script> are not under the > author's direct control. For example, an author that wanted to use > jquery would create a <script> tag with the src set to one of the > popular jquery mirrors (to maximize the chance of the resource being > cached), but then have no control over when the script actually > evaluated. It's easy to imagine a case where the author wants to > initiate the network load as soon as possible but might not need to > actually start using the code until some point further along in the > loading sequence, possibly after a simple form of the page is made > visible to the user. I think it's pretty clear that if browsers started moving as much JS processing as possible off the main thread, that libraries would start taking advantage of this, so I don't think we need to worry about this case. It's an issue only during transition. > For this use case I think it would be handy to have a way to express > "please download this script but do not start evaluating it until I'm > ready". As a straw man, what about using the disable attribute? When > the load completes, if the disabled attribute is set then the script is > not evaluated until the disabled attribute is unset. After the script > evaluates it goes into a state where the disabled attribute is ignored. > Browsers that ignored this behavior would evaluate the script sooner > than the author might expect, but it's usually every easy to detect when > this is happening and react appropriately. If all you want to do is download it (not preprocess it) then you can just use XHR and then stick the script contents into an inline <script>. On Fri, 27 May 2011, Boris Zbarsky wrote: > On 5/27/11 1:10 PM, Aryeh Gregor wrote: > > Also, consider a third possibility: currently, the part of<script > > async> that's captured by the first timing in Ian's/Boris' example > > (whether it's parsing or compilation or whatever) blocks the main > > thread in browsers, even though it's async. (Right?) > > This is true at the moment in Gecko+Spidermonkey. I can't speak for > others. zewt's test case is interesting: https://zewt.org/~glenn/test-top-level-context-execution/ On my machine, Gecko takes about 150ms to compile the code (time from download finishing to script starting), about 0ms to run the top-level code, and about 10ms to run the initialisation function. Chrome, on the other hand, takes about 10ms to compile the code, about 0ms to run the top-level code, and about 150ms to run the initialisation function. Gecko demonstrates that it is possible to move the vast bulk of the execution time here off the main thread (though it hasn't yet been done), indicating that we don't need a new feature to make preparing this kind of script fast. Chrome, similarly, shows that today for this kind of code there is no need for a feature to explicitly make the code prepare faster, though in Chrome's case actually applying the code would be slow. On Tue, 24 May 2011, Steve Souders wrote: > > I only want to do the processing on the second script if the user > activates the feature. This is important on mobile now to reduce power > consumption but is also important on desktops as CPUs become more power > sensitive and JS payloads grow. If the problem is power consumption, then we really have to consider the problem at a higher level. Will delaying the user by 100ms where the user is just waiting looking at a "please wait" sign on the screen use more or less power than downloading and running the script in the background so that the user spends less total time with the screen on? Given the battery cost of a big LCD screen vs the battery cost of the radio and CPU, this might not be a clear-cut decision. To consider the battery cost here I'd really need to look at a concrete example and do some measurements. On Mon, 30 May 2011, Kyle Simpson wrote: > > [...] The majority of your comments are essentially disagreeing with the basic premise that if authors want to optimise their code, they need to be able to control that code. Fundamentally, I disagree with the idea that the only code that a site can update is the script loading code. Sites need to be able to handle security problems in any of the code they rely on, and the same techniques that can be used to resolve security problems can be used to solve loading problem. Also, we need to design for the future, not the past. There will be more sites made in the future than have been made to date. While it's important that we not break past sites, it's more important to make future sites faster than it is to make today's sites faster, especially in the case of sites that simply can't (or won't) change their scripts. > There's a whole bunch of comments in this thread which allude to the > idea that the problems being expressed are simple to fix if authors just > change how they write their code. While that may (or may not) be true, > it's irrelevant to the real-world web we're trying to fix *right now*, > because the vast majority of JavaScript is not written this way (such > that it's entirely modular and causes no side-effects on "execution"). Nothing discussed in this forum will help "right now". Any changes to the spec will take months if not years to deploy to a majority of browsers. > Continuing to suggest in this thread that the solution is to modify the > script is both aggravating and unhelpful, as it completely misses the > most important majority use-case: loading (almost) all the current > JavaScript on the web. Since pages using those scripts are going to need to be adapted to use any new feature we come up with, why would such adaptations be limited to the script loading library and not other libraries? It's not like these adaptations are complicated. All we're talking about here is moving things into a function that can be run later, instead of running everything immediately. It's maybe a half-dozen lines of boilerplate code in the most complicated case, as far as I can tell. > > But really, it seems better to structure your scripts so that they > > don't do anything when they are run except expose a callback that you > > can run when you want the code to run. > > Sure, it's better. But it's also unrealistic to expect all the millions > of scripts on the web to change simply because I want my pages to load > faster. Any changes to the spec are going to have to result in changes to pages for those pages to take advantage of the spec changes. In practice, sites are improved individually, and it is not at all unrealistic to expect a site to improve its scripts. > And as I said, it's untenable to suggest that my ONLY remedy is to > self-host and modify such scripts. No need to self-host them. Just like the scripts in question can be patched to fix security bugs, they can be patched to have different setup behaviour, and those patches can be hosted in the same place. > > What problems do these solutions solve? > > Specifically, they solve this problem: > > I want to load two or more scripts that I don't control, from locations > that aren't my own, in parallel (for performance), and I want them to > execute in order..... BUT I want to control when that execution starts. I think the better solution to this problem is to get control over those scripts and locations. Without a concrete example of the problem (i.e. an actual site, an actual explanation of why you can't control scripts that you are trusting to run on your site!), it is hard to evaluate the situation. > This thread seems to be so easily side-tracked into the minutia of > conjecturing about background thread parsing and different > implementation details. I wish we could just take as a given that > parsing/execution of a script are not zero-cost (though they may be > smaller cost, depending on various things), and that ANY control that a > web performance optimization expert can get in terms of when non-zero > cost items happen is, in general, a good thing. I don't think that's a given at all. For example, it doesn't seem to be a given that giving authors control over whether GC happens before or after printing (say) is a good thing. There is a huge risk in giving authors control: many authors are not experts, and will make poor choices. > The thread also makes a lot of references to <script async> and how that > seems to be the silver-bullet solution. The problem is two-fold: > > 1. <script async> only effectively tells a user-agent to make the > loading of that script resource happen in parallel with other tasks, and > that it can choose to execute that script at any point whenever it feels > is good. This means that the script in fact can be executed still before > DOM-ready, or between DOM-ready and window.onload, or after > window.onload. Thus, the script's execution effects the page's rendering > in an intermittent way, depending on network speeds, etc. > > <script defer> on the other hand specifically tells the script to wait > on its execution until after onload. Actually both async and defer scripts in a page will run before the 'onload' handler for the page. On Mon, 13 Jun 2011, Diogo Resende wrote: > > > > If you just mean that you have several different "panels" or "modes" > > that the user can switch between, then I would recommend just having > > several <section> elements, one for each module, and all but the > > active one have a hidden="" attribute. Script-wise, you'd just have > > each script loaded and active from the start, they'd just only work > > with their own sections. > > The sections are not possible to enumerate or can be too many to > enumerate. Imagine MobileMe, where each section of the web app has it's > own interaction (java)script (I suppose). I'm looking for the best way > to load that when switching between sections/modules and discarding it > when switch back. > > Perhaps MobileMe could have the interaction all bundled in one script, > but for a bigger app to have a fast load/response time, the scripts > should be divided.. I think.. I'd have to see concrete examples to be able to profile them to determine this one way or the other. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
