Chrome: Speculation

If you are a geek and you haven't heard about Chrome, then you've been living under a rock since Monday when it was first leaked. If you aren't a geek, your failure to notice the news is acceptable, understandable, forgivable. But now it's on my blog, and you have no excuse, so get wise.

There are more than a handful of interesting things to say about Chrome, and none of them require me to even have tried Chrome, since it's not yet available for Linux uses... here are each of those interesting things in no particular order.

1) The Comic Book

Google used an unorthodox approach to explaining the technology driving their fancy new browser. Instead of your standard, boring white paper, Google released a freaking comic book! It's still a point-by-point review of the problems of current day browsers and Google's proposed solutions, but it goes a step further with use of clever pictures to describe complex technical problems. It reminds me of an excellent video on Trusted Computing circulated years back (worth a watch if you haven't seen it before). Now, let's not fool ourselves, the Chrome comic book is not for the faint hearted... processes versus threads, memory footprint, hidden class transitions, incremental garbage collection... this isn't kids stuff and certainly not for public consumption. Were it excels is communicated complex ideas to folks with a shared vocabulary but without shared expertise. I don't develop browsers, and probably never will, but I still understood the message. A contributor to Debian Planet quipped, "I think it would be good if we had a set of comics that explained all the aspects of how computers work," and I couldn't agree more. I suppose that's one advantage of having serious cash to throw around.

2) Open Source as Market Motivator

It's my belief that Google has zero interest competing with the likes of Firefox and Internet Explorer, giants that they are... or even the lesser three: Safari, Opera, and Konqueror (being the origins of WebKit... KDE for the win!). Chrome will never be as big as those browsers and Google doesn't care. Google's purpose, stated in various press releases, developers conference, and in the freakin' comic itself, is to improve the ecosystem in which they operate: the web. Google wants more content online, and more users searching for that content, in order to feed the growing advertising business on which Google's billions are based. Chrome isn't about challenging FF or IE for market share, it is about challenging FF and IE to be better.

To accomplish these goals they have open-sourced the browser and all of its fancy doodads. Some clever things here. First, they used WebKit as their rendering engine, and as I mentioned, I love WebKit because it is based on KHTML, which was one of the first good open-source HTML renders and is still in use by Konqueror. What's unique about WebKit is that neither FF (which uses Gecko) or IE (which uses something I will refer to simply as the suck) use it. So, here you've got an entire implementation of a radical new way of building a web browser, with all sorts of cool features just begging for adoption and neither of the big players have a leg up... both will have to tear out parts and re-implement based around their rendering system. And re-implement they shall! If Chrome can deliver on all of Google's lofty promises, then users are going to gravitate to whichever browser can best deliver the same results.

3) Process vs. Threads

This is the big thing that Chrome is supposed to offer. Modern day browsers utilize tabs to allow users to visit many pages at once, which is handy... but in order to visit multiple pages like that, the browser has to be able to do many things at once. Until now, that was down with threads.

To help visualize a thread, imagine you have a fourteen year old kid and you tell him to deliver newspapers along a street. Off he goes and does his thing and he does it very well. Then, the next day, you tell the kid while he's delivering the papers you'd also like him to compose an opera. So, he goes and delivers a few papers, and then stops and jots down a few notes, maybe a harmony or two, then back to paper delivery. He gets it done, but all that bouncing from one to another causes him to do it a bit slower. The next day you ask him to do all those things he was already doing and do your taxes (does anyone else get a cat on the second result?!). This time, when he switches over to doing your taxes, his poor little fourteen year old brain can't handle it and the whole operation goes to hell... no papers get delivered, no opera is composed, and certainly not tax returns. That's threading... one "person" switching between various jobs.

Now, with processes, it's like you have THREE fourteen year old boys to do your bidding... one goes off to deliver the papers, one composes the opera, and the final does your taxes. Even if the third kid can't deliver, his epic failure doesn't impact the performance of the other two. You may still get audited, but at least you'll know the papers are delivered and opera lovers can rave about the latest wunderkind.

