[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

> This can cause the wrong image to show temporarily, until replaced by the 
> right one (which I consider a bug; I think the cache needs to be less 
> aggressive).
>
> That approach is clearly not workable for scripts... ;)

No, clearly not. I think we're finally in agreement on something. :)


I think we need to refocus the thread. Boris, you've brought up issues of 
essentially:

1. Will keeping scripts around in memory that never get "used" lead to 
run-away memory usage?

2. Does the caching behavior of IE do incorrect things (that Mozilla would 
want to avoid)?


For #1, I think we've established this is probably true (for those rare 
corner cases). Perhaps a more sophisticated in-memory content-uniqueness 
cache could be constructed, but it may be more work than it's worth. To push 
the ball forward, in a rough (non-binding) estimate, do you think that 
Mozilla could be persuaded to agree to either of the two proposals, granted 
the potential corner case negative performance, *without* such a 
sophisticated in-memory cache to address some of those concerns? If not, 
would the feasibility of such a system make implementing this proposal 
unlikely? Or would it just be a pre-requisite that made the implementation 
of "preloading" somewhat more complicated than it appears on the surface?

For #2 (and several other related questions we've been exploring)... 
granted, it clearly seems that IE's implementation is not perfect (but is at 
least getting better as of IE9). But as with the above assertion/question 
about #1... if the correct thing is just to always follow HTTP semantics, 
and assume you have to request every URL until you get caching headers 
saying otherwise... isn't that still feasible within the constraints of 
either of the two main proposals? Granted that it would be diverging from 
IE's bugs in this area, but would it be workable to do so? If not, can you 
clearly articulate why you think the proposals could not fit with existing 
precedent on HTTP caching semantics?

Also, I want to go back to a question I asked earlier in this thread and I 
don't think I quite got a full answer to:

With respect to the HTTP caching semantics (or other related performance 
concerns), *other than the potential waste of unused scripts*, what 
additional concerns does "preloading" imply that the quite standard current 
practice of dynamically adding script elements to the DOM wouldn't imply? 
I'm trying to figure out why "preloading" presents additional 
challenges/risks that the current dynamic loading mechanisms don't.



--Kyle