Desktop Applications

By Jeff Cogswell  |  Posted 2008-09-10

Google Chrome Keeps Pace with Web App Advances

In the pages that follow, I give a rundown of the new Chrome browser from Google from a technical perspective. I'm not giving every detail of the nuts and bolts of Chrome, nor am I giving an overview of the cool new features. Rather, this is an overview of some of the interesting technical aspects that I discovered while reading the docs on Chrome and looking at some of the open-source code.

If you're a manager who wants a technical overview, read on. If you're a developer, you'll want to read this before reading my future articles about development for Chrome.

Multiprocessing: Finally!

For those of us who spend 12 hours or more a day at our computer (that would be me), we often start our browser at the beginning of the day and keep opening up new tabs and new tabs as the day progresses. I'm not kidding: There are times I'll have 50 tabs open in Firefox. (Okay, maybe that's indicative of other problems and I shouldn't admit that. Ahem, anyway...) And as we open more and more tabs, while closing a few here and there, the memory consumed by the browser just keeps growing and growing. I've seen the browser easily take up over 300,000K; there have been a few occasions where it even topped out at a gig. (Again, maybe I shouldn't admit that!)

Now while Chrome doesn't totally fix the memory size problem, it does help manage the issue by reducing fragmentation problems. In one of the traditional browsers, the browser gets one set of virtual memory allocated for the single process. Each tab, of course, takes up a block of memory within this total set. And as you open tabs, more memory is allocated. But as you close tabs, the memory left behind isn't always big enough for future tabs, and you end up with the standard fragmented memory problem. (Now I should probably clarify that this is the claim that Google makes; I haven't looked at the Firefox source code to find out for sure how it handles fragmented memory.)

But with Chrome, each tab gets its own process. You heard that right: Not just each Chrome window, but each tab. I've been doing development for some 20 years now, and I have to be honest: It has never once occurred to me to have a single window hosting mulitple processes. But that's exactly what Chrome does.

Now being a skeptic at heart, I wasn't sure I believed this without testing it myself. I started up Process Explorer (from Microsoft's SysInternals) along with Chrome. I then opened up new tabs and watched Process Explorer. Sure enough, there was a new process started as a new page loaded in each tab. When I would initially open a tab, Chrome wouldn't allocate a new process yet. But when I typed an address into the tab and loaded an actual page into the tab, I saw a new instance of chrome.exe start up. With the help of Process Explorer, I could look at the command line Chrome used to launch the next instance of chrome.exe. The instance included various command-line parameters, including --type=renderer which apparently tells the instance it's a tab window, as well as one called --channel followed by a string of numbers, which is likely for locating and communicating with the parent process.

This happened each time I loaded a page in a new tab; I had multiple instances of chrome.exe running. But further, if I had an existing tab with a page in it, and I went to the address bar and typed in a new URL, that page's associated chrome.exe instance closed and a new instance of chrome.exe started. That's perfect: Instead of trying to clean out the memory associated with the existing page that's closing, chrome just wipes out the whole process and starts fresh. And that's one more way Chrome stops memory fragmentation, as well as protection and isolation between pages.

But what's even more interesting is I saw an oddity when I loaded I saw two processes starting up. But for other smaller pages like, I only saw one process. I had a pretty good idea what that second process was, and when I looked at the command line parameters, my suspicion was correct: The --type command-line parameter is now set to plugin, and there's an additional parameter called --plugin-path that is set to:


That's the Flash player; Chrome starts even another process for the Flash player embedded inside the page!

Being a good engineer who likes to blow things up (virtually speaking that is), I did the easiest test I could think of. I killed that process only while keeping the Yahoo page open in Chrome.

Bingo! As soon as I did, the Chrome tab displaying the Yahoo page showed a message at the top of the page, and replaced the Flash windows (wait, plural? Apparently the single process controlled all the Flash plugins for the page) with the Flash logo and a sad face on top of it, as in the following figure.

Figure 1. Flash crashing in Chrome.


And sure enough, the Yahoo page was still usable. In other words, a plugin crashed without crashing the browser. And for a guy who likes to have a few tabs open at once, that's a godsend.

