Hacker News Reader

Comment by azov | Hacker News Reader

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

View on HN

Sounds more like Java to me. Let's replace a few words in the article:

"Under the hood, Java Applets work by compiling Java source code to an intermediate representation, rather than architecture-specific representations as in Native Client. The Java bytecode is wrapped into a portable jar file, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices."

> Sounds more like Java to me. Let's replace a few words in the article:

Winner, winner, chicken dinner.

After seeing all the web developers of the 90s dump on Java applets all the time, it's fascinating to see the same functionality being reimplemented piecemeal in Javascript.

We dumped on Java applets because they ran isolated in rectangles on the window and took ages to start and then proceeded to slow our machines to a crawl, and most of what it was used for was mundane stuff that could be done without Java, or that we didn't want.

The ultimate indictment of just how bad a fit java applets was is exactly that people shunned it despite the horrible alternatives.

PNaCl isn't Javascript.

It is a "Java" that Google controls, that is the main point.

It is not open source, then?

And Java is controlled by whom?

It is not open source, then?

It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).

And Java is controlled by whom?

Oracle. They own the Java trademark, so any fork cannot be called Java unless they certify it.

> It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).

Very importantly it's a copyright (and patent) license, not assignment. And it's the same thing required for any contribution to Chromium[1], and just about every competently run open source project out there, so it's not really an interesting distinction. The important aspect is more that the only "spec" for PNaCl is the documentation, which means that it can be changed by them...but then you break everyone's already compiled apps, so there are some incentives against that. Regardless, it's still open source, and you can still fork it, etc.

[1] http://dev.chromium.org/developers/contributing-code#TOC-Com...

I agree 100% that proper handling of copyright is important (and yes, I was wrong about the license/assignment thing), and I think Google is doing the right thing here.

My point was that Google controls the project (so far as it is possible to control an open source project). I don't see that as a bad thing.

It seems like every time someone tries to replace javascript with a better solution someone has to bring up vendor lock-in. Are we supposed to just live with javascript for eternity? When javascript was introduced it only worked on netscape browsers than other browsers adopted it later. It wasn't made a spec until later.

Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.

- http://phoboslab.org/log/2012/06/measuring-input-lag-in-brow...

- https://code.google.com/p/chromium/issues/detail?id=168459

I think this response time issue is a real show-stopper than JavaScript performance.

This along with the fact that you can't avoid GC when handling browser events makes it really hard to hit a consistent framerate for sure.

Well, asm.js gets around this by piggybacking on JavaScript's syntax. So that's one approach.

Adoption really is a big issue, and I think it kind of misses the point to handwave it by saying, "Oh, adoption is such a big issue that it's insurmountable, so let's ignore it." Google hasn't really done a lot to work with anyone else on PNaCl, or even really to address any issues anyone's brought up with PNaCl. They're just sort of creating an island so far. If PNaCl is going to be a thing, they're going to need to get past that.

Because it is never done in collaboration between browser vendors.

I agree, that's the thought I've had ever since learning of native client. These native, proprietary solutions have come and gone, such will be the fate of NaCl. As far as I'm concerned the future of high-performance webbrowser computing will be javascript-based through projects like asm.js or remote cloud architectures (eg https://brendaneich.com/2013/05/today-i-saw-the-future/)

How is this proprietary? Isnt there an open spec?

For Pepper? There is not, in fact. There's some developer documentation, but nothing resembling an actual implementation spec.

The code is open source, but last I heard there isn't a spec for PNaCl/PPAPI.

The PNaCl ABI is defined here: https://developers.google.com/native-client/dev/reference/pn... - and it's definitely a work in progress we'll be trying to improve. As for Pepper, it's also all documented here and below - https://developers.google.com/native-client/dev/pepperc/

Granted, this is documentation, not a standards-body spec.

Yes, certainly has had effort put into proper documentation. Do you know if there is also work being done to spec it formally?

We're definitely considering it.

Is there a PNaCl spec or just Google's implementation?

There's a bitcode spec [1] and a stability doc [2].

1 - https://developers.google.com/native-client/dev/reference/pn...

2 - http://www.chromium.org/nativeclient/pnacl/stability-of-the-...

The comparison to Active X, while intriguing, is really a Mu since the two are so different (http://eli.thegreenplace.net/2012/11/10/native-client-vs-act...)

Consider this as a much safer Multi-OS native application development platform that happens to work in a browser and all (ok, most of) your fears will disappear.

Chrome provides pepper.js, which converts PNaCl into JS using Emscripten, so it will run anywhere.

Reply on news.ycombinator.com