[whatwg] Proposal for separating script downloads and execution

[Bjoern Hoehrmann]

* John Tamplin wrote:
>This is all arguing about semantics.  The point is the current mechanisms
>for handling scripts are insufficient, and on mobile phones in particular
>the process of reading the contents of a script tag (whether you call that
>parsing, executing definitions, or whatever), is way too slow and interrupts
>the UI.  This problem has driven crude hacks like the comment hack, which in
>fact precludes the browsers every getting smarter about doing the
>parsing/etc in the background or during idle time.  This proposal is about a
>way to hint to the browser that only the download part should happen now,
>and the parsing/execution of the downloaded script will happen later, which
>in fact enables smarter browsers to make smarter decisions.

The proposal is an optimization of these crude hacks. Authors using such
hacks are unlikely to stop using them because the optimization does not
work on deployed clients. New clients supporting it are likely to have
better JavaScript parsers as people make new benchmarks taking parsing
more into account than they have so far and because improvements there
help with all web sites, so as we apparently don't know very well where
the performance issues here lie and how the various hacks compare, we do
not know much about how much of a difference the proposal would make.

What will happen is that people using the proposed feature will intro-
duce subtle bugs in their code (like calling .execute() in some place
but not in another which works 99% of the time on the test systems but
fails on other systems due to, say, differences in how they schedule re-
source loads), and for others using "noexecute" may be beneficial now,
but may not be beneficial with the next browser generation, which may
result in browser vendors changing their optimization logic, which then
causes more breakage and might be more complex. And there is a toll on
everyone since in trying to optimize they would have to try yet another
thing that might help.

The terminology is not all that important, but some analyis beyond the
simple "<script> processing seems slow right now, so let authors say
don't process a <script> with side-effects until the author commands it"
is. In Perl for instance the problem is solved with AUTOLOAD, a routine
that is called when a subroutine is undefined, to act in its stead. That
allows to have the AutoLoader module which automates on-demand loading
of code. That solves the problem with different problems and benefits.
Is that better, worse, would either really have an impact in 3 years?

While I am sure that people here have done far more extensive research
than what we've heard so far, this is Ian Hickson's mailing list and as
I recall, he puts great emphasis on research and the proceedings being
available to the general public, and so far I've not seen much beyond
some blog posting with one test on hard- and software that will be four
years old when the proposed feature becomes anything resembling main-
stream, plus some individual findings, and that's not very impressive.
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/