Hacker News Reader

Comment by hosay123 | Hacker News Reader

> We are actively helping still-popular NPAPI-based services migrate to open-web-based alternatives.

Still using the term "open web", and in the very next paragraph discussing NaCl. Funny guys, real funny

I think it's fairly clear that NaCl is suggested only as an alternative for applications with needs not yet supported by open web technologies:

  Most use cases that previously required NPAPI are now
  supported by JavaScript-based open web technologies.
  For the few applications that need low-level APIs,
  threads, and machine-optimized code, Native Client
  offers the ability to run sandboxed native code
  in Chrome.

And accepting that, NaCl is free and open source that is publicly developed, so I don't see any of the implications of your argument working.

And accepting that, NaCl is free and open source that is publicly developed, so I don't see any of the implications of your argument working.

Wake me up when anyone (can) realistically do an independent reimplementation. Claiming that NaCl is "open web" is a sure sign of excessive reality distortion fields.

Did you even read what you're responding to here? Because your comments throughout this thread imply that you have not. The only use of the term "open web" was specifically in reference to cross-browser technologies. You are the one inappropriately applying it where it was not originally used. So, I think you should take a step back and consider what your argument here really is.

If you have some other objections to NaCl as a technology, then that's certainly your right. However, I don't see you substantiating your objections beyond vague FUD and ad hominem attacks. The reality is that NaCl is free and open source code with a permissive license. It's thoroughly documented and has an exhaustive test suite that would make an alternate implementation straightforward. In fact, independent teams have used exactly that documentation and those tests to reimplement entirely new validators for NaCl from scratch (e.g. the regex based validator). So, there really is no legitimate argument that NaCl couldn't realistically be reimplemented (even accepting that NaCl's license precludes such a need anyway).

NaCL is open source, the papers and documentation are all open, the build tools are all open. The only thing it's not is standardized -- and that's not Google's fault.

Apple and MS are vested in their platform plays, and Mozilla has been playing a comparatively weak technical game for years.

So basically it's a great solution except for the part where everybody else has misgivings about it. There are already standards covering almost everything from NaCl, and going by what it was supposedly for according to their original marketing campaign, 3D games, entirely supplanted already by current generation JS engines

It was a myopic stop-gap that's already starting to show its age, about the only thing it has left running for it is smaller distribution size and faster cold-start times, but they're implementation problems of current generation JS, rather than some fundamental benefit of NaCl

> implementation problems of current generation JS

Wake me up when you get to be end of the rainbow and find the pot of JavaScript gold supposedly waiting there.

Mozilla has been playing a comparatively weak technical game for years.

Except for the part where emscripten completely ate (P)NaCls lunch in a way that works cross-browser.

Uh, when did that happen? It's slow, it's complex, it's a terrible solution, it's barely seen any uptake and near zero interest from tool vendors.

Oh, and it's objectively, demonstrably inefficient. This is just another version of "I implemented something simple ... in JavaScript!". What lunch got eaten?

Zero uptake? It's a target for several important gaming engines now, which were an important target audience of NaCl.

There's really no point in replying to the rest of your (totally false) assertions.

Reply on news.ycombinator.com