Web Browsers of Tomorrow

Throughout this series of articles, we’ve examined the developer toolmakers’ predictions about the next generation of application development. What do the browser makers say about their readiness for the future of Web development? Here’s how Microsoft’s Dean Hachamovitch, general manager of Internet Explorer, and Mike Schroepfer, Mozilla’s VP of engineering, responded to the key issues our experts raised.

What about Apple’s Safari? According to an Apple PR representative, “Apple does not comment on future products or product plans,” so we have no visionary willing to go on the record. However, Apple’s Safari browser is based on WebKit, an open-source Web browser engine, which is also the engine used by Dashboard, Mail and other OS X applications. WebKit’s HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE. Recent features added to WebKit, which “will likely make it to an official release someday,” include Web fonts, client-side database storage, CSS transforms and CSS animation. They aren’t standing still; they just aren’t talking.

First, don’t assume that the browser will be replaced by another technology. “The browser is not going to disappear from the landscape anytime soon,” says Hachamovitch. Moving the browser forward is the IE team’s core challenge.

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<<

But browser technology needs to evolve. “The browser as document renderer is long gone,” says Schroepfer. Browsers, he says, are well understood for documents, but not well understood for more dynamic applications. On the positive side, you can make an online application do just what you want, “even if that isn’t the right thing for 130 million people.”

The Balancing Act

The browser vendors have a tough row to hoe: “We have to be compatible with the past and compatible with the future,” says Hachamovitch. For IE development, he says, “The central challenge I see is how we enable great interoperability and security and performance—because those things are often in conflict.” If the browser vendors aren’t careful, he points out, new features can destroy compatibility.

For browser developers, the notion of “trustworthy” is incredibly important. Not just security, suggests Hachamovitch, but larger issues such as coping with security certificates. With Internet Explorer 7, for example, 900,000 phishing attempts are blocked every week. “I’m putting compatibility and interoperability at the top of the list,” says Hachamovitch. “Trust is right behind it.”

Schroepfer agrees: The weak link is trust. That puts more responsibility on the Web browser to know more of what’s going on, to present information to users so they can make decisions, and to make them more aware of the consequences of their decisions. Much of this, he says, is a matter of education; while socially we may prefer to give users a choice, most of the time that’s giving them enough rope to hang themselves—what Schroepfer calls the “yeah, whatever” click-through.

One way to address this under consideration uses peer-to-peer knowledge or collaborative history of a site—but that raises new problems. Browser vendors have to take a stronger stance with malware as a result. Schroepfer says, “It’s an area where we need to be braver; for the vast majority of users, [these security features are] the right behavior. Out of the box we’ll have it work that way, but you can turn it off.”

One security challenge for browsers—for today and tomorrow—is the way developers learn new techniques and exchange ideas: Are they copying the right source code today, the right patterns? From the earliest days of the Web, programmers clicked on View Source to discover programming tips. “This enabled everybody to have a website with dancing hamsters,” says Hachamovitch. Developers learn from and copy each other’s source code. But warns Hachamovitch, “If that procedure had a security problem, or the developer didn’t understand an information disclosure issue, that code infected a lot of websites.”

Serving the Developer

Developers want to have an easy, straightforward experience writing great applications. Too much time is spent in Web developers optimizing applications to make them work right on a given browser—or even to make the app work at all. They want to spend their time adding value, not dealing with subtle technical differences between implementations. And they don’t want to have to start over when a new technology becomes available. That means investments in the pipeline between development and production. “Compatibility is hard to demo,” says Schroepfer. “It’s not a sexy thing; it’s a hygiene thing. But it’s what permits the Web to be successful long term.”

The browser creators are aware of developers’ challenges, and that it’s hard to do more using current technology. Schroepfer ticks off a few of the issues on his fingers: There’s the deployment model, the need to decouple parts of the infrastructure, the choice of vendors. “We have to make sure the platform is ready for the app, and that the platform is amenable to the apps,” Schroepfer says.

He’s leading Mozilla’s development of the Firefox browser with the expectation that developers need the next round of Web technology to offer better offline support, improved vector graphics and more powerful programming languages. He, too, sees a future in mashups and online video.

Plug-ins and frameworks shield developers from the implementation detail so they can focus on building the application. Yet, plug-ins hold their own set of problems: How much code will users download? Will they eventually conflict with one another? Schroepfer isn’t too worried. “They’re a really important vector for getting functionality into the browser,” he says. He also points out that historically, there have always been ways to add “mini functionality” to the browser, and often those were proprietary solutions. “But it doesn’t have to be “antagonistic to open standards,” he says.

All the technology advances mentioned in other portions of this article package, such as the merging of Web and desktop client and tool evolution, are important to the browser vendors. “It’s easy to say, ‘I want it to work offline,'” points out Hachamovitch. “Sure, we can put in things to put into browsers and frameworks to make it possible to persist offline. But the larger, harder challenge” is making the software know what to do. Does the person writing the app do all that intelligence on both the client and the server—in ASP or Perl or whatever? “Yes, we provided the tech capability to store data offline,” he says, but it leaves a lot of hard work for the developer to connect those dots and to answer difficult questions. Do I need to set policy? As an end user, do I want to do that? Should a Web application be able to share bank info with Facebook? “That’s why we’re engaging with the community of developers the way we are,” says Hachamovitch.

Developers should be part of the discussion. “Developers need to participate in the evolution of their platform proactively,” Schroepfer says. They can participate in helping the process, he says, and they have an important stake in doing so.

Next: Back to the beginning, Beyond Ajax: Software Development, Two Years from Now