The big story over the past 24 hours is Steve Ballmer’s statements regarding WebKit:
“Open source is interesting,” he said. “Apple has embraced Webkit and we may look at that, but we will continue to build extensions for IE 8.”
I figured I’d blog my initial thoughts on Google chrome. Rather than a hard to read essay, I figured bullet points are easier to read/scan, so that’s what I’ll do.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13. Noteworthy that they keep “Safari” in there. This looks like what I’d expect.about:, about:memory, about:plugins.Despite Google’s claims that Chrome is fast, it was notably slower in my tests at the common task of launching Web pages than either Firefox or Safari. However, it proved faster than the latest version of IE — also a beta version — called IE8.
Overall it seems pretty smooth. From what I’ve seen, the process model does result in more memory in total than Firefox 3, since most tabs I open stay open for quite a while. It’s clearly still a little rough, but it’s not even out for 12hrs yet.
I await a Mac release. I just realized Pinkerton is working on Chromium as well, so I have a feeling the Mac release won’t suck but will be a real port that looks and feels like a Mac application should.
I don’t think it was mentioned in the press conference, but the Chromium blog is open.
Wired has a great article on inside the project. In addition to the names I mentioned yesterday, Bryan Ryner was also involved in at least the prototype.
I’ll make one prediction: The code most likely to find it’s way into other browsers is the GreenBorders stuff. It was originally for IE/Firefox, making it most suitable for possible adaptation to be included in other browsers. I’m not sure how much of it remains and how easy to adapt it would be though.
I’ll leave this “review” right here and unfinished since it’s still an ongoing project. Just wanted to share my initial thoughts. I’ll follow up at some point in the future when I feel it’s right to do so.
Any thoughts/additions? Feel free to leave a comment.
Edit [9/2/2008 @ 10:55 PM EST] – Added prediction about GreenBorders and link to Wired Article.
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:
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.
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.
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:
- 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.
Google announced the project lists for Summer Of Code 2008. Some of the more interesting projects from my perspective:
Looks like Apple will be switching Safari to use GDI for font rendering on Windows in the future. Not such a bad thing. The CoreGraphics antialiasing looks good on a Mac, but does look strange on Windows. I think this will please more Windows users who expect Safari to be a good citizen and blend in.
The Acid3 test is out. Ironic that this one comes towards the end of a Gecko development cycle (just like Acid2), meaning it will likely be a while (Mozilla2, the basis of what will likely be Firefox 4.0) until Acid3 compliance is met.
Seems like the WebKit guys are well on their way.
By the time Acid3 complaint browsers are the norm, web applications will have a very nice platform of features that they can depend on. These tests really do help coordinate browser vendors to focus on certain issues by providing a good test case that they can all compare (and compete) against.
Vlad wrote about his work on improving Mac OS X performance (which is awesome by the way), and his findings from looking at WebKit code. To summarize WebKit utilizes some undocumented API’s (ironically from the same company that makes Mac OS X 
) that give it an advantage over other software which can’t use them. This is pretty anti-competitive, and Microsoft-like in behavior. For a company that built it’s modern OS on an open source core, and it’s flagship browser (which is key to their mobile initiative) on an open source rendering engine (KHTML), you would think they would be a little more understanding about crippling platforms. Then again, look at the iPhone controversy regarding it being a closed platform (though that’s supposed to change next week, and I’ll be sure to blog about that).
Robert O’Callahan’s got a got a great blog post on some of his observations of things Mozilla would likely make good use of. He also mentions one thing worth quoting:
It’s worth reflecting that if Microsoft was doing this, they’d likely be hauled before a judge, in the EU if not the US. In fact I can’t recall Microsoft ever pulling off an undocumented-API-fest of this magnitude.
This is a very valid point which I 100% agree with. Microsoft wouldn’t get away with this.
Safari developer David Hyatt (former Mozilla developer from when Lizards roamed the earth) commented about this issue. Essentially he justifies the decision based on it not being a good practice to use some of these methods, and other aren’t even used anymore. This of course raises the question: Should Apple be deciding what other software developers can do, when they themselves can’t follow the same standards? I’d say that if WebKit feels it has to use it, there’s likely others out there in the same situation regardless of “best practice”.
See, I’m not too much of an Apple fanboy to criticize them .
As Robert O’Callahan, John Resig, Anne van Kesteren all point out, this idea of using a meta tag to select a rendering engine is bad. Here are my personal thoughts on the issue. Not as a browser developer but as a web developer.
Essentially the argument by the IE team is this: Rather than fix the problem, lets create a larger problem so the smaller one isn’t very noticeable.
Yea, that’s how I parsed the blog post. For anyone who disagrees, perhaps I interpreted it wrong because they didn’t select the correct parser because they didn’t include the following:
All joking aside it’s an insane idea guaranteed to set things back.