Since its inception, the Web has been synonymous with the browser. Pundits hailed NCSA Mosaic as “the killer app of the Internet” in 1993, and today’s browsers share an unbroken lineage from that humble beginning.
Today’s Web sites are another matter, however. Gone are the static pages and limited graphics of 15 years ago. In their place are lush, highly interactive experiences, as visually rich as any desktop application.
The Web has become the preferred platform for enterprise application delivery, to say nothing of online entertainment and social software. In response, new kinds of online experiences have begun to emerge, challenging old notions of what it means to browse the Web.
Take Twhirl, a desktop client for the Twitter online service. Double-click its icon and the application launches in seconds. Its window is small and stylized, with an attractive, irregular border and configurable color schemes. What few controls it has are convenient and easy to use. It’s sleek, fast, and unobtrusive. In short, it’s everything that navigating to the Twitter Web site with a browser is not.
But don’t be fooled. Although it looks and feels like an ordinary desktop application, Twhirl’s UI is rendered with HTML, CSS, Flash, and ActionScript. Essentially, it’s a Web app.
Twhirl is built on Adobe AIR, which has a lightweight client library that allows Web developers to use familiar tools and languages to build first-class desktop applications. Software created with AIR is fully interactive and network-enabled, with a rich UI. But unlike traditional Web applications, AIR apps gain the immediacy and user engagement that come from running outside the browser window.
“The browser is terrific for transient experiences … things that a user might do once in a while, or for a short amount of time,” says Ed Rowe, director of AIR engineering at Adobe. A frequently accessed service like Twitter, on the other hand, cries out for a lightweight client. AIR allows the same developers to build both.
But AIR is only one branch in the Web’s ongoing evolution. Already, Google, NetSuite, Salesforce.com, Zoho, and others are using Web tools and infrastructure to deliver full-fledged enterprise software, defying the limitations of today’s browsers.
As the static Web gives way to RIAs (rich Internet applications), client software must continue to adapt and evolve; and in some cases, this could very well mean stepping beyond the traditional browser altogether.
The Web, refracted
Adobe isn’t the only company working to push the Web beyond today’s browser. At Mozilla, platform evangelist Mark Finkle explores new ways for current browser technology to better meet the needs of today’s Web apps.
“Honestly, the Web browser — whether IE, Mozilla, or Safari — hasn’t changed too much since the mid-’90s,” Finkle says. “The Web, on the other hand, has changed a lot. The capabilities of the Web are significantly stronger than 10 years ago.”
Finkle is project lead for Prism, software from Mozilla Labs that offers a middle ground between AIR’s desktop integration and the traditional browser experience. Prism is a tool for creating SSBs (site-specific browsers) — applications designed to work exclusively with a single Web application, but without the menus, toolbars, and accoutrements of a normal Web browser.
With Prism, you can capture your Facebook session into an SSB, for example, and then launch it from an icon on the desktop, just like native software. The site appears in its own window, without any extraneous bookmarks, menu bars, or navigation buttons.
“It’s still a Web application, and it’s still running on the Web,” Finkle explains. “Prism is just a different way to view that application.”
That seemingly trivial distinction can make a big difference. After a few hours, it’s easy to forget that an application running in Prism is hosted on the Web and not the local machine. By shedding the traditional browser UI, Prism offers an increased level of user engagement that is particularly attractive for Web applications that displace traditional OS-native software.
“Personally, I run my Web mail and calendar in Prism and use a Greasemonkey-like script to pop up OS alerts for incoming mail and meeting alerts,” Finkle says.
And users can often install Prism applications the same way they would other desktop software. For example, Ubuntu 8.04 offers a number of Prism SSBs in its standard software repositories.
Getting creative
While Prism’s SSBs are really just stripped-down browser windows, however, Adobe AIR takes the concept of stand-alone Web apps a step further. AIR combines an HTML rendering engine with Flash, ActionScript, and a local storage mechanism. Together, these components allow applications built with Web technologies to offer all the luxuries of traditional desktop software.
Users download and install AIR applications using Adobe’s custom installer and launch them from icons, just like native applications. Once they’re running, they are fully integrated with the desktop.
They can open windows or hover above the desktop as widgets. They can even manipulate local files. With the rich graphic capabilities of Flash, there’s little to indicate that they were built with Web tools and not C++.
In a sense, AIR is the opposite of Microsoft’s Silverlight strategy. Where Silverlight applies concepts from the Windows Presentation Foundation to RIAs, AIR allows developers to migrate traditional Web technologies to the desktop.
To Adobe’s Rowe, the transition is a natural one.
“The Web model has proven itself. It’s possible to make massively scalable, robust applications — like Amazon.com — using this model,” he says.
In fact, the Web model has many advantages. Because they are standards-based, Web applications are inherently cross-platform. The familiar Web tools and languages also allow rapid application development, without re-inventing the wheel to achieve basic UI conveniences.
Perhaps equally important, AIR applications are meant to look good. “Adobe is really the leader at working with creative professionals,” Rowe says. The maker of Dreamweaver, Flash, and Photoshop, Adobe now hopes to bring the aesthetic expertise of artists and Web designers to bear on the software development process, an area where design is too often neglected.
“Some of the highest-value designs and the most impressive experiences I’ve seen have been on the Web,” says Rowe. “Software design on the Web really integrates designers better. We wanted them to be able to take those skill sets and create applications outside the browser.”
Cranking up the browser
Not everyone agrees that moving Web apps outside the browser is the right approach.
“We think the browser is where it’s at. We want to push that forward,” says Dion Almaer, developer advocate at Google. “Google has been building all of these Web applications — we’re basically Web developers — and we wanted to add functionality.”
Since the Web’s inception, all browser-based applications have shared certain limitations. Foremost is their reliance on the network; lose your Internet access, and a Web app’s greatest strength becomes its greatest weakness.
Google Gears aims to solve this problem. A Gears-enabled application looks and behaves just like a regular Web app, with a difference. Client-side Gears code caches HTML, images, and JavaScript while you work, allowing the application to keep running even if you lose your Net connection.
When you submit a form or modify data, the request is queued in local storage and synchronized the next time you’re online. The overall effect is like running a native desktop application, without sacrificing the core browser experience.
“With Gears, you still go to the same URL, the application works, and you don’t have to have any companion apps. It’s extending the Web to places that maybe people weren’t used to before,” Almaer says — even, for example, to an airplane seat.
The client-side Gears code confers other benefits, as well. One module, called WorkerPool, speeds up AJAX applications by executing JavaScript instructions asynchronously in the background, freeing the browser to handle user interaction and page display. Future Gears modules will add APIs for location-based services and unified event notification.
Google’s Gears strategy is all about restraint. Unlike AIR, which advertises its presence to the end-user, Gears works quietly, in the background. Rather than confounding developers with hundreds of new features and APIs or forcing them to learn a new application paradigm, Gears adds just a few new capabilities to the browser, each designed to address a particular pain point.
“It’s kind of similar to how the XMLHttpRequest object allowed AJAX,” says Almaer. “This tiny little module with a little bit of functionality enabled developers to be creative. We’re trying to do that approach.”
Share alike
Of course, there’s no one answer. While in some respects each of these technologies competes with the others, they are also often complementary.
For example, there’s no inherent conflict between Prism and traditional browsers. “Today’s SSBs just make it much easier to escape the browser and add some neat OS conveniences,” Mozilla’s Finkle says. “I think we’ll see some of these conveniences start to appear in traditional browsers, too.”
Similarly, the choice between Adobe AIR and Google Gears is a false dichotomy. “I imagine that a browser with Flash and the proper hooks into the Google platform would be pretty powerful,” says David Bliss, technical director at Odopod, a San Francisco-based design firm.
As these technologies mature, a new kind of browser is likely to emerge, one that combines the current Web experience with new capabilities based on emerging tools. The key to that evolution will be to integrate today’s cutting-edge features with tomorrow’s Web standards — a process that Adobe and Google are both actively pursuing.
“We’ve got Gears out there — we’ve got it running in Google Docs, Google Reader,” Google’s Almaer explains. “So now we can go back to the standards groups and we can share our experience, and we can work with them to get these standards that have actually been battle-tested.”
Tellingly, Ian Hickson, lead editor of the draft HTML 5 specification, is a Google employee. And the fruits of Google’s labors are already evident.
“You can take a look at the HTML 5 proposal that’s being actively edited at the moment, and you’ll see that there’s a database API like Gears has a database API,” Almaer says.
Adobe is similarly involved in the standardization process — in particular, extending ECMAScript, the standard on which JavaScript is based, to make it more effective for large-scale application programming. Adobe has already implemented many proposed extensions in Flash’s ActionScript language. “ActionScript 3 is essentially an implementation of where we think ECMAScript is going,” Adobe’s Rowe says.
Tomorrow’s Web
Despite differences in approach between AIR and Gears, Adobe and Google actually share a common vision. Both companies aim to extend the current Web browsing experience with new features that allow developers to deliver RIAs more easily. And, because Web developers, too, have diverse goals and methods, the traditional browser is unlikely to disappear as an application-delivery platform, even as desktop-based Web apps proliferate.
“The goal is to overcome a few persistent shortcomings of RIAs,” says Odopod’s Bliss. “The browser still has an important role in this model. It is likely to be the first touch point for most users and customers. AIR applications can extend the experience for a set of users.”
Far from being a “browser killer,” AIR is merely an extension of an existing, successful Adobe strategy. While AIR apps run on the desktop, most Flash content is displayed in the browser, using the Flash plug-in.
“Adobe has no vested interest in saying all apps should be Web apps or that all apps should be desktop apps. In no way are we anti-browser,” says Adobe’s Rowe. “As far as the browser becoming more powerful, where that makes sense, that’s great.”
Significantly, both Adobe and Google also rely heavily on open source code. Google Gears is 100 percent open source, while AIR incorporates the open source WebKit rendering engine and the SQLite data storage library.
An important effect of this is that code contributed by one company can actually benefit the other. This informal collaboration, combined with the formal Web standards process, ensures that the future development of the Web remains a dialogue, not a debate.
“We realize that we’ve got some smart developers, but there’s lots and lots of people out there that have different things that they would like to make better on the Web. We’d love to have them join our community,” says Google’s Almaer. “It’s all about having one place, one community to drive the Web forward.”
