[whatwg] Proposal for separating script downloads and execution

[timeless]

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.