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.

iPhone Safari

[ryanguill]

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...

Re:iPhone Safari

[Anonymous Coward]

Imagine if IE actually used the same standards as the browsers us open sourcies like to use.

Huh? This is an engine, not a standard.

Still Stateless

[Lumenary7204]

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...

Re:Still Stateless

[MightyYar]

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

I guess I don't understand. Wouldn't having a better browser-side language make stateful applications more likely? I mean, you dismiss AJAX, but wouldn't faster Javascript make AJAX much better? There are already many "applications" that run on the web that are very similar to their desktop counterparts - better performance will make these more common, I would think.

Re:The real question is....

[Bootarn]

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.

Re:The real question is....

[ohcrapitssteve]

Embedded devices/smartphones? Mini-notebooks? I guess everyone is supposed to want an 8lb desktop replacement?

Re:The real question is....

[jo42]

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.

Re:The real question is....

[moderatorrater]

I see it as an indicator of exactly how bad the previous js interpreters have been.

Re:Still Stateless

[_|()|\|]

To me, [the network] would seem to be where most of our time is wasted...

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....

[buddyglass]

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.

Re:Still Stateless

[Jamie Lokier]

The only state most apps need to send to the server are a "session" value (cookie or form) and any data you entered. Complex page state is kept on the server, in a session-associated database. If requests are sending a little more, no harm. If they're sending a lot of data every time, which isn't user-entered on that specific page, they're not very well coded.

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....

[Yvan256]

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.

Re:The real question is....

[Jay L]

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.

Re:The real question is....

[JasonB]

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

Re:Still Stateless

[XHIIHIIHX]

Well, for lazy website operators maybe. You can strip your HTTP headers down to almost nothing, and you only need one cookie to accomplish everything.

Re:The real question is....

[TheRaven64]

It's because computers are cheaper than developers.

Last time I checked, compilers were cheaper than computers. I know compiler writers are developers (I am one), but time spent optimising a compiler has a much greater benefit than time spent optimising a single program, since the speedup applies to all code compiled with it. How much energy is taken per year, do you think, executing JavaScript in web pages? How much would be saved if the implementations were twice as efficient?