[whatwg] Proposal for separating script downloads and execution
timeless at gmail.com
Thu Feb 10 20:33:57 PST 2011
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
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>
> 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!
>> 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.
More information about the whatwg