Just to make sure I tested everything completely (this was strictly for scientific purposes, of course), I killed the process for the Yahoo page as well. (I suppose Google will be glad I didn't kill their page instead.) This time, the whole page turned black with a sad face and a message, as shown here:

Figure 2. Yahoo page crashing.


Meanwhile, the other pages remained running, as I hoped. Again, that's a godsend. No more having the browser crash in my MySpace tab thanks to a bad YouTube video that was the real source of the crash while I'm right in the middle of an online banking session in another tab where I was making a transfer to hopefully prevent a payment for an charge from overdrafting my account, a payment that was in progress in yet another tab showing the page for a book I was buying to hopefully provide details to help me answer a question that I was answering from a reader of my blog in yet another tab, a question that at first I wasn't sure the answer to and as a diversion I started watching a YouTube video somebody sent me on MySpace before I realized there might be a book available that would help me out. (See how I operate sometimes? Now there's a browser that supports my neurotic ways.)

Incidentally, Chrome actually has its own task manager you can try out. While inside Chrome, press Shift+Esc to open it up. It even lets you kill processes within Chrome, having the same effect as when I killed them from Process Explorer. And if you really want a lot of info about the tasks, the Chrome's Task Manager has a "Stats for nerds" link on it, which opens up a new page in Chrome showing all sorts of great techie information on the processes. Oh yeah, and at the top of the page it has the other browsers that are running (such as Firefox) and shows their memory consumption for comparison (or competition, as Google probably sees it).

And incidentally to this incidental, the "Stats for nerds" page is accessible directly by just typing in the address about:memory (which is in the same style as the about name in the other browsers). Try these about pages as well if you're using Chrome: about:cache, about:dns, about:histrograms, about:internets, about:network, about:plugins, about:stats, about:version.

Rendering Engine

If somebody were to start out fresh writing a brand new browser, one particularly difficult part is the rendering engine. (I know-I developed an early rendering engine some 10 years ago in Delphi. The engine is long gone these days, and even if anyone found it, it wouldn't be very useful as it's totally outdated.) Google made the right choice on this one: Instead of starting from scratch, they picked an existing open-source rendering engine that's mature and packed with several great features such as speed. The one they chose is WebKit, which, interestingly enough, was developed by Apple (which in turn based its work on an early code base called KDE HTML Layout Engine). Apple's own development led to the engine that is the basis of their Safari Web browser; they then made the engine open source (WebKit), and now Google is basing its engine off that.

