Native Client: Getting Ready for Takeoff | Hacker News Reader

Native Client: Getting Ready for Takeoff

blog.chromium.org

100 pointsmattyb44 comments

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).

I wonder how people would react if a different company did something like that with their browser.

There are a couple of companies you could be talking about. If you mean Apple and their development of the KHTML engine into something that has been embedded in lots of other software with hugely beneficial effects for the web, then yes, good precedent. If you mean Microsoft and the distribution of Silverlight, the connection is somewhat more tenuous because Silverlight is a solution in search of a problem.

Note the distinctions: open source, platform agnostic, solves a real problem.

Silverlight and Native Client solve the same problem, they just do it differently (and you could argue Native Client solves it 'better').

I assumed the parent was alluding to ActiveX.

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.

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.

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

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.

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

People on the street are not interested in browser implementations and are therefore not the group which needs to be impressed in this case.

Google should tune into WIIFM: http://larryborsato.com/blog/2010/01/wiifm/ ...what exactly is the end customer going to do with this?

If the end customer is developers, then yes, it's interesting and google should promote it heavily at something like GoogleIO or other dev venue.

If it's for customers, it's going to need a killer app.

(edited to remove anchor tag)

I suspect games will be the killer app for this, though the barrier to in-browser games is getting lower all the time with hardware-accelerated canvas becoming the norm. Nonetheless, high end games will probably continue to require native hardware access for the foreseeable future. You can't exactly build Call of Duty in JavaScript+Canvas or WebGL or whatever.

Many people thought replacing email and IM with some grand collaborative technology would be spectacular too. A lot of articles were written about Wave, breathlessly reciting the history of email in their opening paragraphs as if it was already a given that Wave was a successor of equal magnitude.

I'm not convinced at this point in time that NaCl offers enough advantages over the rapid development of JavaScript or the power and speed of operating system APIs. Apps running in the browser was attempted in the 90s with Java, and NaCl been around for a few years now. This link is just announcing that it's supporting the Pepper plug-in interface in Chrome.

I would like to point out that the failing of wave was primarily that nobody found it to be useful, not that it was over-hyped. I can't imagine NaCl having that problem.

I don't want to go off on a tangent but I think it's a relevant point that the overall usefulness of both technologies is strongly related to having diverse implementations. I'm not saying hype is the issue but rather the trying to get cooperation from the industry and competitors when the feasibility of the project isn't entirely proven.

Wave was definitely overhyped. That's why so many sought beta invites and why so many were confused and disappointed when they finally got in.

Unity games without a plugin would impress a lot of people. And it would have geek appeal as they currently don't have a linux implementation of the plugin.

I don't know what the progress is with this, but they were talking it up last year:

http://blogs.unity3d.com/2010/05/19/google-android-and-the-f...

Is Lego Star Wars in the browser enough to make people sit up and pay attention? I think it might be.

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.

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.

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.

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.

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

That's silly, LLVM bitcode is as portable as you like. Hell, you can translate it to javascript if you're truly worried about absolute browser portability: http://code.google.com/p/emscripten/

> That's silly, LLVM bitcode is as portable as you like

LLVM bitcode is actually not meant to be portable at all. It is very specific to the machine it is built for - endianness, structure alignment, and so forth.

> Hell, you can translate it to javascript if you're truly worried about absolute browser portability: http://code.google.com/p/emscripten/

Thanks for mentioning Emscripten, I wrote it :) It's interesting though, that a main challenge in Emscripten is exactly to deal with the non-portability issues in LLVM.

The reason LLVM is used in Emscripten (and, I suspect, in PNaCl) is not that it is portable - it isn't - but that nothing portable exists which is as good as LLVM in other respects (clean codebase, well-defined assembly language, good toolchain, etc.).

How about C--? http://www.cminusminus.org/

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...

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

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."

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.

You can, however, open a WebSocket. You won't be able to connect directly to an SSH server listening with TCP, but you can connect to a server speaking SSH over the WebSocket Protocol. Of course, you can do that today with JavaScript. Ten year old network protocols do not require native code for performance.

Well you can open a WebSocket.

Same-origin prevents your corporate intranet from getting scraped because a user visited a malicious website.

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

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.

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)

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

This prediction is going on 20 years old. :)

Their "Hello world" demo is kind of a turn off: http://code.google.com/p/nativeclient-sdk/source/browse/trun...

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.

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. "

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-... .

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

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."

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

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)

Reply on news.ycombinator.com