> >> 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? > > ... > > Someone pointed out a use-case to me: a progress bar showing how far along > > the page load is. You could do this without an event by just putting the > > appropriate bit in each chunk of the script, but you couldn't do this if > > you use "defer" instead "async" (i.e. you want a progress bar, but you > > don't want the script to execute).
The same diverse sorts of things that authors currently use script#onload for… like initializing some code now that you know it's executed and ready to go, etc. For instance, imagine you have a small plugin as the first chunk in a rather large file, and you'd like to run some logic to initialize and use that plugin as soon as possible, rather than waiting for all the chunks of the multi-part'd file to download and execute, so you'd listen for that very first `chunkReady` event, or whatever, and fire your code off then, which could/would be much earlier than if you waited until the very end of all chunks loading. My assumption is that this feature, if added, would basically allow an author to treat scripts as separately loading items in development mode, thus having separate "onload" handlers as they might normally design, and then for production combining all scripts into a single, but multi-parted, concat file, and mapping those individual `onload` handlers directly to `chunkReady` handlers, one-to-one. ----- I know the code could itself be changed to simulate the same behavior. My bias (as I exposed in the previous message) is to see features designed that are easiest for existing code to take advantage of. If this feature were added in such a way that the only way people could really take advantage of it is if they had to rearchitect their code (as some on this list persistently suggest) so as to do its own wrapping of code and notifications of each chunk being finished, I see this feature as dying a niche death without much widespread usefulness. But if we make it yet another tool in the web performance professional's toolbelt to take existing sites which load multiple files and give them a way to easily convert them (without any major code changes) over to loading fewer files in a multi-part fashion, I can see this feature being pretty useful. --Kyle