This means the rendering in Chrome isn't buggy and slow. It's fast, and it works. But I found something that was intriguing: While researching this article, I read that the early versions of WebKit has SVG built in. So I tried something on a whim: I opened a .svg file in chrome-not an HTML file that displays SVG, but an .svg file directly. And guess what! It rendered it just fine. For me, this is particularly intriguing, because various forces in the industry (such as Microsoft themselves, as well as Adobe) have kind of pushed SVG aside, forcing many people to drop development on it. It's hard to say how this will impact the world of SVG, but it's definitely interesting. (However, I should add a caveat: After writing this, I did some searching and found a discussion where somebody pointed out that Chrome's SVG implementation doesn't handle animation. That's a major drawback, so we'll have to wait and see if Google beefs up the support, or if this minimal SVG support is just an artifact within WebKit. Personally, I'd like to see them add to the support, because I feel SVG is still an excellent tool for interactive vector graphics that has gotten a raw deal in the past year or so.)

Desktop Applications

Desktop Applications

Google Chrome supports a form of "desktop application." There's nothing particularly magical about this; it's really just perception. When you're on a site that's a Web application, you can save a shortcut to your desktop to launch the page. When you click the shortcut, Chrome opens up in a slightly different-looking window that doesn't have the address bar and all that other recognizable browser stuff. Instead, it's just a window with the Web site. In that regard, it looks more like an application.

Looking at the shortcut, I can see that it just launches Google, passing an address as an "app" parameter, like so:



JavaScript V8

JavaScript Engine: V8

Chrome sports a new JavaScript engine called V8. V8 is an open-source project that was developed by one of Google's development teams in Denmark. (You can download and compile V8; I did just to try it out. I built it with Visual Studio 2008, and it compiled just fine, and I was able to start up the command-line sample application. You can get it here.)

The V8 engine has an interesting history. During the short time I had to write this article, I was able to find a few facts, but by no means a complete history. The engine was worked on by people who came from two diverse groups that ultimately came together at Sun. One group at Sun was working on a rather powerful virtual machine for a language called Self. The other group was working on a Smalltalk implementation called Strongtalk. The Self group developed a technology that uses nested inlines, which sounds scary, but in fact allows for heavy optimization. The end result was a Smalltalk implementation that was powerful-but one that never saw the light of day. As we all know, Smalltalk hasn't exactly taken the world by storm. Ultimately, Sun released the product to the open-source world. And Google apparently hired (at least) one of the Self team experts to help resurrect parts of the system and build a JavaScript virtual machine. And this virtual machine is called V8.

V8 ultimately has little in common with the original Self and Strongtalk systems, but it is built on some core, proven pieces, including an assembler. The end result is that V8 can compile JavaScript into native code that runs within a virtual machine that even implements optimized garbage collection (including incremental pointers and the like) and multithreaded processing. That's pretty cool if you ask me. And that's far more than just a scripting language; it's a full runtime.

And incidentally, V8 also makes use of a third-party, open-source library called JSCRE, which is a JavaScript-adapted version of the classic PCRE Perl-style regular expressions library.

(If you want to know more about V8, download the source code and just look at the names of the files. You'll see names like,,,,,,, and others that are indicative of the many features of the architeture. And if you're really interested, you can open up the source code and look at it in detail. The file is pretty fascinating to look at.)

JavaScript: For Developers

I'll be talking more about this in future articles, but for now I'll point out that Chrome has built right into it several tools to assist Web developers.

For starters, Chrome includes a full JavaScript console, as shown here:

Figure 3. Chrome's JavaScript console.


There's also a JavaScript debugger. I haven't yet worked with this, although it looks somewhat rudimentary. (But I should qualify this: I only looked at it briefly, so I could be wrong. Or, if I'm right, perhaps that's because this is still a beta version of Chrome. More on this in my next article on Chrome development.) Here's a screenshot:

Figure 4. Chrome's JavaScript debugger.


Gears and More

Gears Built Right In

Google Gears is a plugin for various browsers that gives Web sites private storage space. For example, in the past, a big problem with online word processors was the document was stored on some server somewhere. If you were on your laptop and riding on an airplane, you couldn't access your documents until you had Internet access.

Google Gears solves this by giving such Web applications local storage. That way you can save your documents locally to your hard drive, something browsers couldn't do in the past. (That's because we're using browsers for activities the original designers of the browsers never intended them to do!)

In addition to local storage, Gears offers a few more features that assist in Web development, such as local caching of items (images, and so on) so these items are available when the browser isn't connected to the Internet, as well as asynchronous JavaScript operations.

With all the standard browsers (Firefox, IE, etc.) Gears is available as an add-in. And to use the offline features of such sites as Google Docs, the end user must install Gears. Google Chrome, however, has Gears built right into it.

At first this might seem like a bad idea. Some people don't want certain plugins. (I know a guy who refuses to install Flash on his computer.) And one that allows sites to save to local storage seems like one that people would especially be leery of. But look at it this way: Chrome is trying to redefine the definition of Web browser and transform it into something that we're already using browsers for: a self-contained platform within which we can run Internet-based applications. As I mentioned earlier, the designers of the original browsers never expected us to be using highly interactive, AJAX-based, Web 2.0 sites that are fully functional without leaving a single page. The users of the Web are allowing developers to take the Web in new directions never before seen. But in order to allow these new directions to happen, the client software must be accommodating, far more so than the old browsers that only displayed static pages and simple forms allowed for. And certainly die-hard users could resist and stick to the older browsers and not install Gears, and, for that matter, disable JavaScript altogether. That's their prerogative. But then they won't be able to use any newer sites either, and shouldn't complain if that's their choice.

What About Plugins?

Here in the media industry, we have to work fast to get our articles out, and I didn't yet have time to do a full analysis of the plugin world for Chrome. I can say that Google has a site called ChromePlugins at (that's .org, not .com). There isn't much there yet, but it appears that Google is ready to fill this site with information and, presumably, plugins for us to download.

As for plugin development, I haven't found much yet. However, that's an important topic that I'll be exploring in the days to come and will be covering in my next article.


I'm impressed. I'm very impressed. Google has recognized that the current state of Web application development has outpaced browser technology and that something needed to be done. And the powers of competition will hopefully compel IE and Firefox to follow suit. If so, we will all benefit in the next year or two as new browser technology continues to move forward, finally taking us to the level of Web application power that we need to perform our daily work-without being tied down by annoyances like airplanes with no Internet and bad Flash scripts bringing our whole browser down.

Jeff Cogswell is the author of Designing Highly Useable Software. Currently Jeff is a senior editor with Ziff Davis Enterprise. Prior to joining Ziff, he spent about 15 years as a software engineer, working on Windows and Unix systems, mastering C++, PHP, and ASP.NET development. He has written over a dozen books. 

Rocket Fuel