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.

7 of 193 comments (clear)

  1. iPhone Safari by ryanguill · · Score: 3, Insightful

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

  2. Still Stateless by Lumenary7204 · · Score: 4, Insightful

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

    1. Re:Still Stateless by Jamie+Lokier · · Score: 3, Insightful

      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.

  3. Re:The real question is.... by jo42 · · Score: 3, Insightful

    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.

  4. Re:The real question is.... by moderatorrater · · Score: 4, Insightful

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

  5. Re:The real question is.... by buddyglass · · Score: 4, Insightful

    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.

  6. Re:The real question is.... by Jay+L · · Score: 5, Insightful

    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.