Anyone played with Google Native Client at all? Is it any good?
I hadn’t really paid much attention to it before, but have just been browsing through what it can do and started thinking it’d be quite neat to be able to embed juce apps in the browser. Any thoughts/opinions…?
It’s doubtful that Native Client will be on any non-Google browser any time soon. Both Mozilla and Opera have expressed disinterest in it.
However, even with only Google supporting it, you still get three great targets:
Google Chrome Browser
Google Chrome OS
Android
Whether Chrome OS will actually take off is another thing, but if want to run JUCE apps on Chrome OS, it should be possible and Native Client is the way.
I was under the impression that there is already a NPAPI plugin hosting NaCl for other browsers… ?
I believe that NaCl apps will be the next big thing 
There used to be, when NaCl was an NPAPI plugin.
Google has since transitioned to a more powerful API: PPAPI. This API is currently only supported by Google Chrome.
It’s a nice idea, and certainly seems to me like it could be “the future” of running code in browsers if it gains enough acceptance. Haven’t got time to do a juce implementation for it right now, but will certainly keep my eye on it…
To me, the next big thing is ARM everywhere, and Linux everywhere (except for those/us using the iBrainfart devices).
In that case, NaCl might not be as “universal” as it seems, since it’s native (I know about the ARM port, but it’s still native, so not compatible with x86).
They have started PNaCl (Portable Native Client), using LLVM as the “binary” format, but in that case, I don’t get the point compared to Java or .Net, with JIT mode.
I bet that tablet’s hype will fade down in the next year, people will realize a computer is required to actually work (and type on a real keyboard is more adapted to this task), but at the same time, the price/power ratio for ARM chip will overcome x86 CPU, and most PC will start using ARM as their main platform.
It’s the portable native client stuff that grabbed my attention - because compared to a VM, it’s much more versatile. You’d be able to compile any language to run on PNaCl, but compiling non-garbage-collected languages to run on things like the JVM would be extremely inefficient, or even impossible.
Well, you can already compile any language (including Java) to LLVM bytecode and then later convert to binary or JVM bytecode if you want. Garbage collection is not in the bytecode interpreter, but at the classpath level.
What I was saying is that PNaCL would not be any faster than Java or .Net since the JIT/compilation task is still required.
So if you have slower code than native one (like Java) and still have to deal with memory issues (unlike Java), I wonder what is the real interest of the beast, in that case.
And unless I’m misunderstood, you still need to rewrite your code for NaCL because you still need to cross compile it, and remove all calls to native syscall, like …fopen/read/write/select etc…
