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
