It's not hostility. It's just that you're a very passionate Mozilla employee and a very passionate creator of asm.js. And from past experience I expect that you'll be willing to continue a debate longer than I can. Plus, you already know that I have reservations about asm.js, and it's just not worth rehashing that debate (accepting that WebAssembly appears to be heading in a direction that addresses most concerns, so I should offer well earned kudos on that front).

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.

I think I see where you're coming from. Overall, I think it's hard for us to estimate how much effort it would take for Unity to support another platform. Perhaps I was overly pessimistic when I said supporting a platform just for a single browser is too burdensome; perhaps you were overly optimistic in saying that maintaining their existing port would have been a good option. Only Unity knows the answer. So I admit you might be right on that point.

But the more important thing is that I disagree on the effort it takes to optimize asm.js. As you can see in those forum posts, out of the 4 major browsers, mainly Chrome is presenting a problem to Unity developers. Yes, it takes some work to optimize huge compiled codebases well, but Google has talented engineers and massive resources. I refuse to believe that Chrome cannot match the results of the other 3 browsers - it would be insulting to the v8 devs to assume so. Since the ability is there but the results are not, I can only guess that the Chrome developer's focus is elsewhere.

And of course there are many other important things to optimize on the web. But Unity and other high-quality 3D games are very important too. Chrome is holding back this part of the web, right now - I hope not for long.

I think you're reading something different than what I intended. I don't work on V8, and what I know about their priorities is no different from what they've stated publicly. That is, the V8 team wants to improve asm.js performance by improving overall JS performance, and not special case behavior just for asm.js. I know that's not the route you took, but that was my point about "not everyone agrees with the path you chose" with Firefox. And regardless of what either of our personal views are, it's hard to objectively argue that the V8 team is wrong in focusing on areas that positively impact the overwhelming majority of their users.

Yes, and I think it's fine that v8 took that route - it's actually the route that I recommended that Firefox take. It is also the route that JavaScriptCore is taking. So I completely agree with you that the v8 team's approach is reasonable.

But they haven't optimized it well enough yet. The main issue Unity (and other big asm.js codebases) are seeing is OOMs and crashes in Chrome. The v8 and JavaScriptCore approach can avoid those, by not compiling everything at once, more efficient in-memory data structures, and so forth. This helps overall JS performance as well. It's just engineering work that needs to be prioritized and done.

(AOT, as in Firefox and Edge, does have an advantage in startup speed that I think v8 and JavaScriptCore will have a hard time approaching, but that is not a blocking issue the way that crashes and OOMs are.)