[whatwg] Proposal for separating script downloads and execution

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
> unlikely?

It would certainly make implementing it soon unlikely, if such a beastie 
is needed.

> 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?

Sure.

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 
cache complexity.

> 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.

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.

-Boris

Received on Tuesday, 22 February 2011 16:29:42 UTC