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