[whatwg] Proposal for separating script downloads and execution

[Bjoern Hoehrmann]

* Kyle Simpson wrote:
>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.

There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after removing the character encoding from the bytes received), while it
is quite likely that browsers don't have very fast parsers, without very
good benchmarks I would rather suspect the problem is more in finding
out about the side effects of the code and eagerly pre-processing code
like turning it into machine code and the things that entails like gc
runs. There would seem to be no reason why a lazier evaluation strategy
would be an appreciable performance hit. You would couple those mainly
because decoupling them in implementations so you actually gain much is
hard.

Anyway, I don't really see the problem with rewriting your code so you
have more control over when execution takes place, for instance, you can
just do `function load() { eval("...") }` and similar mechanisms. That
would in fact seem wiser as browsers would have a better chance to spe-
culatively pre-parse the constant you want evaluated than doing that for
some code that has been commented out. That would of course require you
to change code, and related mechanisms would have other downsides, like
they would not degrade as gracefully or not work across origins in all
browsers, and so on. You might even make the argument that the proposal
here seems like a cheap enough hack that might get traction quickly.

On the other hand, dynamically loading code by fiddling script elements
into documents is rather ... inelegant. A more viable long term solution
would be a proper native script loading programming interface. But it's
only been 15 years since people pointed out that's necessary, let's not
be hasty when it comes to essential low-level features.
-- 
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/