- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 9 Feb 2011 02:46:09 -0500
I'm losing track in the noise of what the fundamental disagreements are--if there even are any. I think the original proposal is a very good place to start: - Add a "noexecute" attribute to SCRIPT, which instructs the browser to retrieve the script without executing it. noexecute implies async. - Add an event triggered when the script finishes loading from the network, indicating that it can be executed; eg. "load". - Add an "execute" method to SCRIPT elements. This executes the script synchronously. This can only be called for noexecute scripts, and can only be called after the "load" event has been fired. - If the script fails to parse, execute() raises an exception. If the browser was parsing the file asynchronously, reporting the error is deferred until execute() is called. The key points of this: - It doesn't in any way restrict when the browser can actually parse the script. It's free to do so when the file finishes loading, when execute is called, or any time in between. Ideally, browsers would parse scripts in an idle background task, pushing it to the foreground if execute is called before it finishes. (In theory, if Javascript parsing is single-pass, it could even be done progressively as the file downloads, to lower latency.) Browsers can already do all this with <script defer>; I don't know if any do. - The "scripts in comments" hack would be unneeded. That's an unpleasant hack, because it will both prevent browsers from caching compiled scripts, and prevent scripts from being compiled in the background. Specifying a bogus file type also has these problems. - Just for comparison: <script src="path.js" noexecute onload="this.execute()"> seems roughly equivalent to <script async>, and like async, falls back on immediate loading if noexecute isn't supported. <script defer> could be implemented in terms of this as well. - Since execute() is synchronous, anything it installs becomes available to the caller immediately. This may simplify script loaders, among other things. - The event name "load" follows the Progress Events spec. If there's actual demand, the rest of that interface could be applied later on. I think this is much clearer than a readyState-based interface. - Support for this API is indicated by the presence of the "execute" function. As a side note: none of this addresses doing any of this from workers, which have a completely different API for loading scripts. Maybe none of the use cases apply to workers. -- Glenn Maynard
Received on Tuesday, 8 February 2011 23:46:09 UTC