> Interesting how they are deprecating one tech (NPAPI) in the name of open web
The only reference to the open web is
> Most use cases that previously required NPAPI are now supported by JavaScript-based open web technologies
while the reasoning given for deprecation is explicitly "security, speed, and stability", which is certainly true. NPAPI is bad, bad business, and wouldn't fly for a second today if it weren't grandfathered into browsers.
It's a shame that there's still the NaCl fallback, but I would give good odds this will end up a positive for everyone as a forcing function, since the remaining plugins will look to JS-based solutions first since they'll continue working in all browsers.
(now, unfortunately some of those will be turning to EME, but that's a different series of poor decisions)
I'm all for deprecating NPAPI. At the same time, I don't think NaCl is the answer and it's definitely not "open web" (for any reasonable definition of that term) and shouldn't be advertised as such.
> I don't think NaCl is the answer and it's definitely not "open web" (for any reasonable definition of that term) and shouldn't be advertised as such.
Agreed, but as I said above, it's definitely not being called that in the blog post.
Maybe not. But they are advertising the use of NaCl just after they spoke about "open web".
One might call it hairsplitting. But we really don't need another ActiveX in the browser. We are still recuperating from that one. And I'm not even saying NaCl is bad as ActiveX, nor am saying that ActiveX is bad from technology point of view. What I am saying is that both are/were technologies that were pushed by single browser vendor and that is bad.
NPAPI plugins are already ActiveX in the browser by your definition: technologies controlled and pushed by a single vendor. In fact, they're even more like ActiveX than NaCl is: they're generally closed-source, vulnerable to a wide variety of exploits, and in some cases not even cross-platform (Silverlight, for example, is a closed-source Microsoft product that "extends" the web and is not released for Linux). Moving to NaCl is better in those senses than NPAPI-based plugins: if the plugins are written in NaCl, they'll at least run on every major OS, and be sandboxed safely.
And NaCl isn't the only recourse for previously-NPAPI-based plugins. It's just the worst (for the web) choice. Better is to build the plugins on top of JS, which some vendors are already doing: for example, the announced future of the Unity on the web is compiling to JS.
Non-web-technologies (like the current iteration of NaCl) intruding on the browser is bad for the open web. But plugins are also bad for the open web, and deprecating them is better than not deprecating them. You can't fault the Chrome team too much for closing one door just because they left another open. :)
NPAPI is bad, bad business, and wouldn't fly for a second today if it weren't grandfathered into browsers.
Agreed, but I still don't see a reasonable replacement for it. PPAPI and NaCl don't fit the bill, and even if they did, no one implements them but Chrome.
> Agreed, but I still don't see a reasonable replacement for it.
A reasonable replacement for it is for browsers to just expose appropriate functionality through JS APIs with appropriate security provisions and continue to optimize their JS engines.
Yeah, that was interesting news. NaCl is officially removed in Unity 4.5 (which just came out). Flash will be removed in Unity 5 (if it's not already?). According to the Unity at least, asm.js + WebGL is the future.
There's nothing Firefox-only about asm.js. It's a subset of JavaScript that runs in other browsers at reasonable speed since it's part of benchmarks that browser vendors are optimizing for.
The pragma may be Firefox-only but nobody cares about that.
It won't do anything for non-Firefox users: things will just work, which is pretty much the entire point and a pretty huge difference from (P)NaCl and Flash.
asm.js is nothing but a "hint" to the JS engine that some optimizations are possible.
IIRC, Chrome hasn't implemented support for the pragma because they believe they can get the majority of the benefits by making V8 smarter.
Something being open source doesn't really have much relation to a technology being open. In this case in particular, it's replacing one open-source API that is easily re-implementable, and has been reimplemented by many parties, by another one that is realistically only available by importing the majority of Chrome into your project.
The point is that NaCL is not browser portable at all. NPAPI is. Therefor, they are depreciating a cross browser plugin architecture for one that is Chrome-only. Which basically means no more plugins at all, unless Chrome captures a ridiculous 50%+ marketshare. Which is actually likely, because Google is doing some real seedy nonsense to get Chrome on every Windows preinstall and bundled with every other freeware program in the universe.
It's a myth that NPAPI is browser portable (at least in the sense that portability is not a massive undertaking). NPAPI doesn't work on mobile platforms and it requires a huge effort to add or even maintain support for a multi-process browser and a modern graphics stack. Even then, the support is a hack that is a constant source of bugs, crashes, and security vulnerabilities. The only thing that's kept it working this long is constant vigilance on the part of browser makers.
Just because something is open source, it does not mean it will be supported by others. Browsers (and web in general) is very complex beast. It's not enough to open source something and proclaim it good for all. Other browsers need to support the same technology in order to gain big number of developers.
NaCl was not (afaik) adopted by any other browser vendor. Therefor it's not open web.
It was a passable-but-not-good-enough solution for something everyone wants to get rid of, quickly superseded by superior alternatives. I wouldn't hold my breath.