>It's much simpler than LLVM and reuses the components of the JavaScript engine that already must exist in browsers. But Google say they used simplified subset

>It's much simpler than LLVM and reuses the components of the JavaScript engine that already must exist in browsers. But Google say they used simplified subset of LLVM IR. In addition as far as I understand PNaCl has its own triple which parks down some things like endinaness and pointers size etc. which make IR much more portable. > You could implement asm.js in the exact same way. There's nothing stopping you from doing that. Yes, I don't argue you cannot keep evolving JS to be closer to real bytecode, I'm just arguing this in my opinion is not the right way to go. And moreover I think it will fail. People tried retrofit JVM to be bytecode for C/C++ too, and where has this efforts lead? In contrast LLVM IR /is already/ IR for C/C++. In its full form it's a compiler IR but making it more stable and portable seem like much smaller task than retrofitting all featuers needed for native execution onto JS. > I have not verified the PNaCl performance numbers, but I would be surprised if they counted compilation time. The asm.js performance benchmarks do count compilation time. So I suspect the apples-to-apples gap is actually much smaller. Compilation time matters only the first time app is run, Google said. If you have a game or large application, you run it more than once. Since their compilation generates native binary, they just need to load it next time so it's 0 compilation time. I don't know how their first time compilation will compare to asm.js but all subsequent ones are likely better.