[whatwg] Proposal for separating script downloads and execution

On Wed, May 25, 2011 at 8:44 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> As far as I understand it now, the actual problem here is that we want
> to be able to separate download and execution, not parsing and
> execution.


I think part of the confusion is that most of us think of "parsing" in C
terms: a compiler taking the whole chunk and processing the whole thing
before executing any of it.  From what I understand (from the above, and
other vague recollections), V8 only does a very rough first pass, and then
parses code when it's executed, so the amount of "parsing" time that could
be done asynchronously is tiny anyway.

But you can already do that by putting the whole script in
> a comment, for instance, as Gmail does, so I'm not clear at this point
> on why we need another feature in actual browsers.
>

That's a gross hack, that they're presumably only doing because they have no
better way.  Isn't that just a workaround for old JS engines on mobile?  I'm
guessing that hack isn't needed on any modern script engine.  See the timing
example I gave earlier: executing a large script block that only defines a
couple functions takes no measurable time.  It also takes no measurable time
(0ms) on the stock browser on my Android 2.3.4 phone (on a Nexus S).

> James points out this doesn't work if you don't control the script at
> all -- e.g., if you're loading a copy of jQuery from a central
> location that serves many sites, in the interest of increasing cache
> hits or offloading bandwidth.

The same applies to the saner wrap-in-a-function method.  I don't think it
makes sense to introduce new browser features for this, though--it's a whole
lot simpler to get the central location to offer a pre-wrapped version, than
to change every browser so they don't have to.  ("Dye my eyes to match my
dress", etc...)

--
Glenn Maynard

Received on Wednesday, 25 May 2011 18:32:33 UTC