Google: We'll prove Native Client's worth on the Web

Native Client has taken only baby steps in its first three years of existence, but Google evidently is hoping its browser-boosting technology will take larger strides soon.

The company has sent out invitations to a Native Client event on the evening of December 8 at Google's Mountain View, Calif., offices, where "we plan to share some news about Native Client," show some demos, and share some wine.

Native Client, aka NaCl, lets Web-based software run natively on x86 processors--and therefore run more quickly than traditional Web apps. That's what Office and Photoshop do, too, of course, but NaCl comes with security protections designed to let people safely run software they just downloaded over the Web, not just trusted software they install themselves.

NaCl now is built into Google's Chrome browser. But because other browser makers range from uninterested to disapproving, NaCl doesn't show many signs of extending any farther at present. Its future therefore hinges on how well Google can generate programmer interest and excitement that will bring others on board.

"It's great technically, but it's only running on Chrome," said David Helgason, chief executive officer of Unity Technologies, in a recent interview. Unity plans to support NaCl with its cross-platform videogame development technology.

"Now they're really close to being ready, and so are we. It's great technology, something we hope other browser vendors would adopt," Helgason said. "It's the ideal way of putting rich content and game engines in the browser."

But winning over those allies won't be easy for Google--in particular with the improvements in the incumbent programming technology for Web apps, JavaScript.

"We're not sure it's really needed," said Jan Standal, vice president of desktop products for Opera Software, of Native Client. "In many ways, JavaScript is becoming ridiculously fast. With what we observe with JavaScript, we're not sure we're going to need the next level beyond."

Native Client's advantages
Ordinary Web apps, written in JavaScript, run slowly but safely on a software layer called a virtual machine, but NaCl permits lower-level access by screening out any programs that use banned commands and by confining software to a sandbox. Programmers who want to try it out only can distribute NaCl software through Google's Chrome Web Store for now.

Native Client has promise as a way to expand what browsers can do--for example, to run physics game engines fast or to boost Web-based video chat with a new high-performance encoding technology. For example, Zipline Games' cross-platform Moai game foundation now can reach Chrome through NaCl. Using NaCl developer tools, existing programs and software libraries written in C or C++ can be rejiggered for NaCl.

One example of a Native Client application is SodaSynth, a very basic synthesizer Chrome app that can create looping music melodies. The app's developers boast, "The lowest-latency keyboard on the Web!"

And Google, which sees NaCl as a security technology, is rebuilding parts of Chrome itself out of NaCl.

Not an easy sell
The biggest barrier to NaCl's success so far is the lack of support from other browser makers.

Without that, NaCl runs the risk of introducing a technology to the Web that fragments it as a programming platform. After years of concerted effort, browser makers and Web developers are only now building HTML, CSS, and JavaScript into a heavy-duty foundation to rival proprietary alternatives such as Adobe Systems' Flash and Microsoft's Silverlight.

Those plug-ins require browsers to have an interface such as NPAPI (Netscape Plug-in Application Programming Interface). Native Client needs an interface, too, but NPAPI isn't up to the challenge, so Google created a new one instead called Pepper. (NaCl is the chemical abbreviation for sodium chloride, more commonly known as table salt. Get it? Salt and pepper.)

But as the Web matures--and as Adobe scales back its Flash Player ambitions--plug-ins are being put into the doghouse.

"There's no way browser vendors are going to carry NPAPI support forever, or add any new NPAPI features now, just to run Java and some other relatively little-used plugins," said Mozilla programmer Robert O'Callahan in a personal blog post. "Eventually we'll be able to disable plugins and rip out a lot of code."

And Microsoft barred plug-ins from the version of Internet Explorer 10 that will run in the new "Metro" interface of Windows 8. "Plug-ins were important early on in the Web's history. But the Web has come a long way since then with HTML5. Providing compatibility with legacy plug-in technologies would detract from, rather than improve, the consumer experience of browsing in the Metro-style UI," Microsoft said.

Without a plug-in interface, Native Client would have to be built directly into the browser to work. That's an even greater challenge than convincing browser makers to update their plug-in interfaces to accommodate NaCl's needs.

And allies are hard to come by.

"NaCL in its current is actively bad for the Web because it enforces hardware platform lock-in," Mozilla programmer Boris Zbarsky said in a personal opinion on a Mozilla mailing list. Lock-in refers to the fact that NaCl today requires computers using x86 chips--the variety Intel and AMD sell for use in personal computers. "We (Mozilla) should certainly not be supporting it; we should be opposing it, because it is the antihesis of what we stand for."

The mobile challege
NaCl requires an x86 chip today. Those are all but nonexistent in tablets and smartphones, though, and attracting programmers to NaCl will be harder if those programmers are shut out of the hot and fast-growing mobile segment.

Google's solution to that problem could help allay Zbarsky's lock-in concern: on a variation called PNaCl that brings Native Client to the ARM processors that dominate the mobile realm.

PNaCl, which stands for Portable Native Client, uses a technology called LLVM (low-level virtual machine) that makes NaCl client code portable by adding a new layer to the execution process.

Instead of a NaCl program being translated directly to the machine-code instructions a chip understands, as with NaCl, the program is translated first to an intermediate "bitcode." A virtual machine then runs the bitcode on the ARM device by translating the instructions into native instructions for the chip. That hurts performance, but Google still thinks it'll be worth it.

Of course, there's more to getting a standard into the Web than building the technology. Zbarsky, for example, remains concerned that even with PNaCl breaking the hardware lock-in, the technology still is Google's baby. It's open-source, but it's "not open contribution and not open control," he said.

JavaScript
Perhaps the biggest NaCl challenge is JavaScript itself, though. Fueled in part by competition with Chrome, other browser makers have been working hard on speeding the performance of Web apps written in the language that today supplies the Web with the ability to think.

And it's not just JavaScript. Google--willing to back multiple horses--also has a JavaScript language alternative called Dart.

One of Dart's performance advantages comes from the fact that it uses "typed" variables. That means that when programmers declare a variable, they must say what type of variable it is--a string of text or an integer, for example. That declaration means that the compiler, which converts the human's program into machine-readable instructions, can produce a much more efficient software.

But Mozilla is bringing to market a new feature for its "SpiderMonkey" Firefox JavaScript that does some of what Dart does. The new IonMonkey just-in-time compiler includes a technology called type inference that lets the browser figure out variable types, even though JavaScript itself doesn't require programmers to do so.

It's unclear how well JavaScript will overcome performance challenges--and which other browser performance bottlenecks will hold back Web apps.

It's clear, though, that tremendous energy is being poured into the problem. Each advance helps millions of Web pages already built with JavaScript. It's got an incumbent advantage that's hard to beat, and that's probably Native Client's biggest challenge.