[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

We've gone back and forth around implementation specifics, and now I'd like to get a general feeling on direction. It seems that enough people understand why a solution like this is important, both on the desktop and for mobile, so what are the next steps?

Are there changes I can make to my proposal that would make it easier to implement and therefore more likely to have someone take a stab at implementing?

Is there a concrete alternate proposal that's worth building out instead?

As I've said before, I believe this is an important feature in whatever incarnation may arise. If my solution isn't the right one, that's fine, but let's try to figure out what the right one is.

Thanks.

-N

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of timeless
Sent: Thursday, February 10, 2011 11:34 PM
To: Boris Zbarsky
Cc: whatwg at lists.whatwg.org; Bjoern Hoehrmann
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I don't think so.  If there is any parse or compilation or whatever you want
> to call it error, the script is never executed, so window.x is never
> defined.

oops, right, but i don't know that that complicates things much. you
just store a list of variables to pollute window with when </script>
should be applied or the error to send to window.onerror at </script>
time.

> Also, I would fully expect it to be a web compat requirement that
> window.onerror not be triggered until the script would be evaluated.  If you
> parse/compile/whatever before that and hit an error, you'd need to save that
> and report it at the "right" time.

sure, but that's one error to store with a pending <script> it's
cheaper than most other things. any attempt to speculatively compile
or compile on a thread will have to support queuing the window
assignments / onerror dispatch.

> Which means the that parse/compile/whatever process is currently not
> observable directly.  And that's a good thing!

agreed

>> in theory, i believe a js engine could choose to discard all work it
>> has done to validate syntax for x+y beyond saving those coordinates,
>> and then either do the proper ast / bytecode / machine code generation
>> lazily (or schedule to do it on a thread).
>
> Sure; a js engine could also not do any syntax validation at all, until it
> needs to run the script...

my operative assumption is that the scripts we're dealing with have
lots of functions which are declared but which will not be used in a
given page instance, which means that there /could/ be a win in not
performing a complete compile, both in time and space. obviously any
changes to the engines increases complexity which is a loss of sorts.