[whatwg] Proposal for separating script downloads and execution

On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> I'm a little surprised that this conversation has swooped back around to performance and whether or not there's a valid use case here. In addition to standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla and Chrome teams were also trying to come up with solutions to enable preloading of JavaScript. What I was hoping for was a consolidation of the efforts rather than a discussion as to whether or not such efforts should continue.

The question isn't whether or not such efforts should continue, it's
whether any features need to be added to web standards to help the
efforts continue.  This is a web standards discussion list, after all,
not a list about user JavaScript library development, or browser
implementation.  If it turns out that the libraries can be developed
just fine with existing standard features, like perhaps if browsers
improve <script async> handling, then no further discussion is needed
here.

> Moving parts of the JavaScript download/execution process doesn't allow me to control when that script will be executed, which as I mentioned in a previous email, is really the crux of the issue.

So now we're back to the question of, why can't you just wrap all the
code in a function, put the function in a <script async>, and not
execute the function until you want the code to execute?  This is
assuming that future browsers parse/preprocess/whatever <script async>
on a background thread.

One possible reason I can think of: what if it turns out you need to
synchronously call the code in the <script async>, but the <script
async> hasn't finished loading yet?  Then you'd want to block the main
thread until it finishes loading, but I can't think of any way to do
that.  Well, other than busy-looping and polling until the function is
no longer undefined . . . but that's an unwarranted complication.

Received on Thursday, 26 May 2011 15:49:33 UTC