Yeah, and you can also run Linux in a browser and run Chrome within that and then everything will be portable everywhere. Except, well, for performance. One of

Yeah, and you can also run Linux in a browser and run Chrome within that and then everything will be portable everywhere. Except, well, for performance. One of the big differences between ASM.js an PNaCl is that ASM.js just exposes ordinary standardized Web APIs, while PNaCl gives you the Pepper API, which is basically an entirely Chrome specific API. That means that rather than just using Emscripten and compiling with two output targets (PNaCl and ASM.js) which call the same APIs, you need to do a wrapper layer on one or the other (emulating PNaCl with standard Web APIs, or vice versa, or having some other intermediate layer that abstracts over both). The whole point of ASM.js is to leverage existing standardized infrastructure, while PNaCl just exposes what's convenient to expose in Chrome, while likely being considerably more expensive for other browser vendors to implement. This is a lot like Filter Effects in IE. Rather than specifying a reasonably portable syntax, they defined something that was build specifically on some random subset of DirectX filters, and pretty much impossible to implement anywhere else without implementing a large amount of DirectX. While other browsers eventually released most of the same things in a portable manner, there was a while where you had to either implement both or use some kind of wrapper of one over the other. While I think that it's a good thing that Google has spent time experimenting with and building NaCl and PNaCl (in general, you need ad-hoc single engine experimental implementations that people can play around with in part to figure out what will actually work for authors and is actually implementable, like canvas was, or various CSS3 effects over the years), it's a standardization dead end, and it would be nice if they would spend their effort on trying to extract something that could be standardized from it and ASM.js, rather than enabling it for web pages so it'll become another single-vendor technology that leaves others as second-class citizens. This kind of vendor lock in is out of line with promises of openness and supporting standards that Google has made in the past, and especially concerning since they're selling hardware that only runs Chrome. Between locking people in to a single browser on that platform, and a single browser if they target PNaCl (with maybe second-class support for other browsers via Emscripten and pepper.js), this is starting to remind me of what a certain other company did when they had the sleek, fast new browser that was trouncing the big buggy slow incumbent.