Google's latest developer release of its Chrome browser enables packaged apps, a way to create Web apps that are indistinguishable from native apps, at least from an aesthetic perspective.
The technical gaps that remain--Web audio APIs, hardware access APIs, and the like--are all rapidly disappearing. Despite the difficulties confronted by early adopters, like German game maker Wooga's experience with Pocket Island, there are enough convincing demos at conferences like Google I/O that prove Web apps can compete with native applications, more often than not.
But for Web apps, the issue isn't merely technical. It's also aesthetic. The Web app user experience diverges enough from what native apps have trained computer users to expect that the difference is a barrier to acceptance. That's why Google's packaged app documentation has sections labeled "How they look" and "How they behave" but not "How they perform." It's also why Google's recent Chromebook refresh introduced a familiar desktop UI: As far as interacting with computing devices goes, it's a challenge to get users to embrace new modes of interaction and unfamiliar interfaces. Witness the ongoing popularity of Microsoft Word.
Packaged Web apps may be new but they feel familiar. Google's packaged apps platform, said Google engineering manager Erik Kay in a demonstration video, helps you "make apps that feel more like native applications."
A related project that Mozilla had under development, Prism, described the goal of packaged Web apps more bluntly, calling it "a way to make Web pages superficially appear to be native applications."
In other words, it's largely about appearances.
Packaged apps launch in their own window, like native apps, and they can be launched outside of Chrome, like native apps. They are offline by default and are less dependent on a network connection--a source of frustration for users when connectivity is slow or not available. They support system-level APIs to access TCP/IP, USB, and Bluetooth, as well as APIs for cross-application data sharing. And they support new app-windowing APIs so they can manage multiple windows, just like Windows, Linux, or OS X.
In fact, Kay's description of the goals of packaged apps makes it sound as if Web app development represents a source of potential shame: "Your users shouldn't be aware that your app was built with Web technologies," he said.
One thing developers should be aware of, however, is that some of Google's packaged app APIs are Chrome-specific. Developing Web apps using these APIs means you're developing a Chrome app rather than a platform-independent Web app.
Mozilla's Prism used to be an alternative, but the initiative was cancelled last year, as was its successor, Chromeless. Todd Simpson, Mozilla's chief innovation officer, said in an email that Firefox already has incorporated some of the technology from these projects. "We have built on the ideas from the Chromeless and Prism projects, and they are implemented in Firefox as part of our Web runtime for applications," he explained. "They have provided similar functionality to Chrome's recent announcement for some time now. It is great to see that Google agrees with us that running some applications outside of the browser better suits user expectations and needs. This should further accelerate the adoption of HTML5 applications."
There are other alternatives to Google's packaged app technology: Developer Todd Ditchendorf makes a Mac app called Fluid, which allows users to turn Web apps into OS X desktop apps. It's not really comparable on a development level, but it's similar from a user experience perspective. And of course there's Adobe AIR, which can package Flash and Web apps to run without a browser, using the AIR runtime.
But if Google's packaged apps platform can help turn the Web-apps-vs.-native-apps debate into a more productive assessment of technology based on project requirements, developers and app users alike stand to benefit.