On Monday 02 of May 2011 18:29:13 Charles Forsyth wrote: it's hard to see how a fast Javascript implementation, > (...) it's hard to see how a fast Javascript implementation, > for example, is especially dependent on the operating system > on which it runs (...)
<![PESSIMISTIC VIEW[ that used to be the case, but much not anymore. some popular websites are JS- heavy, and the browser has to do heavy lifting. various speedups were implemented by popular browsers -- and are practically necessary for use of those sites. one popular speedup is compilation of JS to native code. this depends to a good deal on paging for protection (and perhaps GC, not sure). this requires some co-operation with the OS. another point of dependence (read: infinite surface of dependence) is the interaction of JS and DOM with OS-specific input model. today not only hyperlinks and comboboxes are widgets, but a lot of seemingly plain areas are made active, both on click and on mere hover, (for good reasons and with good use). also the output model: (re-)drawing screen content. both good old 2D APIs and (for IE, at least, but will in near future for others) interacting with GPU for access to accelerated drawing primitives, working neatly with composition and avoiding costly cascades of copying image data around system memory and to video memory. yet another point, probably best illustrated with FF: some plugins contribute functionality via JS code. supporting such plugins also should have some platform-specific dependencies. something having little to do with JS itself, but important for website rendering: font support. the second worst problem in computing, IMHO. some websites require pixel- or even sub(!)-pixel accuracy, lest they end up looking all messy and/or end up with overlapping widgets. yes, it runs kinda contrary to the purpose of HTML and CSS. another fine technical decision by technically unqualified managerial personnel, sigh. last but not least, google's NaCl (a.k.a. Native Client) which uses certain properties & aspects of memory protection for secure execution of binary code from foreign sources (yeah, i know we've been there; but this one oughta work, as it depends on silicon, not digital signatures from one gatekeeper company). it again depends on the OS to a degree for running the code. i believe this is an interesting thing, and possibly a viable alternative to including explicit support for countless alternative scripting languages directly into browsers. to wrap it up: i don't believe in high-performance cross-platform browsers. they either need helluva lots of maintenance & chasing the evolving platforms, or not perform all that well. ]]> -- dexen deVries ``One can't proceed from the informal to the formal by formal means.''
