[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

> Can you list some of them?  Most of the ones I can think of are ultimately
> different forms of the same optimization.

I would first refer you to the use-cases that Steve Souders has documented 
around his ControlJS library. His commentary on this topic is far more 
comprehensive than anything I can rabble off here.

http://www.stevesouders.com/blog/2010/12/15/controljs-part-1/

But, I'll take a stab at a couple of use-cases:

1. One use-case that I *am* quite familiar with is: script loaders (like 
mine, LABjs) have the need to be able to download multiple scripts in 
parallel (again, for performance optimization, but not just for mobile!), 
but it's quite common that some scripts have dependencies on each other. The 
problem is that scripts loaded dynamically are not guaranteed to execute in 
any particular order. A mechanism for loading files in parallel but 
controlling (or enforcing) their execution order, is necessary.

A recent proposal and accepted addition to the spec was my "async=false" 
proposal, which was also focused on this exact use-case. For "async=false" 
(a simplified solution to the majority use-case), what the web author can 
now opt into is that a group of scripts will be enforced to execute in the 
order that they are added to the DOM (like script tags in markup do). While 
this works for the 90% majority use-case, it doesn't cover all needs of 
script loaders.

For instance, if I have two groups of scripts ("A.js", "B.js" and "C.js") 
and ("D.js", "E.js", and "F.js"). Within each group, the order must be 
maintained, but the two groups are completely independent. As "async=false" 
is currently implemented, you cannot accomplish isolating the two groups of 
scripts from affecting each other. The "D,E,F" group will be forced to wait 
for the "A,B,C" group to finish executing.

There are several permutations of that nature in script loading which would 
be enabled quite easily by the ability to explicitly control when a script 
executes.

2. Another plausible use-case that occurs to me is loading two overlapping 
plugins (like for jQuery, for instance). The author may have a simple 
calendar widget and a much more complex calendar widget, and the two may 
conflict or overlap in such a way that only one should be executed. But for 
speed of response, the author may want to "preload" both plugins and have 
them waiting on hand, and depending on what action the user takes (or the 
state of data from an Ajax request), may then decide at run-time which of 
the two plugins to execute.

Hopefully that illustrates a few other advanced use-cases (not specifically 
around mobile) which are enabled/assisted by controlling execution of 
JavaScript separate from its loading.


>>>> See
>>>> http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html
>>>> for the official blog post about this technique.
>>>>
>>>> So, I think you should consider having download / parse / execute be
>>>> separate if you are going to go to the trouble to do anything.
>>>
>>> Isn't this just a quality of implementation issue?
>>
>> No, frankly it isn't. No matter how good the implementation of the
>> JavaScript engine on mobile, the mobile device will always be much more
>> limited in processing power than a desktop browser environment.
>
>That's not what the question was about.

The context of the original assertion is clearly about optimizing things in 
mobile (like the Gmail mobile team did) by deferring parsing/execution of 
scripts from happening during initial page-load (when the mobile device's 
CPU is already taxed). Then, the question is asked "is that just a quality 
of implementation issue".

And so I think my response is quite on target and germane. I'm asserting 
that the solution to the problem can't just be "the mobile implementation 
needs to be more efficient (higher quality)", because the issue is not 
really about the JavaScript engine, but the limitations of the device it's 
running on. That's what the Gmail mobile team found a way to work-around. No 
matter how much better the JavaScript engine on mobile could be made, there 
would be a finite limit of CPU power available on the mobile device that is 
at least an order of magnitude less than on the desktop.

We're saying we need a feature to assist in working around such issues, not 
to debate possible/mythical future optimizations to the engine which do 
relatively nothing to help the hacky workarounds for the use-case 
(performance) right now in current applications.


> The thing is, if a browser is idle, why shouldn't it go ahead and parse
> the script?

In most cases, a web author trying to second-guess a browser is not a 
fruitful endeavor. However, browsers are not always perfect in their 
behavior and decision making. If a web author needs to do something that 
they then observe is causing issues on a slow mobile device, in general, why 
shouldn't they have a little more control over how/when it happens?


> That way when you want to execute it there's no sudden UI
> pause as the script is parsed.  I'd think this would be preferable

In 95% of cases, I'd probably agree. But I've also seen cases where the 
browser tried to be smarter than I wanted it to be, and that backfired. If 
an author has *some* way to address undesired behavior in those advanced 
use-cases, the situation is not quite so hopeless and ugly.

Most of the time, when a dev is painted into the corner in one of those 5% 
of cases where the browser's "smarts" are hindering their goal, it feels 
like the balance is too far to the side of "let that be black-box inside the 
browser and you just don't worry about it" to give a web author much of an 
option.

I recognize it's a difficult balance because I understand the benefits of 
letting browsers be free to optimize. But in my perspective, these types of 
optimizations should more often be implemented as just *default*, with some 
way for a web author to opt-out or control them more fine-grained, if they 
find the need to. Giving the web author no control or visibility into things 
leads to all kinds of crazy hacky workarounds when we get ourselves stuck in 
the ugly 5%. I've run into such situations *many* times over the last few 
years of my career, and I regularly wish that the browser would expose some 
form of lower-level visibility/control to help me out.


> So I'm opposed to any proposal that forbids browsers to
> parse/compile/whatever scripts whenever they want to,

I am not sure that I'm asking specifically to give a web author the ability 
to "forbid" a browser from doing something. I think I'm asking for something 
slightly less militant. I'm asking for the web author to have a way to 
opt-out of normal default behavior (which is that a script downloads, 
parses, and executes all together practically without interruption), and 
instead have some way to pause that process after download and then resume 
it at a later time.

IF the browser chose to implement this feature request in such a way that 
they actually break it into 3 distinct steps, and the middle step (the 
"parsing") they reserve the right to do at any time, but they still give us 
the ability to indicate when we want execution to occur separate from the 
loading, I think that's a reasonable compromise here. It certainly comes a 
lot closer to accomplishing the intended goals than what we're capable of 
doing right now.

-------
ALSO, please keep in mind, the spec already suggests that there's value in 
executing a script separate from when its loaded. The clause that led to 
this whole discussion wasn't my idea, but obviously there was previous 
wisdom found in it at some point before, probably by devs much smarter than 
I am. It's just that we're now coming along and discovering that it's more 
useful than perhaps thought previously, and asking that it become a 
requirement instead of a suggestion to move the ball forward on wider 
browser adoption.


--Kyle