IE and FF use threads (though, rumor on the street is that IE8 beta is process based)... so if one thread goes wonky, you probably lose the entire browser. Chrome is different, it uses separate processes for each tab, that way if one has a problem, the others aren't impacted. If, at this point, you are saying "big deal, how often does my browser crash?" you are right where I am. I use my browser for everything all day... 10 - 15 tabs at once is standard operating procedure for me. Maybe I'm not visiting the nefarious parts of the internets. But here's what is cool about their concept. It's not one process per HTTP request or page fetch, it's one process per tab/domain. Which means that so long are you are browsing around CNN.com, you operate within a single process, sharing memory for various javascript fun within that domain. But once you leave CNN.com to visit, say, nytimes.com, the old process is killed and a new one, with fresh uncluttered memory, is spawned. Which, if you don't know much about the AJAX security model, is really a clever approach. AJAX is sandboxed by design, meaning AJAX scripts running on a page at cnn.com can ONLY talk with cnn.com servers... it cannot make a request off to washingtonpost.com or whatever... it's all isolated. So now, when you go to gmail.com and sit there for HOURS, with its memory consuming javascript, it is all washed away the moment you move to a new domain. Now that, my friends, is good news.

Of course, it comes with a cost... those processes each need their own memory, and while it may be virtual memory at first, once they start doing a lot of writing, and you get all those page faults, it's gonna be real memory... and then we'll see what happens on less-than-modern computers that don't have 2 GBs of memory to throw around just to read their daily web comics.

4) Javascript: V8

I like javascript and have no patience for its detractors. If you haven't used the likes of prototype or jquery, you have no concept of what javascript is capable of or how it can be extended to do whatever you might possibly want to do. Having said that, Javascript can be slow... painfully slow... on underpowered computers (like my laptop, now three years old). You can hear it chugging away on some javascript code. It's my observation, however, that it's not the javascript engine at fault, it's the javascript itself... folks relying too much on their framework and object oriented design and not enough on smart coding.

For example, I recently retooled a javascript library that reordered a sequence of pulldown menus (known as select elements in HTML lingo). The previous version of the library iterated through the list of selects SO many times, it wasn't even funny (and I find most HTML/javascript base conversations to be hilarious!). So, although I had to sacrifice a bit of encapsulation to do it, I was able to rewrite the library to be significantly faster... and my CPU thanked me for the effort. So, what does this have to do with Chrome?

Well, Chrome has a new javascript engine, V8, which is supposed to be a lot faster for various reasons. I guess that's great... but, at least for the vast majority of javascript code out there, the real problem isn't the engine, it's the code. Google has an answer for that too, but the day I choose to learn Java is the day I choose to dust off the law degree.

5) Gears Out-of-the-Box

When I first learned about Gears, I wasn't excited. Then I went to Google I/O and I got a little excited so I tried it out... Firebug threw so many errors, and everything ran so slow, that I lost all my excitement the threw it out. I will say that the idea of a more robust javascript interface to the filesystem and to other hardware resources is a great idea... as is a persistent data storage system beyond cookies. But Google's got an uphill battle here. Until the majority of users have Gears installed, or a browser with Gears like features, no web developer is going to utilize those tools, thus there will be no incentive for users to actually install them. I honestly have no clue how Flash managed to get installed on nearly every browser out there... but I don't see how any plugin that is as invasive as Gears is going to be able to repeat that miracle a second time. So, Gears out of the box?! Yeah, just another browser with propriatary extensions that are tempting, but should not be used.

6) User Interface

I haven't seen it yet, so I don't know... one friend says it's really hard to get used to. I reserve the right to be obstinate.

In Conclusion

Hell if I know... Google is a complete mystery. But, by and large, they haven't steered me wrong, even if some believe what they are doing is more like sharecroping than software development. I'll be the first to try Chrome soon as they release that Linux version... and while Google's at it, maybe a Linux Picasa client?