Chrome Native Client (NaCl) allows you to write native code web apps.  Now you can use it for ARM processors and it is fairly easy. In the near future you will be able to create architecture-independent native modules - which might seem something of a contradiction.

Chrome has a number of features that make it special but the one that currently makes it unique is the ability to run native code. The idea is that native code is fast, compact and can do things that you just can't do in JavaScript.

There was a short time when Firefox could also run NaCl modules via a plugin, but Mozilla has said that it prefers to concentrate on making its JavaScript faster. This is, of course the alternative philosophy - don't go to native code; make JIT compilation good enough to use JavaScript as if it was native.

Equally obvious is that the disadvantage of native code is that it only runs on specific machine architectures. In the days when the x86 was the only CPU you would encounter, this wasn't a huge problem, but today most mobile devices use an ARM processor of one sort or another. So committing to native code implied that your app would only work on x86 system and generally not on mobile devices.

Now you can target both x86 and ARM processors writing in C or C++. You have to add a line to the manifest and recompile your module, but this is fairly simple. This just adds an ARM binary to the 32-bit and the 64-bit x86 binaries that are already produced. There is also a restriction to the Newlib standard C library. All you need to do is to make sure that you are using the most up-to-date SDK.

So can you now take your NaCl modules and run them on mobile devices? Not exactly. The problem is that the current Chrome for Android doesn't support NaCl at all. Only the Chrome browser that is part of the Chrome OS supports NaCl on ARM. This means that for the moment your apps will be restricted to Chromebooks.

For the slightly longer term future the Chrome team is planning a much bigger change:

"In 2013 the next generation of Native Client, called Portable Native Client, will introduce true architecture-independence by using LLVM bitcode as the wire format."

This will be known as PNaCl, pronounced "pinnacle" - and the idea isn't unlike the standard approach to running languages such as Java in a machine-independent way. The C/C++ is complied to an intermediate code called LLVM bitcode. The high level language is complied to a single portable executable which is downloaded to the browser without regard to the architecture it is running on. A small compiler embedded in the browser will compile the LLVM bitcode to the native code needed by the NaCl layer.

How is this different from, say, Java running in the browser?

It only really differs in the fact that the code is eventually compiled to machine code and in the efficiency with which this can be done. Once compiled the PNaCl code would run at the same sort of speed as NaCl code, but there would of course be a startup cost involved in the compilation.

All of this is going to cause many to say that PNaCl is little different from approaches that don't claim to be "native". And to an extent this is true. If at the end of the day JIT-compiled JavaScript runs as fast as LLVM bitcode then there isn't much to choose between them on grounds of speed.

What really matters is how much of the advantage of working with a true compiler these approaches can deliver. This is the browser version of the wider controversy concerning managed v unmanaged code that is currently destabilizing Windows programming.

What matters at the end of the day is the compromise between language sophistication and quality of implementation.

As far as PNaCl goes - the jury is still out.