[whatwg] Proposal for separating script downloads and execution

?> If that's what you were responding to, then I think your response is
> simply incorrect.  There's nothing whatsoever that requires that a web 
> browser freeze up its UI while parsing a script.  If it does so, it's a 
> quality of implementation issue, pure and simple.
>
> You don't need to be more efficient to avoid freezing the UI.  You just 
> have to not do the parsing work in a single shot on the main thread.

I can't speak definitively as to how the JavaScript engine is implemented 
(and if the code is significantly different between mobile and desktop). But 
I can say that even if their code is substantially the same, I could still 
see it quite plausible that the device itself locks up (not the browser) if 
there's just simply too much going, taxing its limited CPU power. Heck, I 
have times when my powerhouse desktop freezes for a brief moment when I have 
a lot going on. Exhausting the CPU is not a difficult thing to imagine 
happening on these tiny devices.

I can also see it quite plausible that mobile OS's are not as capable of 
taking advantage of multi-threading (maybe intentionally forbidden from it 
in many instances, for fear of battery life degradation). Perhaps it's 
simply not possible to multi-thread the parsing of JavaScript in parallel to 
the UI rendering. If that's the case (I really am completely guessing here), 
then it's not exactly a "quality of implementation" issue as far as the 
JavaScript engine is concerned, but more an issue of how the mobile OS is 
designed and integrated with the device hardware. Regardless, considering 
such things is way outside the scope of anything that's going to be useful 
for web developers in the near-term dealing with these use-cases.

Even if you're right and the fault really lies with the implementor of the 
JavaScript engine (or the OS), that's still a fruitless path for this 
discussion to go down. No matter how good the mobile JavaScript engine gets, 
I promise you sites will find a way to stuff too much JavaScript down the 
pipe at the beginning of page-load in such a way as to overload the device. 
That is a virtual certainty.


> And I'm saying that I just don't want this feature getting in the way of 
> browsers improving.  As long as it doesn't, it's fine by me.

I don't want to cause browsers to be less performant or hold them back from 
improving. I want to help developers have an option to increase performance 
in those cases where the browser's automatic processes to do so happens to 
fall short. I believe there must be a way to achieve both goals 
simultaneously.


> Now you may be right that authors who really want to screw up like that 
> will just do browser-sniffing hacks of various sorts and still screw up. 
> But it's not clear to me that we need to make the barrier to shooting 
> yourself in the foot lower as a result....

That sounds more like a question of degree (how much we should expose to the 
developer, and how) than the principle (should we expose it). In any case, I 
don't see much evidence that suggests that allowing an author to opt-in to 
pausing the script processing between load and execute is going to lead to 
authors killing their page's performance. At worst, if the browser did defer 
parsing all the way until instructed to execute, the browser simply would 
have missed out on a potential opportunity to use some idle background time, 
yes, and the user will have to suffer a little bit. That's not going to 
cause the world to come crashing down, though.

What's VERY important to note: (perhaps) the most critical part of 
user-experience satisfaction in web page interaction is the *initial* 
page-load experience. So if it's a tradeoff where I can get my page-load to 
go much quicker on a mobile device (and get some useful content in front of 
them quickly) in exchange for some lag later in the lifetime of the page, 
that's a choice I (and many other devs) are likely to want to make. 
Regardless of wanting freedom of implementation, no browser/engine 
implementation should fight against/resist the efforts of a web author to 
streamline initial page-load performance.

Presumably, if an author is taking the extraordinary steps to wire up 
advanced functionality like deferred execution (especially negotiating that 
with several scripts), they are doing so intentionally to improve 
performance, and so if they ended up actually doing the reverse, and killing 
their performance to an unacceptable level, they'd see that quickly, and 
back-track. It'd be silly and unlikely to think they'd go to the extra 
trouble to actually worsen their performance compared to before.

Really, let's not always assume the worst about web authors. I believe in 
giving them appropriate tools to inspire them to do the best. If they do it 
wrongly and their users suffer, bad on them, not on the rest of us. That's 
not an excuse for recklessly poor implementation of features, but it IS a 
call for giving some benefit of the doubt from time to time.


> In other words, forbid the browser to start parsing the script, right? How 
> would you tell whether a browser implemented this as specified?

I could tell if the browser let me control execution pretty easily. As for 
telling if the browser were deferring parsing to a useful degree, I'm sure 
that the only way to actually determine that would be test a site with a 
particularly long script file (length being a rough approximation for 
parsing time), and see just when (between load and execution) the big 
parsing delay (as observed previously) was happening. If the lock up still 
happened during page-load right after the script loads, even though 
execution was specifically deferred, that would seem to be the browser being 
stubborn and uncooperative.


> OK.  I definitely agree that better user control over when script 
> _executes_ is a good idea.  Sounds like we're on the same page there.

I think that what should happen is, if a web author chooses to defer the 
execution of a script (easily detectable if it's not ready for execution 
when loading finishes), the browser should get the strong HINT that maybe 
the parsing should be put off until later (and perhaps until execution 
time).

If a little bit later, the browser detects a period of idle time and hasn't 
yet been told to execute the script, and it wants to go ahead and attempt 
that parse preemptively, that's not really so bad. But if the browser 
instead insists on parsing the script immediately after loading it, then 
it's failing to recognize the spirit of what's being asked for here, and I'd 
call that a failed implementation.

Do you see how what I'm asking for is not direct forcible control over 
parsing but some way to strongly encourage the browser to defer both parsing 
and execution until later, when *I* say I want it to? Ultimately, if it 
choses option C and parses at some point between load and execution, when 
the browser/device is truly idle, then it's a win-win for both of parties. 
But automatically parsing right after load can quite easily become a 
lose-lose, and so there should be some way to clue in the browser to that 
reality.


--Kyle

Received on Tuesday, 8 February 2011 21:27:35 UTC