[whatwg] Proposal for separating script downloads and execution
bzbarsky at MIT.EDU
Tue Feb 22 16:29:42 PST 2011
On 2/22/11 7:19 PM, Kyle Simpson wrote:
> 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?
First of all, which two proposals are we talking about here?
> If not, would the feasibility of such a system make implementing this proposal
It would certainly make implementing it soon unlikely, if such a beastie
> 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
That's an excellent question. Is that the correct thing?
For some things (e.g. stylesheets and images) browsers don't do this in
many cases (and the HTML5 spec in fact requires such behavior). What
should the script behavior be?
> isn't that still feasible within the constraints of either of the two main proposals?
My point was that coalescing loads in ways that HTTP doesn't actually
allow is one way to handle the memory growth issue without exploding
> 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
Because if you're trying to implement some sort of "sophisticated
in-memory content-uniqueness cache" is also expected to implement HTTP
semantics, that makes implementing it a good bit more difficult.
More information about the whatwg