[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

>>>>> 1) If your script is no-cache, or max-age:0, does IE make a new
>>>>> request for it for every<script> element?
>>>>
>>>> For the most part this seems to be the case but there are two
>>>> exceptions:
>>>> a) Before a URL loads, if it's assigned to another script, only one
>>>> request is made.
>>>
>>> OK, that would be a violation of the HTTP caching semantics.
>>
>> Can you explain how, in more detail? In practice I haven't seen IE's
>> behavior be a problem, but perhaps I'm not seeing the full context of
>> the issue you're concerned with.
>
> If I have a response set to no-cache and you make two requests for it but 
> only one of those actually hits the server, then you're clearly caching it 
> in violation of the no-cache header.  Is that really that unclear?

Look above at what Will says... he says "before a URL loads" in (a). I 
interpreted that to mean that if I make two requests in rapid fire 
succession, and the browser hasn't yet gotten the response headers (from the 
first request) to tell it not to cache, then it makes sense from an 
optimization standpoint that IE would see the two simultaneous URL requests 
as the same and assume to only load once instead of twice.

Again, maybe I'm missing something, but the way Will describes it sounds 
perfectly reasonable to me. It might be slightly on the aggressive side, but 
I don't see how that, as described, is violating the HTTP caching semantics. 
I don't see that those semantics imply that a browser must wait to fully 
receive response-headers from a first request before deciding what to do 
with a second request of the same URL.


> Because it's the easy way to do it; we had to jump through some hoops in 
> Gecko to make sure an async XHR stays alive until it fires its last 
> readystate change event when no one is holding a ref to the XHR object.

Right, but in that case, the XHR object has a circular reference to itself 
via the closure of the handler function (assuming it was an assigned 
anonymous or in-scope function that was assigned). I was just saying that in 
the case of actual DOM elements, when a circular reference is created 
between the DOM element and a JS counter-part, through the closure of a 
handler assigned to the element, I assumed this was enough to avoid GC.

I recall in older IE days avoiding stuff like:

var script = document.createElement("script");
script.theobj = script;

Because this created a circular reference, and thus a memory-leak, if you 
didn't forcibly unset before unload the `theobj` reference to break the 
circular ref.



>> In any case, for all intents and purposes, for someone to be using the
>> "preloading" as we're suggesting (with either proposal), you'd have to
>> keep around a reference to the script element anyway, so that you could
>> later programmatically execute it.
>
> Well... no.  You could grab the ref in the onreadystatechange handler.

In the most rudimentary of cases, and only assuming the `onreadystatechange` 
handler actually had a closure reference to the script element... it 
wouldn't if say you just made reference to some outer/global scope function 
that you just assigned to the `onreadystatechange` property, like:

function handle(rs) {
   if (rs == "loaded") { ... }
   // but, no ref to script object in here
}

(function(){
   var script = document.createElement("script");
   script.onreadystatechange = handle;
   script.src = "...";
   // append to DOM
})();

Also, there's a whole set of more advanced "preloader" functionality at 
stake for script loaders which wouldn't suffice *even if* the only reference 
to a script element was via closure in the handler (and that was sufficient 
to avoid GC). For instance, a script loader that needs to load a dozen 
script files all in parallel, then execute some of them in particular order, 
while others in just first-come-first-served order... he can't just 
daisy-chain off the handlers, he needs to actually have a reference kept for 
each script element, so that he can specifically execute each one in their 
proper order.

My point was, in practice, most advanced usages of preloading are in fact 
going to have to keep around the reference, thus the GC isn't going to be an 
issue. Only in the simple basic subset of the main proposal use-case would 
this GC bug arise. And it's easily worked around by keeping a ref in scope.


--Kyle