- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 11 Feb 2011 01:39:25 +0100
* John Tamplin wrote: >This is all arguing about semantics. The point is the current mechanisms >for handling scripts are insufficient, and on mobile phones in particular >the process of reading the contents of a script tag (whether you call that >parsing, executing definitions, or whatever), is way too slow and interrupts >the UI. This problem has driven crude hacks like the comment hack, which in >fact precludes the browsers every getting smarter about doing the >parsing/etc in the background or during idle time. This proposal is about a >way to hint to the browser that only the download part should happen now, >and the parsing/execution of the downloaded script will happen later, which >in fact enables smarter browsers to make smarter decisions. 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. New clients supporting it are likely to have better JavaScript parsers as people make new benchmarks taking parsing more into account than they have so far and because improvements there help with all web sites, so as we apparently don't know very well where the performance issues here lie and how the various hacks compare, we do not know much about how much of a difference the proposal would make. 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 fails on other systems due to, say, differences in how they schedule re- source loads), and for others using "noexecute" may be beneficial now, but may not be beneficial with the next browser generation, which may result in browser vendors changing their optimization logic, which then causes more breakage and might be more complex. And there is a toll on everyone since in trying to optimize they would have to try yet another thing that might help. The terminology is not all that important, but some analyis beyond the simple "<script> processing seems slow right now, so let authors say don't process a <script> with side-effects until the author commands it" is. In Perl for instance the problem is solved with AUTOLOAD, a routine that is called when a subroutine is undefined, to act in its stead. That allows to have the AutoLoader module which automates on-demand loading of code. That solves the problem with different problems and benefits. Is that better, worse, would either really have an impact in 3 years? While I am sure that people here have done far more extensive research than what we've heard so far, this is Ian Hickson's mailing list and as I recall, he puts great emphasis on research and the proceedings being available to the general public, and so far I've not seen much beyond some blog posting with one test on hard- and software that will be four years old when the proposed feature becomes anything resembling main- stream, plus some individual findings, and that's not very impressive. -- Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de 25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
Received on Thursday, 10 February 2011 16:39:25 UTC