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

[Ojan Vafai]

On Mon, Dec 3, 2012 at 6:35 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Mon, Dec 3, 2012 at 6:15 PM, Kyle Simpson <getify at 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?
>

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).


>
>> 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
>>
>>
>>
>>
>