[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

?> Is there a specific problem with letting Web Workers handle this use 
case?
> They should not interfere with the UI thread.

I think the primary reason why Web Workers is not useful is that it's not 
widespread enough adoption yet to be useful to the script loader community.

http://caniuse.com/#feat=webworkers

To the best of my knowledge, it's not implemented in the mobile world at all 
(concurring with that chart). A main reason why the Gmail team experimented 
with the comment-trick for deferring parsing/execution of code was 
specifically for the mobile use-case, where Web Workers would not be 
helpful.

Also, there's no signs of Web Workers being added to IE9 (I guess we can 
hope, but I doubt it), so leaving the entire IE family out of the equation 
is not very useful or practical for the foreseeable future.


> Note that in the blog they mention that on an iPhone 2.2 parse time was 
> 2.6
> seconds for 200k of JS, compared to 240ms to just download it in a comment
> -- the mobile network isn't the issue, it is the JS parser in mobile
> browsers.

Yes, it's important to note that it's not even the *execution* of JavaScript 
code that's actually the particular issue, but rather just the parsing of it 
(even if invoking of the functionality is deferred until later) that causes 
the biggest slowdown, in most cases.

For the purposes of this discussion, we are combining (but safely so, I 
believe) "execution" and "parsing", and saying that we want to be able to 
defer the "parse/execution" phase of script loading. The reason it's 
necessary to draw the distinction (and point out that parsing is the costly 
bit) is to defuse the argument that the script author can simply change the 
script to not execute itself until manually invoked at a later time. (that 
argument hasn't been heard here yet, but it's definitely present in many 
other forums where this line of discussion has occurred before)


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

I believe I misinterpreted this question in my previous post, so let me 
readdress it. The question is, are there sites which are setting the `src` 
property but NOT wanting the download to occur, which could be burdened if 
the proposed behavior were more widely adopted? I haven't run across any 
examples of such behavior. I can't imagine that it's very widespread, 
although it's conceivable that someone may have a very small complex niche 
case where the speculative download was undesirable.

HOWEVER, the spec already says that the user-agent "may" do this speculative 
downloading, so if there are any sites which are relying on that NOT 
happening, then they are playing a dangerous game already. If the spec never 
changed to say this was a required behavior, but several more browsers just 
decided to implement the suggestion as its currently stated, those sites 
would be at no more practical risk than they are if we consider making it a 
spec requirement rather than a suggestion.


--Kyle