Free Software Linux

Google Chrome is big news since yesterday and there's a lot of great analysis already (browser wars, tech highlights and questions). So here's some analysis and speculation, especially from the perspective of software developers. First, Google's new WebKit-based browser is causing software QA folks to sigh and add yet another browser to their testing, but because WebKit is the rendering engine underneath Safari and Android, it's actually a leg up for Apple. Mozilla say they aren't worried and they continue to get millions a year to make Google the default search engine in Firefox, so that's nice, at least up to 2011. Unfortunately Mozilla is popular with the folks who are quite prepared to change browser when a better one comes along, so if (or when) Chrome achieves that, there will be a brief blur and Mozilla's share of browsers could tank. But that's not what's shiny, or what will make Chrome interesting for users and developers. Some people have compared Chrome to an OS, but it isn't. Chrome leverages the native OS' memory-separation and protection by using a separate process for every WebKit page or tab, so you get a lot of benefits:

• Every WebKit page is its own process, so Javascript on one page can't hang the entire browser
• When you close a memory-hungry page, you return its memory to the OS for use by other applications

So Chrome is in many ways a safer environment for running (at least) HTML-based applications. At least conceptually, this is a bit like a prototype that I put together at Sun with Antonio Xu several years back; instead of launching the JRE inside the browser, the applet could be launched in a separate Java process, but was rendered within the browser's main window. Which brings me neatly to raise some assumptions and questions about Chrome. Assumptions:

• Chrome's memory footprint will be larger than other browsers because its memory separation means less reuse (but native code in DLLs/.so's will be reused)
• the browser cache (file and memory) will be shared among WebKit processes
• access to the files in the browser cache probably don't have to be synchronized, but the mechanism for requesting a file to be downloaded probably does
• the memory cache probably has to be in shared memory

Chrome will probably not have a separate cookie store for each page, because Google in particular wants to ensure that users only need to login once across many of their applications Leading questions:

• what kind of add-in or plug-in model will Chrome have? add-ins are also a source of bugs and thus browser instability or insecurity
• ditto for Java, Flash and Silverlight runtimes - I'd expect them to also run separately in each WebKit process (further increasing Chrome's memory usage)

How will Mozilla and Microsoft respond?Expect Mozilla to replicate what's unique to Chrome (multiple processes running the Gecko renderer) fairly quickly. Unless there is a significant change in the headcount working the browser, Microsoft will respond more slowly, but it will get there too (not before it's lost even more share to not one but two major multi-platform competitors). How will users respond?A lot of people will start banging on Chrome right away, so if Google setup an effective community site around Chrome, they will get plenty of bug reports. But Firefox has so many invaluable plugins that very few people will move to it right away, and IE's position as default Windows browser and market leader still counts in large amounts. Where will Google go with Chrome?Google will push Chrome fairly quietly; they don't need to bang a drum, Chrome sells itself. They will just continue with other activities that support Chrome while not alienating all the other browsers that bring eyeballs to their web properties. I firmly expect that Google will play to its strengths in terms of an add-in model; instead of OLE/COM or Gecko-Chrome/XPCOM, why not go the mash-up route and get developers to write applications in (D)HTML, Java, Flash and C#? Where will Google go next?With pockets that extend all the way into deep space, the answer has to be "anywhere they want to.", but Google make strategic investments rather than just spending cash because they can. Naturally they could fund or contribute to an IDE (Eclipse or Netbeans) to help it support the development of web apps, but why bother? Chrome by virtue of its protected memory model makes web applications intrinsically more attractive than before. They could equally create a (D)HTML UI toolkit (GWT mandates Java and a server-side development model (which doesn't appeal to everyone), or support an existing one (like Dojo). But that could cause concern among the existing toolkit developers, which would impact applications being developed on those other toolkits. So I'd have to say that this will happen subtly, if at all. Google could also build unique APIs for developers in Chrome. I'd say this will happen for plug-ins (especially mashup-based ones), but I'm betting any APIs they offer will support other browsers per my comment on eyeballs above. So I'm going to go with the following:

• Google will facilitate porting or re-developing Firefox plugins to Chrome (we're talking GSOC funding, quiet cash rewards, and maybe some migration tools or docs)
• They will enhance Gears, but continue to support it for other browsers
• They will enhance WebKit, to improve standards support and also compatibility with IE- and Mozilla-isms

Outcome?Who can say for sure what's going to happen next, but I will say this - Chrome has to work hard to catch up with Firefox's wealth of add-ins. It's certainly going to be interesting when Firefox replicates Chrome's multi-process capability, as this will put a dent in Chrome's major reason for creation and adoption...

You have already tagged this post. Your tags: