Google Native Client: The web of the future - or the past?
This time, it's Mozilla v Google
Opera man says no to Salt and Pepper
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.
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.
"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
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
"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.
"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.
Sponsored: Data Loss Prevention & Data Theft Prevention