[whatwg] Proposal for separating script downloads and execution

> The proposal is an optimization of these crude hacks. Authors using such
> hacks are unlikely to stop using them because the optimization does not
> work on deployed clients.
>
> What will happen is that people using the proposed feature will intro-
> duce subtle bugs in their code (like calling .execute() in some place
> but not in another which works 99% of the time on the test systems but

First of all, you're making quite a few assumptions which YOU have no proof 
of. The people who are vocal on here asking for this feature are 
responsible, seasoned developers, who've been in the trenches of JavaScript 
and web development for many years. We're also authors and maintainers of 
publicly consumed and widely used tools (script loaders, etc), and we know 
exactly how to responsibly use the feature we are asking for. I can't speak 
to if other devs will possibly do it wrong, but there's PLENTY in both HTML 
and in JavaScript specs which can (and is, regularly) abused by ignorant 
developers. That something *can* be abused is not proof it will be, nor is 
it a reason to deny it from the people who clearly know how to use it 
correctly.

Secondly, and more importantly, as I've said several times already in this 
thread... **THIS IS NOT JUST ABOUT THE MOBILE PERFORMANCE** I'm not sure why 
some people in this thread insist on focusing on arguing that point (ad 
nauseum) to the exclusion of the other parts of the conversation. Combine 
that with the others who want to play semantics games over what we call 
something, and the bikeshedding is getting out of hand.

Talking about how deferring a script's "execution" can help mobile 
performance seemed like a simple way to illustrate a usage of the feature 
being requested, especially since there was hard evidence and established 
research done by a pretty well known/respected/intelligent group -- the 
Gmail Mobile team.

If we were to completely throw out the mobile performance use-case, and ONLY 
consider the others (of which I've documented several), could we get this 
conversation back on track instead of these side paths of argument over 
issues which don't really matter to the overall validity of the 
request/proposal?

Even if the mobile performance use-case were thrown out, I'd still be 
advocating for the other use-cases and requesting this functionality as a 
result. I think I can safely speak for Nicholas and Steve in my assertions 
that there are other valid reasons this functionality is important besides 
just deferring execution to avoid CPU-bottlenecking on mobile.



--Kyle

Received on Thursday, 10 February 2011 17:59:23 UTC