Google x86 Native Browser Client Maybe Not So Crazy After All

GMGruman writes "Google's experimental technology to run native x86 binaries in the browser shows lots of potential, writes Neil McAllister. He's previously said it was a crazy idea, but a new version of Native Client (NaCl) caused McAllister to take a fresh look, which has led him to conclude the technology is crazy like a fox. McAllister explains what NaCl is useful for, how to use it, and why it's not a Java or a Flash or a JavaScript replacement, but something else."

NaCl + GAE

[rumith]

Can't wait for this thing to get hooked to App Engine once they are both stable enough. The results will likely be breathtaking, to say the least.

Re:Why????

[Ancantus]

If you havn't noticed, one of Google's intents is to make the browser you go-to place for all your needs (kinda makes sense with their business plan). And honestly i think that it is a worthy goal. This way people can make cross-platform applications and a way to distribute them all on one platform.

Re:Light on details

[slart42]

NaCl in it's current implementation is not JIT compiled. It is actual compiled native x86 (or x64 or arm) code running in a secure sandbox. What causes a delay is the Validation of the code, ie, the code has to meet certain requirements to be secure. That said, Google has plans for PNaCl, "portable" nacl, which indeed uses LLVM bytecode, making it a JIT implementation. Why not just use JavaScript? Having access to a lower level language and to being able to reuse tons of existing code is a big plus. Think porting existing game engines to the web.

Re:Light on details

[pclminion]

How well does the validation engine cope with code that's deliberately obfuscated? I don't know for sure, but I suspect that proving code is safe using static analysis is probably NP-complete. Dynamic instrumentation would make it much easier to implement sandboxing -- all operations which aren't explicitly permitted are forbidden, and you simply stop the code when it tries to do one of those forbidden things.

Re:ActiveX revisited?

[suy]

You probably should start reading about it first, please. The browser doesn't allow you to run native binaries of the system, or native code in general. It allows you to run very constrained routines in assembler code, but a very limited set of instructions, only the ones that can be secured enough. That's why you need an specialized SDK: the generated binaries have to use a very reduced set of machine instructions.

The great benefit of this, is that the generated ".nexe" files are portable accross operating systems. Basically, is a way to run heavy routines in C/C++ instead of JavaScript. The API is limited too.

It's pretty cool in the sense that you could do fancy graphics or UIs without Flash or Silverlight. You could write them in Qt or GTK+ or SDL, and the generated executable works on every OS (you'll need a recompile for ARM phones though).

If it can be refactored to a plugin for every browser, this will be the best Flash/Silverlight killer ever.