Slashdot Mirror
Next-Gen JavaScript Interpreter Speeds Up WebKit
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.
I cannot wait to get this on my iPhone. I would like to see some more in depth information about how this compares to tamarin though. If it truly is better than tamarin, I wonder if mozilla would consider swapping it for squirrelFish. As an aside, that is an awesome logo...
This still isn't going to fix the fact that (X)HTML pages are transported and managed by what is still fundamentally a stateless protocol, XMLHttpRequest and AJAX notwithstanding.
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...
It's all about efficiency. If the computers are getting faster and no optimizations are done, the performance of JavaScript will of course increase. If, however, optimizations are introduced we'll get a steeper increase of performance and will also be able to write more advanced JavaScripts. Which one is better? If a better algorithm for solving a given problem comes along, then it's best to make use of it.
Embedded devices/smartphones? Mini-notebooks? I guess everyone is supposed to want an 8lb desktop replacement?
Every time I read something like that I want to bitch slap some sense into the 'tarded poster.
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.
I see it as an indicator of exactly how bad the previous js interpreters have been.
I've had large spreadsheets in Google docs, with multiple simultaneous editors, really bog down FireFox 2 on a 2ghz Core2. To the point of noticeably interfering with other apps I have open. This will only get worse as more companies try to implement traditionally "thick" applications (e.g. spreadsheets) inside a browser.
The problem is that a lot of people have grown up with the "throw more hardware at it to make it run faster" mentality since all they know is Microsoft products.
Um, no. I miss the days of hand-optimizing branches as much as the next guy, but the latest trend toward bigger, bulkier software isn't stemming from Microsoft this time. It's because computers are cheaper than developers.
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.
W.r.t. the performance of a browser's JS and HTML engines: A browser is much more than the sum of its fundamental rendering technologies. If performance were the most important driver of customer adoption, we all would have switched to using Opera years ago. But each time I try to move away from Firefox, I end up moving back because of either:
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
I am TheRaven on Soylent News