Home >
Friday Google announced a new RIA platform called Google Native Client (NaCl). NaCl provides a browser plug-in that allows your browser to run C/C++ applications directly on your x86 processor. Google is releasing it as open source (BSD-style license) very early in its development (“release early, release often!”).
Google NaCl is a fairly major departure in terms of architecture from many other RIA technologies. Silverlight, Flex, JavaFX, and Ajax all execute in a managed environment which is slower than native C/C++ code but is also more portable across operating systems and computer chip technologies. However, given the fact that the three most common desktop operating systems (Windows, Mac, and Linux) all run on the x86 chip architecture, portability across chip architectures would appear to be far less important today than it was five years ago. (Unless, of course, you also want your code to run on other devices such as smart phones.)
Even as a research project NaCl is both exciting and scary. It’s exciting because it promises much better performance, which means that graphic intensive games, 3D, and data visualizations have more potential than ever. It’s scary because it reminds us of ActiveX - one of the most unsecure technologies ever introduced to the Web. But is the ActiveX comparison fair? According to Google the NaCl employs very different security architecture. While ActiveX allows downloaded applications free rain over the operating system (an ActiveX control only needs your permission to install and it can do anything a native application can do), NaCl depends on existing “trusted” libraries to execute operations that might otherwise be exploitable by hackers. This early release of NaCl is specifically targeted at security professionals who are most likely to identify at least some security problems.
So if NaCl is as secure as Google says it is, and it offers native runtime performance, it would probably offer an excellent alternative to many other RIA technologies. That said its been demonstrated that performance is not a primary driver for developer adoption in the mass consumer space. What matters to developers of mass consumer RIA applications is ease of development. That means a development environment that is easy to use, a language that is easy to learn, lots of prefabricated components, and a thriving ecosystem. None of which is available for NaCl. The fact that NaCl applications are developed in C/C++ (not exactly the language of choice for most RIA developers and designers) is a huge obstacle to adoption. Not only is C/C++ unfamiliar to most RIA developers, its also a tricky platform (pointers anyone?) with a steep learning curve.
Of course Google’s NaCl is not the only choice you have for native, or near native, runtime performance. Curl (note: the author works for Curl) has based its architecture on native compilation for ten years and is portable accross Windows, Mac, and Linux. In addition, Google Chrome compiles JavaScript code to native code. Programming in JavaScript is far more enticing than C/C++.
As Google will soon discover, the performance advantage, while important in the enterprise, is of little marketing value in mass consumer applications. Most developers don’t think of raw performance until they hit a wall with their current RIA technology of choice and by then it’s probably very expensive to switch technology platforms.
There is another problem that promises to be a big barrier to adoption for NaCl in the mass consumer market. The NaCl runtime environment is a whopping 22MB in size. For the Mac the largest runtime environments for RIA technologies prior to NaCl were Java (15MB), Adobe AIR (12MB) and Curl (9MB). The plug-ins for Flex ( 5.5MB) and Silvelright 2 (7.1MB) are even smaller. Ajax is a mostly zero install technology.
While NaCl provides enticing performance advantages, there is no guarantee that NaCl will become competitive or even reach a final release. Other, better-established, players have already saturated the mass market and enterprise developers are less likely to adopt a technology that is called “experimental”. So while NaCl is interesting it is not a shoe-in as a game changer. Still, Google is a force to be reckoned with and NaCl cannot be dismissed easily.




Facebook Application Development
I'm surprised this article did not mention Adobe's Alchemy, which converts C++ and C code into ABC (ActionScript Byte Code), to be run inside of the Flash Player. Adobe has been demoing it for the past year and at this year's MAX released it to the public on Adobe Labs:
http://labs.adobe.com/technologies/alchemy/
According to Adobe, C++/C code converted into ABC runs just 2 to 10 times slower than native C++/C code, which is an incredible speed boost for code running in the Flash Player.
followup @Matthew Fabb:
Adobe Alchemy reportedly even runs some things faster than if they were programmed in native ActionScript code.(!)
I think it's very true that "Most developers don’t think of raw performance until they hit a wall with their current RIA technology of choice and by then it’s probably very expensive to switch technology platforms." but I hope we see some really cool things being developed - could be the dawn of a new crop of browser games!
It's interesting to see a revival of C++ in the web, a bit ironic as it was mostly left for dead in that field. Let's see how it goes, but I for one don't feel like going back to that kind of programming
The potential for Alchemy is being able to use existing C/C++ libraries without having to port them to AS3. It is not to code in C and run it in Flash as that would be inefficient, just code it in AS to begin with. Plus there are plans to support as many languages as they can opening even more doors.
The Google Native Client seems geared towards making C apps run in the browser using the Internet as a delivery device. I suppose there are uses for that but I can't think of any reason I would suddenly stop Javascript or Flash development to pick up C again. Plus I would have some serious security concerns with this as they rightly point out. This would be code having full control just like any other app. If it weren't for security concerns then I would assume that Javascript and Flash would have much stronger capabilities by now as well.
To me, Alchemy and Google's Native Client (silly name) are comparable in what they do but not in what they are intended for.
I'm translating this article.
But it looks like there are some errors.
ActiveX allows downloaded applications free rain over the operating system.
rain => rein
NaCl is interesting it is not a shoe-in as a game changer.
shoe-in => shoo-in
I don't know for sure, but I think.
The true power of NaCl is that it can bring _any_ language to the browser. Web developers don't like coding in C++. However, whatever language they use (Ruby, Python, PHP) ends up executed in a more or less advanced interpreter (think /usr/bin/ruby on your server).
NaCl should provide native performance for compute-intensive applications so, bandwidth aside, there's nothing stopping me from coding my application in my favorite version of Ruby, and shipping my NaCl-compiled ruby interpreter to run it in the browser.
I know NaCl isn't there yet. But I'm looking forward to the day when I'll be able to choose my language, on both the server side and the browser side.
Hope this helps,
Victor