The important news on the Google front was the launch of Google Native Client (NaCl), which is Google’s attempt to allow the ubiquitous web browser to run web apps “natively”, allowing them to properly leverage the processing capabilities of lowly PC. What implications does this have in the short-term and the long-term? After mulling this over for the past day, I think this
Programming for the web browser has been an ever-shifting landscape. With web browsers running on a large number of hardware platforms and form factors, the hope of the “perfect” universal programming language has been elusive. Sun’s Java was hoped to be a very portable programming language, but has struggled to be widely adopted and has essentially lost the battle on the desktop, with modern web apps now being developed in a number of different tools such as Javascript (Google has been a big promoter of asynchronous Javascript or AJAX) and Adobe Flash (Flash games these days are getting pretty sophisticated these days). But browser-based web apps have clearly not fulfilled their potential, in part due to users not really trusting these apps to do anything serious or important in their day-to-day lives. In part, this is due to security, and Microsoft’s launch years ago of ActiveX allowed plug-ins writers carte blanche in doing pretty much anything they wanted with users’ systems, which made it a perfect entry point for… virus writers. In summary, each programming environment has its drawbacks.
Microsoft Silverlight (portable, proprietary, not compatible with legacy code)
Adobe Flash (very portable and very popular, runs well, but can’t run legacy code, and is only really used in browser apps)
Java (very portable, not very popular for web apps but very good in server apps, slow to load initially as it needs to download the entire app before executing, and can’t run legacy code. It is now open sourced which is good)
Javascript (very portable and very popular, performance is not ideal and Google’s Chrome browser was designed to help speed it up, but can’t run legacy code
Virtualization, allowing legacy code on modern PCs, is perhaps the easiest solution, allowing legacy compiled code to be runnable in a pretty seamless way, but virtualization introduces a great deal of overhead in terms of storage and processing, may not be portable to a mobile environment, and may not be secure.
Native Client works like a composite of these different environements, trying to combine the portability of a Flash or Java, the compatibility of virtualization, and with an emphasis on performance. Web apps that provide simple user interfaces work fine using Flash or Javascript, as seen in financial web sites from companies like Reuters or Thomson. I’ve been impressed with Google Apps and am amazed that the spreadsheet works pretty well, but understand that I wouldn’t want to be building complicated financial models using it – it would simply be too much to expect from a web-based app, for the time being. But what about the prospect of doing real work within a browser, such as editing graphics or video editing? While this seems preposterous, NaCl could enable these sorts of things, breaking the boundaries between traditional desktop applications and web applications.
Code re-use is an important characteristic of NaCl, and could help to prevent it from suffering the same fate that seems inevitable for Adobe Air and Microsoft’s Silverlight. It boils down to this: introducing a new portable platform is great in theory, but if programmers don’t adopt it and end customers don’t install the plug-in necessary to run them, then all that effort is flushed down the drain. With NaCl, it’s not a case where programmers need to re-write previously-released software to work with this new tool. Instead, NaCl simply re-compiles legacy C/C++ code (code that today can’t really be used in web browsers unless the user installs a dedicated plug-in just for that application). This is significant, because a Microsoft research team estimates that almost half of the code in the SourceForge repository was written in C and C++ – there’s a lot of free code open source software that’s not being leveraged in a web context.
But it’s still a plug-in. For end users to run NaCl projects, end users will still need to install a browser plug-in, which remains the bane of a number of environments. Adobe Flash has been a huge success not because of a technology advantage but due to its ease-of-use (browsers tend to come with some level of Flash out of the box), ease of upgrading, and users are familiar with Flash. A big barrier to platforms like Adobe Air and Microsoft Silverlight is that users don’t need them. The majority of multimedia content today runs on Adobe Flash, and personally, I’ll avoid sites that require Silverlight, which are few and far between (NBC’s Beijing Olympics site was one). Could getting end users to install the NaCl plug-in be a barrier to success? Absolutely. I suspect Google’s introduction of its Chrome browser was in part due to the prospect of NaCl, and with Google “giving” away a lot more free web apps to consumers, the trust factor for Google could run in the company’s favour as this plays out.
Does NaCl work? In looking through some research done by Google, it appears that the performance of the apps tested was about 10-12% slower than running without NaCl, which isn’t bad. The bigger question mark is whether NaCl is safe, and the answer is… maybe. The research time does make security a high priority, and highlights a number of techniques to accomplish this, from setting up double sandboxes (giving apps a safe area to access and then building a fence around the sandlot), and performing code validation to ensure that they don’t do anything “unsafe”. However, as with any system, we just don’t know what it is possible and not possible, as hackers tend to push the limits in breaking defences. Time will tell, in other words.
The longer-term prospects with this technology are interesting, as Google appears to be targeting not only the desktop opportunity, but also emerging platforms like mobile. In this world, the future remains very uncertain in terms of a common programming environment, especially with Microsoft .Net, Apple iPhone SDK, Google Android, Symbian, and Java all in use to some degree on various devices. Here, performance and security are even more important than on desktop systems, and ironically, Google’s Android uses a customized Java, while .Net, Apple iPhone, and Symbian are all in either some variant of C/C++. Is the time right for NaCl on mobile devices? We might be, with ARM-based CPUs popping up the latest wave of smartphones, from the Samsung-designed ARM-based chip in the iPhone, Qualcomm designed ARM-based chip on the Google G1 and BlackBerry Storm, and Nokia’s touchscreen 5800 “Tube” also going with an ARM design for its CPU. Is there be a need for a way of getting applications written for an iPhone easily portable over to a Google G1 Android phone? Definitely.
In summary, with the convergence of the major desktop systems (Mac, Windows, Linux) towards Intel x86 CPUs, getting code to run on all 3 systems has been a matter of compromise between performance, security, and cost. With this first step in Native Client, Google is offering the common web browser as the conduit to making the job of the software developer much easier, while leveraging years of legacy code to improve the capabilities of web apps in general. In a sense, this announcement should be viewed not so much as an attack on virtualization (Microsoft, VMWare, Citrix) but rather the old web apps vs. desktop apps argument. And historically, companies like Adobe and Microsoft have absolutely feasted on their ability to keep desktop apps firmly off-line, and the state of Microsoft Office today (how different is it from 5 or 10 years ago) and arguably the same can be said for Adobe’s Creative Suite. At the end of the day, NaCl could open up web apps to entirely new level of desktop performance, and while this doesn’t mean an overnight transformation of the capabilities of web apps, it does open up Pandora’s Box to some degree.
If this sounds terrible to Microsoft, this development is clearly not a surprise to them, and a Microsoft research team this year announced its own initiative in this regard called Xax, which appears to be almost the same as NaCl though it was simply a presentation of theory. I wouldn’t be surprised if Microsoft hasn’t already patented a bunch of these techniques already, in anticipation of either profiting from this move towards native apps within a web browser, or as they did in introducing “Microsoft Java”, helping to control its progress. For Google, this announcement is a positive in my view because it shows that it continues to be serious in trying to develop one more pillar to generate revenue, and along with Google Gears and Google Chrome, should help to make web-based apps more functional, all part of Google’s strategy to make the web browser the new operating system of the future.
