?> 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
