- From: Ojan Vafai <ojan@chromium.org>
- Date: Mon, 3 Dec 2012 18:35:52 -0800
- To: Kyle Simpson <getify@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Mon, Dec 3, 2012 at 6:15 PM, Kyle Simpson <getify@gmail.com> wrote: > Adam- > > > To load and execute a script as quickly as possible, the author would > > use the following markup: > > > > <script async src="path/to/script.js"></script> > > > > The HTTP server would then break script.js into chunks that are safe > > to execute sequentially and provide each chunk as a separate MIME part > > in a multipart/mixed response. > > I like the spirit of this idea, but one concern I have is about the script > load and readystate events. It seems that authors will want to know when > each chunk has finished executing (in the same way they want to know that > scripts themselves finish). > Why? What would you do in such an event? > There's a contingent on this list which thinks that all script authors > should change their code to never have "side effects" of execution, and > should all instead be executable by having some other logic invoke them > (aka "module style" coding). The reality is that a mixture of both types of > approaches will be available on the web for any foreseeable future (well > beyond the time when ES6 has provided first-class module support to all > in-use browsers, so probably nearly a decade from now I'd think). So > authors will likely want to be able to monitor when each chunk "onload"s. > > One suggestion is to added a state to the readyState mechanism like > "chunkReady", where the event fires and includes in its event object > properties the numeric index, the //@sourceURL, the separator identifier, > or otherwise some sort of identifier for which the author can tell which > chunk executed. > > > > --Kyle > > > >
Received on Tuesday, 4 December 2012 02:37:01 UTC