Google Browser Is Now Google Chrome

I’ve mentioned the long fabled Google browser for ages now “googlefox” as it began. Some more interesting news came today regarding “Google Chrome“.

Some of the features touted by the comic include:

  • faster – mentioned throughout via new js virtual machine (might be SquirrelFish) that’s potentially embeddable into other applications and using WebKit. Also multi-threaded.
  • More Stable – Separate process for each tab means one page doesn’t crash the browser. Also more memory efficient in the long run since you’ll kill tabs that hog memory at some point.
  • UI – UI is minimal, tabs contain the controls (tabs on outside), are detachable from the window, and similar to Prism can be minimal enough to make a web application feel like it’s not in a browser. Omnibox (awsomebar equivalent), auto complete only to what you’ve explicitly typed before, improved new tab screen (similar to others proposed and implemented).
  • Secure – Sandboxes processes (sounds like the work from GreenBorder), plugins running in their own processes, phishing protection. Also has porn privacy mode.
  • Compatible – Based on WebKit, automated testing via “chrome bot” browsing pages, unit tested, fuzz tested.
  • Google Gears Included – Includes Google Gears, which is downloadable for other browsers already.

Also interesting were some of the names mentioned in the comic. While long known a few Mozilla hackers went to Google, here’s a list that are mentioned in the comic: Darin Fisher, Ben Goodger, Brett Wilson (various Mozilla contributions via Google), Arnaud Weber (Netscape).

Check the comic for more details. This is pretty much the main info in there for those who don’t have the time to sift through it all.

Edit [9/1/2008 @ 6:23 PM EST]: Google Blog post.

Edit [9/1/2008 @ 7:45 PM EST]: John Lilly’s Thoughts on Chrome & More.

Edit [9/1/2008 @ 9:05 PM EST]: Apparently this was announced prematurely due to someone not realizing that it Labor Day isn’t in Germany. As a side note, how does one get on that mailing list?

Edit [9/2/2008 @ 8:55 AM EST]: Code should appear here.

Getting Faster With TraceMonkey

Mike Shaver has an awesome blog post on work to speed up JavaScript. Granted Firefox 3.0 is pretty fast already, 4.0 is shaping up to put 3.0 to shame. For those who don’t want to read it all, here’s what you really should know:

The goal of the TraceMonkey project — which is still in its early stages — is to take JavaScript performance to another level, where instead of competing against other interpreters, we start to compete against native code. Even with this very, very early version we’re already seeing some promising results: a simple “for loop? is getting close to unoptimized gcc[.]

That is a very impressive feat, and even more impressive is that it’s so early on. Schrep has a demo for anyone who still doesn’t see what this really means for future web applications.

Brendan has a great blog post with some more details on what has been done so far, as well as some more graphs.

The first thing that comes to mind is that it makes <canvas /> much more useful. While it already is handy, one of the big problems is that it doesn’t take to much to make it feel slow.

I think the real benchmark for most people these days is Gmail and Yahoo Mail, which are likely the two most JavaScript intensive applications most people use on a daily basis. Most people saw a nice gain when moving to Firefox 3.

Considering a substantial part of the browser chrome is implemented in JavaScript, this work has significant impact in the future performance of the browser as well as the web applications that run within it.

This all comes just a matter of hours after querySelectorAll landed, which will also give a boost in performance as John Resig explains.

A few months ago I mentioned SquirrelFish, the WebKit teams attempt to improve JavaScript performance. It’s great to see performance being such a focus.

It’s important to note that this isn’t just about making things feel faster, it opens up the web to handle things that previously couldn’t be done before. It also paves the way for a better mobile experience. Two fantastic things. Things that previously a browser just couldn’t do as well as a desktop application will become possible in the not to distant future.

Safari’s New JS Interpreter: SquirrelFish

There’s an announcement on the Safari blog about SquirrelFish, their new JS interpreter. To sum it up:

SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation.

Some performance data can be found here, as well as here, which even tests against Tamarin (slated for inclusion in Mozilla2). I think the motive for this move might have been best summarized here:

  1. I can imagine the “performance per watt? power consumption for SquirrelFish is also much lower. Good for my iPhone’s battery life.

Especially with the iPhone going 3G next week which will consume more power, making a web browser be as efficient as possible with CPU cycles not only makes the experience better, but will save battery life. This doesn’t just impact the iPhone as Google’s Android also includes WebKit.

David Mandelin has some analysis and comparison to the Mozilla work being done on his blog.

It’s pretty interesting stuff.