Portable Native Client

[azov]

http://en.wikipedia.org/wiki/ActiveX - 1996 is knocking… yes, I know - it's very, very different this time, but still can't help remembering the horrors of ActiveX :)

PS. From Wikipedia article: In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator

PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..

[RyanZAG]

Ugh. Sounds like the next IE6 is here...

Can't wait to log into a bank that demands I installed Chrome to use their new 'security' or some web apps that won't run in anything but Chrome.

[pkulak]

This seems like more of a ChromeOS move to me, so that you can run native code on Atom and X86 machines. The knock on ChromeOS is always that it's "just a browser". I seriously doubt anyone is going to write their Etsy storefront in NaCl. The benefit here, of course, is that if someone does write the next Photoshop for ChromeOS machines, it should also run fine in OS X, Windows and Linux. Seems like a win for portability to me.

[scottmp10]

I doubt Google wants to keep this Chrome-only. Just like SPDY, there isn't initially support on all platforms/browsers so you have to have a fallback. But if it catches on then you will see broader support over time.

[chully]

Web apps that won't run in anything but chrome? There are already plenty. Picasa/Google+ photo editing for a start.

[spot]

IE6 did not have an open source implementation that others could adopt.

[melling]

The big difference, of course, is that you can be on any operating system with Chrome/Chromium. It's not ideal but that is huge. The "lockin" is no longer at the operating system.

[cia_plant]

PNaCl has been in development for a while, I'm having trouble understanding just what is being announced here. Is PNaCl now enabled by default in Chrome?

I also hadn't seen pepper.js before, is that new?

[azakai]

The news is that PNaCl has been enabled on the web in the latest release of chrome. Previously it shipped but ran only on the chrome web store and whitelisted sites like plus.google.com.

Also pepper.js is a fairly recent thing, yes.

[mistercow]

> Is PNaCl now enabled by default in Chrome?

I just updated, and in chrome://flags, the "Enable Portable Native Client" option has changed to "Disable Portable Native Client".

So yes, apparently.

[devrelm]

> http://codepen.io/lbebber/pen/xrwja

I think so. I just updated to Chrome 31 and it brought up a UAC in windows, which probably means that it was installing the PNaCl runtime since it usually doesn't require a UAC.

[amaks]

It was NaCL which was previously available. This one is Portable NaCL which presumably can run the code built from the same intermediate machine code on various platforms (ARM, x86/64, etc). The immediate winner here is which runs on ARM and x64.

[bsimpson]

Be interesting to see if this becomes a target for other languages, e.g. allowing browser applications to be written in Python.

[leoc]

What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their de facto control over Web standards.

[pedrocr]

I really really hope that this+pepper.js will allow you to deploy Ruby/Python/Go as client-side languages for the Web. Does anyone know how (P)NaCl interfaces with the DOM?

[cliffbean]

We've had other languages running in browsers for quite a while now. eg.:

http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...

[eliben]

http://gonativeclient.appspot.com/demo has a Lua interpreter demo. There's also Python, but you'll have to build it yourself (naclports).

[_random_]

Very good news! A lot of developers don't like JavaScript and HTML. Google started to listen. I really hope the rest of big players will follow the suite.

[cgh]

So PNaCl + llgo means Go in the browser, right? Now that is something to think about right there.

[oblio]

Be careful what you wish for because it might come true. A lot of people don't like the Open Web and are clamoring for something obfuscated. Longer term is lose-lose for everyone.

[thrownaway2424]

The demos are cool, but are there any among them that can't be done in JS? I know I've seen Voronoi polys in JS that were way less janky than the one in the PNaCL demo.

[leoc]

Well, presumably you could implement a language with bignums in PNaCL with reasonable efficiency, something which is evidently not possible in JS.

[spot]

the voronoi is the only one that i think is competitive in JS.

js has plenty of 2d physics sims but i have yet to see a decent 3d one like this.

[tluyben2]

It says 'LLVM style intermediate code'; why not actual LLVM intermediate code? What would be the reason for an alternative? If it would be actual LLVM code it would be easier to compile from programming languages and to different backends, right?

[mccr8]

It is based on LLVM, but presumably they have to modify it for their particular needs. The PNaCl bitcode reference manual goes into more detail: https://developers.google.com/native-client/dev/reference/pn...

[kenferry]

"The PNaCl bitcode is a restricted subset of LLVM IR."

https://groups.google.com/forum/#!msg/llvm-dev/lk6dZzwW0ls/J...

[lucian1900]

LLVM bitcode is quite large and not really suited to being a transport format. The bytecode they did come up with is probably a LLVM frontend.

[peterhunt]

For anyone who works on Chrome: does this mean that Chrome won't move to support asm.js? I tried searching the bug tracker and discussion group and couldn't find anything.

In general I'm really happy that we're getting faster (no-gc) runtimes, but I think I favor asm.js's approach due to its backwards compatibility (though I admit I am not aware of the nuances of each implementation).

[elisee]

Chrome has taken the approach of working on improving their V8 engine to (hopefully) achieve similar performance to Firefox's specialized asm.js AOT codepath but without any special handling of the "use asm" directive (which gives Firefox guarantees about variable types & stuff like that). See https://news.ycombinator.com/item?id=6553794 for a discussion on the subject.

[_prometheus]

> backward compatibility

IMO NaCl is much more backwards compatible, letting you recompile old code-bases for the web with minimal changes. The javascript approach (even with the speed gains of asm.js) does not have threads/native instructions/etc.

I want chrome to support asm.js, and firefox to support NaCl. Winning all around.

> though I admit I am not aware of the nuances of each implementation

Perhaps a neutral discussion page is needed... I'll see about making one.

[asdfaoeu]

In a way NaCl offers better backwards compatibility as the code can be compiled to both NaCl and Javascript simultaneously. asm.js javascript offers subpar performance on non asm.js platforms as it is optimised to a specific subset that would have no benefit on those. Also long run asm.js sounds like a terrible format when you consider the extra overhead of massive javascript files that could be concisely encoded like NaCl.

[sry_not4sale]

Here is the V8 (Chrome) bug for asm.js support: http://code.google.com/p/v8/issues/detail?id=2599

[misuba]

They provide pepper.js, which does a similar trick for PnaCl stuff.

[Fr0styMatt]

Why do people keep saying that PNaCL is like ActiveX, when it's nothing of the sort? Is this a failing on Google's PR?

[BitMastro]

Because lots of people are narrow minded apparently

[willvarfar]

Great news for zerovm too! Will this mean apps that run seamlessly on ARM and X86 boxes?

[icefox]

Anyone know why it takes so long to load any of the demos on http://gonativeclient.appspot.com/demo/bullet ? They simply take way to long.

[pritambaral]

One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc.

By the way, Google has already proven their "platform-creation" skills with Android.

[smegel]

How is this different to Javascript? They both get jitted to native code (v8, llvm)...what's the benefit?

[ThinkEzy]

I am actually looking at saying good bye to browser (html / css / js and all the madness) and hello to apps that connect to dropbox or s3 or some such cheep server.

[augustl]

Isn't it better to ship uncompiled C++ code directly, instead of decompiling and recompiling already compiled code?

Honest question, I'm a noob at compilers :)

[cek]

When this is supported natively in Safari on iOS it will be interesting.

[djvu9]

asm.js is a better answer.

[general_failure]

What's the question?