Yesterday Google launched a beta of a new web browser they're calling "Chrome." (Windows only at this time, with Mac and Linux in the works.) Most peoples' initial responses are "Oh great, ANOTHER browser to deal with!" But Google is saying "No no! This is not just another browser."
With Chrome, Google is starting from scratch and creating an [open source] web browser for this decade that's more appropriately designed for today's environment.
So what's that have to do with us? We've been writing and talking more and more about the coming evolution of applications, and that includes web applications. The concept of a web app is changing, and we're seeing standards like Gears and Silverlight and AIR and others which could potentially blur the line between "web" apps and "windows" apps.
Yesterday I read through all of the Google Chrome documentation that was available. I played with the beta (via Fusion of course) and read through all the blog entries about the product I could find. Obviously there is a lot of cool stuff and a lot to talk about, but here's what's important to know about Chrome in the context of corporate IT applications and app delivery:
Each Chrome tab is its own process
Of course Chrome is a tabbed-browser. But one of the problems with the other mainstream browsers is that all the tabs run under a single process. This means that they all run in the same security context, and that a single buggy web page/app/script/whatever can crash your entire browser.
In chrome, each time you launch a new tab, a new process is created. (Not a new thread, but an honest-to-goodness process.) While this will slightly increase the overhead at first, it means that worst-case, a bad app will only crash that tab, not the whole browser. It also means that closing a tab will completely clear out and remove all memory elements of that page/app.
Built-in frameless app / SSB support
One of the emerging trends in the web application space is the concept of a "site-specific browser" (SSB). The idea of an SSB is that if you're just using a single web application, you don't need the address bar, bookmarks bar, forward and back buttons, etc., that a normal browser has. You'd probably like to be able to put shortcuts to that app on your desktop or start menu. Ideally you'd probably also like to change the contents of the menus (file, edit, view, etc.) so that they were specific to the web page or web app that you were using. (For example, a "compose email" menu item on the file menu of a Gmail app that would invoke the same AJAX routine as clicking the "compose email" link within the web page.)
There have been a number of lab-type projects in this space over the years, the most notable being the "Prism" extension for Firefox. (Also Windows only.) The HTML 5 draft specification has some language around this idea as well.
Google Chrome has several SSB features built-in already, including the ability to hide the excess browser and menu clutter, as well as the ability to easily create shortcuts on your desktop to web pages and apps.
Perhaps the coolest SSB feature of Chrome goes back to the fact that each tab is its own process. So now when you click icons or visit pages in an SSBish way, you can start/stop/launch/kill whatever you want without different pages/apps negatively affecting each other.
(As a quick side note, everything in Chrome is drag-and-droppable. Since each tab is its own process, you can simply drag a tab out of a window to "pop" that tab into its own window. A few more clicks and you've removed the menu bar, etc., from that window. I literally kept my Gmail window open and running all day in the background, and it felt 100% like a "real" email client. You forget that you're using the "web," which I guess is the whole point.)
Gears is built-in
I briefly mentioned Gears previously. If you've never heard of it, Google Gears is Google's technology which will allow users to run web apps while they're offline. (This will of course require that the web app developer has specifically developed the app to be Gears-compatible.) Right now the only [sorta] mainstream app that's Gears-compatible is Google Reader (Google's RSS reader), but it's widely assumed that Gmail, Google Office, and pretty much everything else that Google owns will be Gears-enabled at some point.
Building Gears into Chrome is not unexpected, but it's just one more of the "little things" that this browser does that's oriented towards real web apps.
Chrome is here to stay
I guess the bottom line with Chrome is that it's here whether you like it or not. And with a company like Google behind it, it will get noticed. We'll see how it evolves over time, but in my mind this is just one more reason (or enabling component) that will allow real desktop apps to ultimately move off of the desktop and into the cloud.