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
I was a little dismayed by the complexity of the modules themselves. One of Google's examples was a trivial module that could return a number to the browser and reverse a string of text. That simple demo comprised 306 lines of C source code and 101 lines of JavaScript and HTML. Admittedly, a lot of that was explanatory comments -- still, "Hello, world" it ain't.
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 <embed> tag in an HTML file, and then JavaScript handles the job of communicating between the NaCl module and the application running in the browser. All of the necessary files are hosted on an ordinary Web server, just like any other Web application. The server itself needs no special configuration; the MIME type of the .nexe files is specified in the <embed> tag.
Off and stumbling with NaCl
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.
Running NaCl apps is a little rocky. The first thing you'll notice is that there's a delay of several seconds before an NaCl module loads -- even when launching them from the local network -- and there's nothing displayed onscreen to let you know the NaCl environment is starting up. You can use JavaScript to query whether a module has loaded properly, but when it doesn't, there's no error message to indicate that NaCl had a problem. Much like when JavaScript errors halt an ordinary Web application, the app simply fails, and any JavaScript triggers designed to communicate with the NaCl module return errors.
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?
The obvious answer is that Google believes the ability for Web applications to take advantage of client-side CPU resources is a good thing. Being able to run computation-intensive applications in the browser is one reason why Google has worked so hard to accelerate JavaScript in Chrome. But you can only accelerate interpreted languages so much, and because JavaScript is a platform-neutral Web standard, it doesn't do a very good job of exposing hardware resources such as GPU acceleration.
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.
Another way to do computation in the browser is with Adobe Flash. Unlike Apple, Google has continued to support Flash across most of its platforms. But while Flash offers some GPU-accelerated special effects, its ActionScript scripting language is a derivative of JavaScript, so it has essentially the same performance ceiling when it comes to implementing custom algorithms.
Native Client fits somewhere in between all these alternatives. It doesn't try to replace the GUI capabilities of HTML, as Flash does. It's not the way to implement entire applications, as you might in Java. And it works in tandem with JavaScript, rather than replacing it. NaCl's intended niche is as a method of allowing Web applications to execute complex algorithms at native speed. Picture 3D modeling for scientific applications, for example, or running complex graphic transformations in a Web-based paint program.
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.