Google Native Client X86

[Churchill]

Has anybody here played with said beast?

[VectraMan]

I played with it in 1995 when it was called ActiveX.

[NickFitz]

I played with it in 1995 when it was called ActiveX.

Netscape Plugin API

(Oh, and the first version of Internet Explorer to support ActiveX controls shipped in August 1996.)

[VectraMan]

I played with it when it was the Netscape plugin API too (that was crap!).

Leaving aside the facetiousness for a minute:

I think this is quite interesting. What they seem to be doing is allowing native code, but forcing you to link against Google supplied libraries instead of the standard ones to limit what you can do, and with a runtime that verifies that combined with some sandboxing (double sandboxing in fact) to trap anything they consider dangerous.

Which is great, but it's not really native in the sense of being able to do everything that a desktop program could do, and there's always some overhead associated with any kind of sandboxing or virtualisation. So compared to the likes of .NET or Java, this has the performance advantage of being able to beat JIT by writing your own hand optimised code, but the same disadvantage of being one stage removed from the system.

Probably a godsend if you need your website to calculate PI on the client end, but it's hard to see too many practical purposes that can't be solved in a better way.

[NickFitz]

The example they give of allowing complex image editing in the browser, rather than repeated round-tripping to the server at every step, sounds like a reasonable use case. There are many other such activities that a web application might want to provide as a service to users, without forcing them to go off to a desktop application and then upload the resulting file.

[VectraMan]

The example they give of allowing complex image editing in the browser, rather than repeated round-tripping to the server at every step, sounds like a reasonable use case.

Maybe, but that's for a relatively small amount of data. You wouldn't want to edit a video this way, as that would mean downloading and uploading the whole video file and potentially having the whole video stored in memory (can it even access the local hard disk?). Much better to have the server do the work, and have the client just show a visual representation of the current video frame.

One application I can see for this is local rendering of remote data, although Flash, Silverlight et al already have decent enough drawing APIs for most purposes so there may be little benefit for native code.

[jkoder]

The example they give of allowing complex image editing in the browser, rather than repeated round-tripping to the server at every step, sounds like a reasonable use case. There are many other such activities that a web application might want to provide as a service to users, without forcing them to go off to a desktop application and then upload the resulting file.

I think you would struggle to come up with any credible use cases outside of niche areas that couldn't be accomplished better by just using a desktop application.

id software have re-released Quake III using a similar or even the same technology, you essentially get to play the game in a browser but the game would run just fine, if not better on the desktop. Running this game on Firefox means you will incur the browsers memory overhead which is usually 100mb (depending on what I am doing ) on my machine. The only reason I can think of them doing so is that they also provide an interactive website with lots of game data and I guess they want everything to appear more integrated and maybe a little cooler.