There are already about a hundred schools of thought contending over the worth of Google's new Native Client ("NaCl") technology.
NaCl (inevitably punned by the Googlegentsia) is a way of allowing native-code (raw machine instructions, instead of an interpreted language such as the currently-standard JavaScript) to execute in your browser. As such it is painfully reminiscent of Microsoft's ill-fated attempt to add ActiveX controls to the browser, a move resulting in so many security breaches that it contributed significantly to the mass developer move away from Internet Explorer.
Some critics contend that NaCl will is merely a rerun of ActiveX and will suffer the same fate. However, unlike ActiveX, Native Client is not restricted to a single operating system, and although currently implemented only in one browser, Google's own rapidly-growing Chrome, it is open source and available for incorporation by other browsers if their developers so desire. As such, Native Client would run on whatever operating systems a given browser does.
A more serious criticism is that NaCl is currently restricted to a single chip architecture, x86-class code, meaning that it won't run on your mobile phone or tablet's browser, as those machines are currently almost all powered by ARM cpus. Google already have an answer to this in the works, based on compiling your C or C++ source down, not to native instructions, but intermediate-level LLVM bitcode. This is where the story starts to get hazy. Will the bitcode get further compiled, and if so when? In the browser? By the web server? It has even been suggested that Google may end up writing a virtual machine to execute LLVM bitcode directly. Shades of Java, why not just use that? — Indeed, your humble blogger remembers writing a post on the Mozilla developers mailing list about a decade ago, advocating exposing Mozilla internals to Java, so that people could write internal-level stuff using Java (which almost everybody could do) instead of C++ (which relatively few people could do), an idea which sank immediately and without trace; but that's another story.
The security angle seems much better thought out. Google are determined to sandbox the native code inside the browser, and seem to have invented a clever way to check and enforce that sandboxing. Said clever way relies on features of the x86 chip family though, and again, the concern must be that similar ways may not be so readily found for other chip families.
The least convincing criticism, I find, is that Google should have spent this effort on implementing the complainer's favourite interpreted language instead, because it's allegedly so much better than JavaScript. Candidates include the usual suspects: Python, Ruby and Lua (though I actually don't remember anyone proposing Perl). The people who make this criticism seem to me not to be one hundred percent awake: the goal of NaCl is to make browser capabilities that are available to JavaScript also be available to C and C++ programs (initially, with other compiled languages later, perhaps). Now if your NaCl program were to be ... a Python interpreter ... a Ruby interpreter? See how that might work? By doing the larger job, Google have automatically provided for the smaller job. Now, all we have to do is get responsible people in the Python, Ruby, Lua and whatever else camps to hook their interpreters up to the Native Client APIs, and a hundred browser languages will blossom,
No comments:
Post a Comment