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
