Last week, Google announced a new version of its SDK for Native Client (aka NaCl, in a riff on the chemical formula for salt). For those who don't recall, NaCl is the technology I once called "Google's craziest idea yet." In a nutshell, it allows developers to deliver code modules for Web applications in the form of native x86 binaries that execute on the user's bare CPU -- no interpreter, no virtual machine, no nothing.
I called the idea crazy, but it's really crazy clever. As Native Client continues to evolve, I thought it was high time I checked under the hood to see how this nutball idea actually worked in practice. To that end, I downloaded the new SDK, fired up my toolkit, and put a few of Google's demo NaCl applications through their paces.
[ Peter Wayner explains how to develop HTML-based mobile apps and escape the app store. | Stay up to date on the key programming news and issues with InfoWorld's Developer World newsletter. Sign up today! ]
Old tools for a new kind of Web app
Once compiled, NaCl modules are not ordinary executables. They carry a .nexe extension, and they won't run on the server itself or anywhere outside the NaCl environment. The upshot is that it doesn't matter what platform you develop them on; I built the SDK's examples on a Linux workstation and served them to a Windows 7 client with no hiccups.
Hosting modules is relatively straightforward, if a little cumbersome. Each module must include a manifest written in JSON that identifies the various files associated with it. The module must be invoked using an
Off and stumbling with NaCl
To see NaCl apps in action, you need a browser that supports Native Client. For now, that means Chrome 10 or later, and you need to explicitly enable NaCl, either with a command-line option or through Chrome's experimental features panel. Once NaCl is enabled, Chrome warns you that security and stability will suffer -- don't try this at home, kids.
One gotcha is that while NaCl modules are platform-independent, they are not architecture-independent. All the examples included with the SDK compile to two separate .nexe files: one for x86 and another for x64. Google has said it plans to have NaCl running on Chrome OS devices at some point, so presumably you'll need to maintain a third binary for the ARM architecture if you want your module to run on those.
As it stands, you can't run 32-bit modules on a 64-bit PC. NaCl detects the architecture automatically and requests the appropriate version of the module. If it's not found on the server, the application fails. Merely commenting out the path to the 64-bit module in the manifest file was enough to make the demos fail on my Windows 7 x64 machine; trying to fool the system by specifying the same binary for both architectures didn't work either. The really interesting thing was that the version of Chrome I was using for testing was itself a 32-bit application; even so, NaCl would only accept module binaries built for x64.
When the demo apps launch, they're not that exciting. The code runs like it's supposed to, but the demos are short on visual frills, and the routines they execute are trivial. A while back, Google made a lot of hay about a version of the 3D arcade game Quake running in the browser, but that demo no longer seems to work with the latest Chrome/NaCl builds. What we're left with are a bunch of simple exercises that remind me of nothing so much as -- dare I say it? -- Java applets, as they debuted in the late 1990s.
Is Native Client really necessary?
So what is NaCl good for? And why do we need it to build ugly Web apps when we've had Java applets for years?
Java handles that sort of thing reasonably well, but Java is a heavyweight environment for running the small snippets of client-side code Google envisions, where most of the application still lives in the cloud. Users must also have Java installed before they can run Java applets, unlike native code. And Java, of course, depends on Oracle, whose commitment to client-side Java is unclear.
Mind you, we're still a long way from delivering Photoshop in a browser window. As it exists today, NaCl is still very rough around the edges, and the available audience for apps that use NaCl modules is pretty much nobody. Still, NaCl remains a fascinating technology -- one that's well worth watching if you're interested in future directions for the Web.
This article, "Inside Google Native Client for x86 binaries," was originally published at InfoWorld.com. Track the latest developments in programming at InfoWorld.com, and for the latest business technology news, follow InfoWorld.com on Twitter.