Google Native Client: The web of the future - or the past?

This time, it's Mozilla v Google

Common Topics

Opera man says no to Salt and Pepper

Native Client plugs into Google's Chrome browser via a new API Google calls Pepper. Google has always used "NaCl" as a diminutive for Native Client, and inevitably, it plays off the word "salt" when naming complimentary technologies. Pepper replaces the longstanding NPAPI browser plug-in interface that was developed at Netscape, and the idea is to securely provide Native Client programs with access to all the same browser tools that JavaScript developers have access to.

"Our goal is to have an execution arm that can have no side effects – zero interaction with the outside world – and that's what we think we have achieved with the sandbox," says Brad Chen. "But the thing is that if you can't interact with the outside world, including the browser, you can't actually do anything. That's where these Pepper interfaces come in. They're designed to expose to Native Client exactly what is also being exposed via JavaScript."

The addition of Pepper, says Greg Morrisett, potentially creates more security concerns for the technology, but Google believes Pepper is far safer than NPAPI. The company based the original version of Pepper on the old Netscape plug-in API, but it has since rebuilt the technology from scratch.

NaCl

Google has already used the Pepper API to integrate Adobe's Flash Player with Chrome, and later this month, it will turn on Native Client in the stable version of the browser, opening the doors wide to third-party native applications.

This doesn't make Flash part of the web, and it doesn't make Native Client part of the web either. Native Client hasn't been integrated with other browsers. It hasn't been standardized. And it requires compilation on a specific instruction set. In addition to the x86 version, Google has built versions for 64-bit x86 and ARM, but this still falls short of a web that runs on any device.

Google is well aware of this, and in an effort to alleviate the problem, Linus Upson says that when Native Client launches, Google will only allow Chrome to run Native Client applications that have been compiled for all available processor platforms. Chrome will only accept Native Client applications distributed through the Chrome Web Store, and Google will only allow Native Client apps into the store if they're available for both 32-bit x86 and 64-bit x86 (the ARM version of Native Client is not yet ready for prime time).

"We don't want to bake one instruction set into the web," Chen says. "If it's in the store, we can – through policy – make sure all future architectures are supported too."

Håkon Wium Lie

But the ultimate plan is to create a new version of Native Client that can run on any processor. This Portable Native Client – PNaCl, pronounced "pinnacle" – is already under development. Basically, instead of generating x86 or ARM code, this version will transform native code into bitcode using a compiler based on the open source LLVM (low-level virtual machine) project. When the browser downloads the bitcode, PNaCl will then translate it to machine code and validates it in the same way Native Client validates machine code today.

This could potentially give Native Client the same reach as JavaScript. But there are still hurdles to leap. Part of the problem is that Portable Native Client requires more overhead. Currently, Upson says, PNaCl can generally execute much faster than JavaScript, but it does not yet start up as fast. Before officially launching PNaCl, Google wants to ensure the gap is closed. But even if it does outperform JavaScript, it may not win a place inside other browsers. Apple and Microsoft have yet to weigh in on Native Client, but Mozilla and Opera are openly opposed to the idea.

"NaCl seems to be 'yearning for the bad old days, before the web', to paraphrase Tim Berners-Lee," says Berners-Lee's former colleague and not-quite-namesake Håkon Wium Lie, who now serves as Opera's chief technology officer.

Mozilla at the gates of DLL Hell

Wium Lie believes that despite the performance gains offered by Native Client, browser makers should stick to improving the existing web standards, including HTML, CSS, and JavaScript. "The web platform has everything we need to do everything people want, and if there's something lacking, we should fix the web platform rather than go out and build a new platform," he tells The Register. "And that's really what Native Client is about: building a new platform – or porting an old platform into the web. I don't see the need for it. It will just bring in complexity and security issues, and it will take away focus from the web platform."

Simpler, he says, is better. "HTML won because of simplicity," he continues. "It's easier to teach people when things are simple. It's easier to deal with security when things are simple. If you add another platform, that's more for the security experts to look over."

Web standards need expanding, he says, pointing to the new WebGL standard as an example. But that's very different from allowing native code into the browser. "WebGL gives us an interface to the hardware, to graphics processors. But we don't need binary code. That's another beast," he says. "Native Client lets you run legacy games. But it's not worth it."

His view not only contradicts Google's message, it contradicts Google's terminology. For Wium Lie, Native Client is not the web. For Google, it very much is. For Opera, Native Client is a browser plug-in. For Google, it's part of the browser, something very different from Java or Silverlight.

"We don't want to go back to a place where it's just binary delivery over the internet. We've seen people try to do it before."

– Chris Blizzard

Mozilla makes many of the same arguments as Opera, and then it goes a little further. With JavaScript, says Mozilla open source evangelist Chris Blizzard, you can improve the performance of a program simply by improving the browser that sits under it, but that's not the case with Native Client. "The promise of the web is that it's cross-platform, that it's source driven, that it evolves with time. Native Client doesn't actually solve any of those problems that the web actually solves," Blizzard tells us.

"Once you download the native code, there's no opportunity for browser optimizations. There's no opportunity for all kinds of things. You have to keep in mind that the evolution of browsers over the last several years has been that we have made a 10X improvement on existing sites. The evolution of browsers has made everyone's applications faster whether or not you've updated that site in X number of years.

"With Native Client, all of that disappears. The fast innovation we've seen on the web disappears. A source code–based world means that we can optimize things that the user hasn't even thought of, and we can deliver that into their hands without you, the developer, doing anything."

But Blizzard also points out that native code is, well, native code. "What are you going to do about version compatibility? What are you going to do about DLL hell? What are you going to do about Lib C hell? There is reason why Microsoft's operating system has continued to bloat over time and they have to ship multiple versions of things and they have to worry about backwards compatibility. We experience those problems too on the [browser] add-on side. Binary add-ons are more difficult for developers to update.

Chris Blizzard

"All of these things exist in the native code world. It's not a world we want to see. We think the web is a step forward. We don't want to go back to a place where it's just binary delivery over the internet. We've seen people try to do it before. Microsoft's ActiveX is one example. Native Client may have better security properties, but it's reasonably similar."

Native Client is often compared to ActiveX, Microsoft's ill-fated effort to equip browsers with software controls written in C++, Visual Basic, and .NET, and it's not a flattering comparison. ActiveX was a notorious security hole, enabling an epidemic of malicious drive-by-downloads on Microsoft's Internet Explorer. But Blizzard's comparison goes beyond security. Even if it's secure, he says, Native Client isn't a good thing.

Much like all those developers at Hacker News, Opera and Mozilla blend the technical with the religious in making their arguments. But even the religious can't be discounted. After all, developers and browsers makers drive the web. Mozilla still controls a good 25 per cent of the browser market, so even if you don't agree with its stance, its stance matters. If you code for Native Client, many developers will say, you'll reach only a portion of popular browsers – and you'll further fragment the world of online apps.