[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

?
> I'm not sure why you are narrowing the scope to "script loaders"? (I
> imagine you're referring to js-libraries which help with loading
> scripts faster?)

Yes, script loaders like LABjs are the primary use-case that I'm concerned 
about in terms of giving the load-but-defer-execution behavior to. That 
doesn't mean it's the only use-case, just that it's (in my mind) the 
majority use-case for this feature.


> My idea was that webservers would output the above markup directly,
> avoiding the need to go through special libraries at all.

Yes, web servers could output markup like that. BUT, there'd still need to 
be some special library or code logic on the page that knew how and when to 
execute the scripts. So, in my mind, if you already need to have such logic 
in place for the execution, wrapping that logic into an existing script 
loader which is almost certainly going to use a dynamic script element 
(instead of script markup) makes natural sense.

I'm not saying the markup use-case is invalid, just that from my perspective 
it's less prevalent than the rise of all the different script loaders 
wanting to access this behavior on dynamic script elements, loaders like 
LABjs, RequireJS, HeadJS, ControlJS, and many others.

>> Yes, as I said earlier in the thread, I think we'd need to consider 
>> changing
>> the "may" wording in the current spec language to "shall" or "will". And
>> then we'd have to consider giving some basic framework language for an 
>> event
>> mechanism. Technically, the "preloading" event mechanism isn't strictly
>> necessary, but it's quite useful for several things you can't do without 
>> it,
>> and so I really don't think it's worth adjusting the spec without also
>> adding that part in.
>
> I'm not quite sure I follow you here. What I was thinking was that we
> say that implementations MUST (in the rfc 2119 sense) start loading
> the script immediately.

This is the wording that's already in the spec:

-----------
For performance reasons, user agents may start fetching the script as soon 
as the attribute is set, instead, in the hope that the element will be 
inserted into the document. Either way, once the element is inserted into 
the document, the load must have started. If the UA performs such 
prefetching, but the element is never inserted in the document, or the src 
attribute is dynamically changed, then the user agent will not execute the 
script, and the fetching process will have been effectively wasted.
-----------

I was just saying that since this wording currently says "may", it's only 
taken as guidance and a suggestion. To make this a true requirement, we'd 
likely change "may" to "shall"/"will"/"must", right?


>> Agreed, "load" is a binary one-time event, and thus not suitable for
>> overloading for this purpose. "readyState" is much more suitable since it
>> defines a progression of states. XHR already makes good use of defining 
>> such
>> an event mechanism, and so there's precedent to draw from here. In the 
>> case
>> of preloading for scripts, there's probably just two states necessary:
>> "uninitialized" and "complete". Haven't seen any use-cases for which any
>> intermediate states (like "loading") would be useful, as they are in XHR.
>
> Sure, but we'd also want to fire some event once the script has been
> fully downloaded so that the page doesn't have to use a timer and poll
> to figure out when the download is done.

I think we're in agreement here. At least I hope so. I think that the 
`onreadystatechange` event firing when the `readyState` property becomes 
"complete" is quite sufficient for an event to notify when the script 
finishes loading, correct? That's how the current IE implementation works.

I *do* see a possibility that an event for `readyState=complete` (fired when 
the script has finished *loading*) and an `onload` event (fired when the 
script has finished *parsing & executing*) could be a little confusing (name 
wise) to some developers. I wish that it hadn't ever been called "onload", 
but for clarity sake, instead called something like "onrun" or "ondone", 
etc. However, "load" has been for a long time commonly taken to mean 
"completely loaded and run" -- that boat sailed long ago. There'd probably 
be far too much compat breakage if we changed the semantics of the `onload` 
event now.

IMHO, `readyState=complete` (or `readyState=loaded`) will be fine for the 
true "loaded" event and `onload` can remain as-is for the "loaded and run" 
event.


--Kyle