Firefox 3.5 vs. Chrome 3 Showdown, Round 4: Running Web apps

The behaviors a browser can't control

Officially, Zoho does not support Chrome, and says so up front in a bright red warning box. Zoho does support Google Gears, and Google actually does credit Zoho for doing so. Acrobat.com doesn't officially support Chrome either. So we were prepared for bugs on the part of the apps themselves, and we've cautioned ourselves not to blame Chrome for those bugs once we find them. Here's one: In Zoho Writer running in Chrome, when you paste a URL into a document and it makes it into a hyperlink by default, you can then have it remove the hyperlink and just leave the text. But once you've done that, the document is no longer editable -- not until you save it (which you can still do), back out of the app, and re-enter it.

For Acrobat.com, on occasion, a command will necessitate the opening of another window -- for example, the Document > Open command. Here, Adobe wishes to use its own exclusive window rather than rely on the operating system. In a regular browser, the document opening window shows up in a separate page; but in Prism, that window will appear separately, making it work like a File > Open dialog box. Chrome's lack of support for Flash-based apps like Acrobat.com means that when a document is already open, in one window, Chrome will try to open the dialog box in a tab, inside Chrome. If a regular Chrome window isn't already open, the browser launches one -- and thus the identity of this particular platform provider is inadvertently revealed.

Now, you have to wonder a bit why Chrome 3 (at least for now) is not taking account of the context of the Web application. When a Web app runs in Prism, any new page the app runs is launched in a separate window -- and since this is an application we're talking about, that's the behavior the user should expect. The browser should step aside at this point and give the Web app the stage.

On a similar note, when you launch a Web app hosted through Chrome, the Windows Taskbar registers the app as Chrome, not under its own identity. That's another behavior the user might not expect. It's also not convenient for when the user is running both the Web app and Chrome; Windows 7 will bunch both windows together under the single Chrome icon.

Meanwhile, a Web app like Pixlr that does rely on the operating system for its document opening dialogs (an Explorer window, in Windows) operates in both Prism and Chrome the way you'd expect, so choosing a file from local storage looks just the same as for any other application.

One of the biggest problems any browser-based Web applications platform (as opposed to, say, Java or Flex/Flash or Silverlight) will face is the fact that it cannot effectively marshal the behavior of each Web app. Whereas an operating system like Windows or a runtime interpreter like Java can provide an application with resources in such a way that using those resources makes the app follow the rules, a bare-bones browser platform cannot provide that luxury.

As a result, cross-platform Web apps will not interoperate effectively with the operating system. For example, neither Zoho nor Buzzword nor Pixlr recognize the Windows system clipboard, so you cannot cut and paste between Windows applications, such as from Buzzword to Word. This category of Web app remains one step removed from the user's world; and sometimes, their manufacturers will take advantage of this extra layer of obscurity to compel their users to save documents in their version of the cloud. For Buzzword and Zoho, there's an easier step, but you just have to know it's there: You can export the entire file you're trying to copy from, which makes it into a download. Of course, this means you're exporting the entire file and not an excerpt.

It's when initiating a download that the platforms start behaving like Web browsers again. Firefox brings up a dialog box asking you whether you want to open the incoming imported file in its native application, whereas Chrome places its familiar download button along the bottom rim of the window, and animates a blue arrow pointing to it.

Pixlr, however, goes a different route. Since it's designed to let you edit local images, you're never using remote or cloud-based storage. So there's no "export" necessary, only saving. And here the File > Save dialog box comes up quite naturally, in Chrome or Prism/Firefox. So you know it's possible for a Web app to save local data locally without the need for this download process; it's therefore not the browsers' fault that they have to behave like browsers to bring files into the user's local namespace.

Is there an indicator of efficiency?

Pixlr, unlike the other two apps we chose, does support Chrome, so we looked for any obvious sign of performance difference between the Prism and Chrome platforms. Even the performance indicator that Pixlr provides its users, in the lower right corner of its window, registers a peak of 100 FPS for both platforms. But that performance indicator also registers memory consumption. And it's here that we noticed that, when we load Pixlr with the exact same image from our local storage, Chrome consumes 91.5 MB of memory, climbing with each task we perform. Every brush stroke consumes an entire megabyte.

Meanwhile, Prism starts Pixlr at 13.7 MB, and every brush stroke adds 0.7 MB to that number and climbing. Not that 700,000 kilobytes for tapping an airbrush tool is impressive memory consumption under any circumstances (assuming Pixlr is being honest about its numbers), but it would appear for now that Prism has the edge on memory efficiency.

That's important, because slower and less capable systems than our test platform (for example, a netbook) will not have as much system resources. So even though the relative usability differences of an app like Pixlr in Chrome and Prism are negligible, if they're even detectable, right at first, over time we can expect performance to degrade -- and this indicator suggests that it's Chrome's performance that will degrade first.

The verdict

While the whole business of running a browser-based app outside a browser is fast-moving, unpredictable, and volatile, the big surprise from my vantage point is how far Mozilla has come in this department in just over a year's time. With regard to providing the user with a platform that works and behaves the way she should expect it to, Firefox 3.5 with the Prism add-on is just a little ahead of Chrome 3.

But I mean very little. The differences here are mostly minor ones, although one difference that matters more than most is that Prism appears to be less resource-intensive than Chrome. This might not matter much for folks with 4 GB desktop systems and wired broadband connections; but if Google's entryway into the operating system market is going to be through netbooks, it needs to pay attention to this fact and do some tuning up. It's the fact that Prism, for the most part, behaves as per general user expectations, plus the fact that the speed demon Chrome could squeeze in a lot more miles per gallon, that we give this heat -- one where I thought Mozilla would be left eating Chrome's dust -- to Mozilla.

And that makes our running tally very lopsided for now: Firefox 3.5 (3), Google Chrome 3 (1). But Chrome 3, still being very much in beta, could clear up several of these issues at any time. And when that happens, we'll be the first on the scene with a correction of our own.