Why NASA Switched from Unity to Blend4Web

Getting back to your point, pragmatically speaking, maintaining a port is a distinction with less difference than implied. First, any reasonably complicated NPAPI plugin needs to handle a range of browser-specific quirks, meaning that significant porting is unavoidable even if it's bundled into one binary. Second, Unity supports ActiveX in IE, so they're clearly already comfortable maintaining a browser-specific port that doesn't offer any of the security or platform portability benefits of NaCl.

Outside of that, there's just the one-sided nature of the argument. As a creator of asm.js you are obviously a huge proponent. However, you must appreciate that not everyone perceives it the way you do, and not everyone agrees with the path you chose for adding support into Firefox. So, the technical burdens on another browser are just not the same, and in the specific case of Unity in Chrome have to be balanced against the fact there was already a tremendous past investment in a high-quality implementation.

So, no, I completely disagree with the framing that "Chrome has left Unity no good option". Independent of any work in Chrome on better supporting asm.js, the fact is that Unity had at least one other good option. So, I'm sure Unity had their reasons for the path they chose, but it was and continues to be a very explicit choice.

Why? You have regressed a feature that your users want. I realize that plugins aren't sexy, but Unity is something that both developers and users want. Entire development studios are based around creating online games in Unity that have active user bases who enjoy those games.

For better or for worse you have removed the ability for people to enjoy using a part of the web. But hey, an idealized vision of software perfection won out over what users wanted, so you got that going for you.

I'm a bit bitter that those in charge of browsers have en-masse decided that being pragmatic is worthless in comparison to creating idealized castles in the sky. This just as much applies to Mozilla as it does Chrome. Mozilla's response to why they won't implement Pepper is just as "pie in the sky, who cares what users want" as Chrome removing NPAPI is.

Plugins are something that users want. Ignoring how Adobe has managed to completely drive Flash's overall quality and performance into the ground, plugins are useful. They may not be useful to Developers who are doing Serious Developer Stuff at Serious Companies, but for a lot of users, my mother, my grandmother, my nieces and nephews, they are very useful.

On the other side, browser developers have content developers as customers. Those content developers prefer alternative toolchains. Flash and Unity have far better tool chains than WebGL does. Debugging problems is far easier when you don't have to go through multiple translation layers. And less layers in the stack means less places for something to go wrong. If you are writing against Flash then Flash may have a problem. If you are writing against 3 different browser's implementation of WebGL and/or ASM.js you now have 3 different sets of bugs and implementation quirks. (Not that Flash works the same across all browsers, but at least it is from one vendor!)

But all of that is thrown away in the name of "web standards".

Users care about what works. As developers we have a responsibility to make users happy, our own sense of happiness is sort of not the primary concern.

The 1.5 year notice you gave before depreciating the NPAPI in Chrome was way to short. 5 to 10 years would have been realistic to allow existing games to reach their natural end of life. Both NaCl and HTML5 are not appropriate porting target for an existing, complex PC game that's already running for several years. They are only a realistic target platform for starting new projects. What we do now is simply moving our users out of the browser into the standalone client, thankfully our users don't mind that much since most are 'hardened' PC players that don't mind the scare popup dialogs browsers put up when downloading a native installer. But it can hardly be in the interest of browser vendor to move gamers out of their platform I would think.

And for NaCl vs HTML5:

- NaCl was never allowed in the wild, only through the Chrome app store

- PNaCl simply came too late and had very long compilation times at first start, this has become better but is still a lot slower than FF's asm.js AOT compile pass

- performance differences between PNaCl and JS on Chrome are pretty much negligible, especially for a 3D game where WebGL overhead is much more important

- emscripten puts much more effort into supporting standard APIs for games then NaCl (e.g. SDL, glfw, OpenAL, ...)

- from personal experience, bugs in Chrome on the HTML5/JS side are fixed much more quickly than bugs on the NaCl side, very likely because the HTML5 side has much more resources available

From my experience, the PNaCl implementation in Chrome doesn't provide any real-world-advantages over the HTML5 way, and both platforms are a 'hard' porting target. Of all existing platforms (iOS, Android, OSX, game consoles), the web is definitely the hardest to port an existing PC game to (starting from scratch is much easier though).