Are Web Browsers Ready for the Next Generation of Internet Applications?

It’s one thing to ask tool builders about their application development vision. It’s certainly relevant to contemplate the challenges software developers will face. But if the application platform—in this case, the Web browser—doesn’t cut it, the computer industry may be in a world of hurt.

ARTICLES IN THIS SERIES: THE FUTURE OF WEB DEVELOPMENT

Beyond Ajax: Software Development, Two Years from Now

Convergence of Desktop, Web and Mobile Clients

The Immersive, Cinematic Application: Improving the User Experience

Making Development Less Difficult, or Interceding with the Browser Gods

>>Are Web Browsers Ready for the Next Generation of Internet Applications?<<

Web Browsers of Tomorrow

Don’t assume that toolmakers are perfectly aligned with the browser developers. Tim Bray, director of Web technologies at Sun Microsystems, says, “The people who make a living building Web apps and tools for them live on a different planet than the people who build browsers.”

Yet, for a happy Web development future, browsers have to change. “Today the browser is a pretty tough execution environment,” says Jochen Krause, CEO of Innoopract (the company behind Eclipse RAP). Alex Russell, project lead for the Dojo Toolkit, believes that the browser makers have failed the development community. They’ve made application design incredibly difficult, he says, because “the majority of browser vendors haven’t published a road map, so no one knows what’s coming.”

Alternatives may be necessary. David Wadhwani, Adobe VP, RIA platform, says, “Browsers may hit a wall because of political conflict between browser vendors and their own agendas.” As a result, he believes, “Developers will depend more on plug-ins to extend the browser.”

This raises the question of whether future Internet applications will rely on the browser per se, on plug-ins or on…well, something yet to be invented. And should they?

One possibility: “The border between the operating system and the application will get more and more porous,” says David Temkin, Laszlo Systems CTO. Right now, the browser doesn’t know when you plug in a digital camera, so—unlike desktop applications that are integrated into their host environment—it can’t take action when that event occurs, he says. “We’ll have to see more communication between plug-in vendors and OS vendors,” says Temkin.

But the architecture may need some deep navel gazing, he believes. The Internet (and thus the standards for it) has a heritage of documents; that’s not how applications work, Temkin claims. “There’s a little bit going on with the browser where it’s the tool of choice for delivering network apps; that isn’t its heritage, and that’s holding it back,” says Temkin.

David Intersimone, CodeGear vice president of developer relations, says, “I don’t know that I want the browser to be more than just a conduit or a container for stuff. I’m happy if they give us the hooks and APIs to do all these things.”

Yet, he contemplates several looming problems for developers, such as how to take advantage of the hardware horsepower on a virtual machine. For example, with computer systems commonly having multiple processors, how does a developer tell a Web-based application that one component should use a single CPU? What about 3-D screens, alternate UI devices (such as eye tracking or voice)? How do users change the way they interact with the interface? If we use a speech UI, wonders Intersimone, do we have to say aloud, “Click it”?

“I am not convinced that the browsers will solve problems for us by adding more capabilities,” Intersimone concludes. “I thirst for either a simple browser container with loads of hooks for programmers, or desktop application containers that allow us to bring the Internet to the desktop.”

Right now, he’s exploring what Adobe’s FlexBuilder 3 and Adobe Integrated Runtime (AIR) might do; but even it, he says, relies on integration to other programming systems including Java, PHP and Ruby.

Standards Follow Behavior

It’s a good thing that we have Web standards; every existing Web 2.0 site relies on them. But some toolmakers worry about the balance between standards and innovation. Russell points out that saying to the browser vendors, “Thou shalt follow the spec” trickles to the browser vendors as, “We shouldn’t take risks.” Yet, he adds, “The W3C isn’t so much wrong as they’re downwind.” In other words, they don’t drive the action.

Still, says Adobe’s Wadhwani, the industry has to hold the browser vendors to work toward a meaningful spec and adhere to the spec. “The spec process is defined by committee,” he points out, “so we end up with a really slow, poorly designed environment for creating applications.” The situation isn’t improved by the fact that vendors all have their own agendas. “There are those on the inside [of the standards process] trying to scuttle the progress,” says Wadhwani. “It isn’t consistent with their desire to move the platform forward.”

This view is not necessarily universal. Jean-François Abramatic, chief product officer of ILOG (who is on the W3C Advisory Board and a past chairman), says, “Some [standards] are more to the point than others because nobody’s perfect, but at the end of the day they’re the foundation at which we can talk.” The Web as a platform for application development wasn’t in the cards 10 years ago, so the standards bodies need to reflect new realities, he says. “I’m not worried here,” he says. “Those are the people who are making it happen.”

Whatever the politics, the standards committees need to contend with the new technologies—and they are indeed addressing new issues. Mobile technologies have been around for a while, so standards work in that regard is already going full speed, says Abramatic; video is new and work is going on at the moment. But there’s plenty more to do. “There are other areas where we will need to see things happen: in the lower layers of the infrastructure, device independence, content adaptation. There are standards developing,” Abramatic says reassuringly.

The toolmakers envision problems—oh excuse us, challenges—in predicting and working with the next generation of Web browsers. But the browser vendors, aware of the same developer desires, have their own frustrations. We asked them to respond in the next article in this series, Web Browsers of Tomorrow.