Next-Gen JavaScript Interpreter Speeds Up WebKit 193
JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.
iPhone Safari (Score:3, Insightful)
Re:iPhone Safari (Score:0, Insightful)
Huh? This is an engine, not a standard.
Still Stateless (Score:4, Insightful)
Every time you click a button that triggers a server-side transaction, the page needs to explicitly transmit info - a cookie, GET/POST variables, something - back to the server to "remind" it of its current state.
To me, this would seem to be where most of our time is wasted...
Re:Still Stateless (Score:2, Insightful)
Re:The real question is.... (Score:2, Insightful)
Re:The real question is.... (Score:1, Insightful)
Re:The real question is.... (Score:3, Insightful)
What if you didn't have to wait for faster hardware? What if everything ran much faster on what you have now - TODAY? Why should should we have to continue to spend thousands of our hard earned currency units because developers are frickin' lazy? And what about mobile devices such as PDAs and mobile phones?
Go back to Digg or wherever you crawled out from.
Re:The real question is.... (Score:5, Insightful)
Re:Still Stateless (Score:3, Insightful)
As always, it depends. I can think of two cases offhand in which bandwidth was cheaper than JavaScript/DOM. Using JavaScript to zebra stripe a large table basically hanged the browser for five seconds, so we added a class to every other row and used CSS. Adding and deleting rows to a large table was extremely slow, so we rendered all of the extra rows hidden by default, then unhid them as necessary. (Not a general solution, but it worked for our purposes.)
Re:The real question is.... (Score:5, Insightful)
Re:Still Stateless (Score:4, Insightful)
The real excessive state transfer is the repeated sending of large quantities of (X)HTML from server to client. AJAX helps with that.
Re:The real question is.... (Score:3, Insightful)
Re:The real question is.... (Score:5, Insightful)
I recently had the opportunity to work with some code I hadn't touched in over a decade, and port it to a modern hardware platform (same OS). It was amazing, because I could now do the "overnight full build" in 15 minutes. Daemons that used to take 5-10 minutes to compile now took 1 to 2 seconds.
Faster computers change everything. (Just like the availability of cheap screens, and then cheap graphics hardware, moved us from teletypes to CRTs to GUIs.) Continuous integration? Sure, we have cycles to spare. Automated testing? Ditto. Over-modularized components for quicker builds? Don't need 'em. Complex, custom circular buffers? Just log it and parse it later. Need more cache? Have some RAM.
Could I still write code that fits in 2048 bytes and runs at 1MHz? Sure. Can I do a lot more when I don't have to worry about it? Yep. Do we gain more from standing on the shoulders of frameworks and libraries than we lose to hardware costs? Hell yeah.
Re:The real question is.... (Score:2, Insightful)
A. A site compatibility problem.
B. A FF plugin that I cannot live without.
In a perfect world, alternative Linux browsers would provide support for FF plugins, but the reliance on XUL and other very FF-specific technologies makes that all but impossible. That being said, I look forward to this making its way into Midori - the WebKit-based GNOME browser project.
-jason
Re:Still Stateless (Score:2, Insightful)
Re:The real question is.... (Score:3, Insightful)