[whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed

[Kyle Simpson]

>> 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.
> 
> If the script author needs to manually designate the chunk boundaries,

I don't think a script author needs to manually designate the chunk boundaries. I can envision this sort of feature just being part of some low-level automated build process, which concats all .js files together into a big file, but separates out the chunks.


> can?t the script authors insert a call to a function before each
> boundary? That is, why is it necessary for the UA to generate events?

Firstly, the exact same argument could be made for not needing the script.onload event, but I don't think that argument would fly very far. Do you similarly think we should remove script.onload and just force every script on the web to be modified so that script loaders can detect when a script finishes loading?

Secondly, you very well may be inserting scripts into the stream which you don't "own" or control, just third party plugins or utilities, so modifying them to make such calls wouldn't fit with the workflow of just including third-party scripts untouched.

You could you make a system where you had a global function called `scriptLoaded(..)`, which when called essentially fired an "event" notification to anyone who's listening, and then insert `scriptLoaded("foo.js");` at the very end of each script part right before the separator. But the drawbacks of that should be obvious: having to create another user-land library for negotiating that stuff (which increases the overall script payload on the page), AND having to create another global namespace object.

Thirdly, forcing these notifications to be manually inserted into the stream not only makes the stream creation more complex (perhaps less automatable), but it then basically makes the front-end side of the equation not be able to do passive observation of the loading progress. Passive observation of events is an important technique for debug logging, performance monitoring, etc.



--Kyle