
Native Client: Getting Ready for Takeoff - mattyb
http://blog.chromium.org/2011/02/native-client-getting-ready-for-takeoff.html
======
noibl
Just like Wave, NaCl is an inspiring but highly technical innovation that
Google started trying to attract community interest in while it was still on
the drawing board. Mozilla and others have already turned their noses up at
it. What Google needs to do is finish the thing quietly, build something
spectacular with it, get lots of people using it, and _then_ casually slip
into the conversation that other browsers are welcome to use it.. if, you
know, they want to.. (then shrug nonchalently).

~~~
fierarul
I can't imagine anything more spectacular than running native code inside the
browser securely and across multiple OS.

Google is handling this just as they should and I can't see how else would you
introduce such a major piece of browser infrastructure.

This doesn't even compare to Google Wave.

~~~
noibl
Yes, it's 'spectacular' to you and I. I meant in the broader sense of
spectacle, the sense in which people on the street want to try it out because
it's like nothing they've ever seen before. And that is possible with NaCl if
expectations are properly managed.

~~~
StavrosK
We already know what the killer demo is going to be, Doom in the browser.

~~~
skymt
Doom 3 maybe. We already have Quake 2 running in the browser using WebGL
(<http://code.google.com/p/quake2-gwt-port/>), anything less would undersell
NaCl.

~~~
StavrosK
I was afraid of that, but yes, you're right. Doom is old enough to run with JS
already.

------
equark
The latest Mono 2.10 has NaCL support provided by Google. That means F#, C#,
IronPython and IronRuby, and Java through IKVM, should work with little or no
work.

This is a very exciting technical development but it remains unclear what the
killer application will be.

------
eddieplan9
I hope this is not ActiveX-sans-security-hole all over again. Native code has
the huge benefit of being native but also the huge drawback of platform-
dependent, which is a huge step backward for the openness of the Web. I only
hope the use of NaCl does not take off is kept to the minimum and the
absolutely necessary.

Even if they are talking about Portable NaCl, I have doubt about how portable
they can make it.

~~~
wmf
The "platform" for NaCl is x86, so the same code runs on OS X, Windows, and
Linux. pNaCl supports both instruction sets (x86 and ARM), so it's even
better.

~~~
eddieplan9
On ARM support, from their website:

> Native Client runs on 32- and 64-bit x86 systems that use Windows, Mac OS X,
> or Linux. _Some ARM support_ is implemented in the source base, and we hope
> to make it available for application developers next year.

~~~
othermaciej
At least with the current native client, you ship architecture-specific
binaries. So the existence of "some ARM support" doesn't help you browse a
site that posted x86 object code.

They do have a version that's based on shipping LLVM bitcode instead, but that
is not yet ready for prime time and it's not clear when it will be.

Here is a comment of mine from last time NaCl came up that explains this and
other issues with it:

<http://news.ycombinator.com/item?id=2057611>

------
blocke
This piece is essential to Chrome OS. It is the container for legacy code and
things where it'll be unrealistic for javascript to handle for years to come.

Countdown to SSH client functionality in 5... 4... 3...

~~~
wmf
Unfortunately, NaCl seems to have all the same protocol and same-origin
restrictions as JS, so you can't even open a frickin' socket.

~~~
blocke
Didn't Google pay for a student to the naclssh port as part of the code of
summer project?

Something tells me such limitations will be temporary...

"This allowed us to remove the expiration date and localhost security
restrictions we had adopted in previous research-focused releases.

We are excited to see Native Client progressively evolve into a developer-
ready technology. In the coming months we will be adding APIs for 3D graphics,
local file storage, WebSockets, peer-to-peer networking, and more."

~~~
wmf
AFAIK the security limits are intentional and when they add new NaCl APIs they
will have the same restrictions as the equivalent JS version of the API.
NaClets that run within an "app" instead of a "page" may be able to bypass
some restrictions, though.

------
alecco
Very cool. But I'm holding my breadth for the llvm version. Think mobile ARM.

~~~
InclinedPlane
On the one hand I think it's good for google to avoid "picking winners" before
there's any competition. On the other hand, I think LLVM support will be what
propels NaCl adoption.

------
jhuckestein
Soon your browser will be synonymous with your computer. There is a bunch of
projects that work towards that same goal \- Chrome OS + NaCl (another part of
their framework is called pepper) - WebOS - Various JavaScript SDKs
(specialized like Game Closure or heavyweight like Sproutcore or small like
backbone) I always found it inefficient to 'install' software in multiple
locations. It gives you a lot of headaches wrt updates, piracy etc.. I'm
excited to see where this goes! Notably not participating in the development
is Apple, but I have a feeling they may be working on something like this as
well (remember how the iPhone initially launched with just a JS SDK)

~~~
bonch
"Soon your browser will be synonymous with your computer."

This prediction is going on 20 years old. :)

------
olalonde
Their "Hello world" demo is kind of a turn off:
[http://code.google.com/p/nativeclient-
sdk/source/browse/trun...](http://code.google.com/p/nativeclient-
sdk/source/browse/trunk/src/examples/hello_world_c/hello_world.c)

------
MikeW
NaCl is disabled by default on the Cr48 development laptop. I would at least
hope this means they start enabling NaCl by default in the ChromeOS source
tree.

~~~
contextfree
The article mentions a clear criterion for flipping the on-by-default switch:

"We’ll also be working on Dynamic Shared Objects (DSOs), a feature that will
eventually allow us to provide Application Binary Interface (ABI) stability.
[...] Until the ABI becomes stable, Native Client will remain off by default.
"

------
cookiecaper
It's really a shame that JS has stuck around so long. Google is right to be
looking into allowing developers to create something usable in the browser
without having to use JavaScript or Flash.

Even Brendan Eich openly talks about JS's flaws and admits that it lacks a lot
of important things, mostly attributable because he had only a few weeks to
compose something to stop Netscape from doing "something worse". See
[http://www.jwz.org/blog/2010/10/every-day-i-learn-
something-...](http://www.jwz.org/blog/2010/10/every-day-i-learn-something-
new-and-stupid/) .

I greatly anticipate the day when I script a web page in Python instead of
JavaScript.

~~~
damncabbage
Mr Eich in the comments responding to someone accusing them of screwing up
Javascript and selling out:

"But at the time, mostly we felt the need to move very quickly, not to make
money but because we knew Microsoft was coming after us. Microsoft low-balled
Netscape in late '94, and the Jims (Clark and Barksdale) told them to pound
sand. After that, we felt the monster truck riding up on our little Yugo's
rear bumper, month by month.

"If you appreciate this and it is accurate, consider that JavaScript (please,
not "JScript") saved you from VBScript."

------
olalonde
What are the chances of this getting adopted as a standard eventually?

------
jlgosse
This is funny because I just opened a PSD in Gmail thinking that it would
throw some kind of error... but then it worked almost flawlessly! (albeit it
was missing layer styles, as far as I can tell)

