Implementing an interpreter on typed arrays is leaving a lot of the power of the dynamic OOP host untapped. Translating Python classes to JS objects like Skulpt is a much better approach.
The RPython toolchain has another mode of operation, which outputs higher-level class-based code rather than low-level C-style code. They use this for a CLR backend, but it would be interesting to try implementing a JavaScript backend at that level and compare it to the lowlevel+emscripten approach.
Heh, actually it might be possible to cheat a little with this backend as well, using http://www.jsil.org/ to translate the output of the cli backend into javascript. Trying C+Emscripten versus CIL+JSIL would be a very interesting comparison.
I'm not sure what your point is, but so far the asm.js samples that I've seen have not indicated that compiling a runtime for a dynamic language, including memory management, GC, and JIT, are anywhere near as fast as transpiling to JS, and there are tons of complications.
lua.vm.js is running at 50% of Lua, not LuaJIT. Add to that that you can't touch the DOM from asm, and the ported VM basically has it's own heap and no way to collect cycles between Lua and JS and it's not a good solution. Much better to rely on the JS VM for memory management.
Transpiled asm.js code beats the pants off non-asm.js code in almost every regard. Period. I have not seen a single case where code heavily leveraging the JS GC heap, etc. will outperform the typed array, virtual heap, etc. style even WITHOUT the benefit of asm.js's AOT compilation.
It's possible, of course, but I've never seen it. And I certainly haven't found any way to achieve it with a compiler. If you have, let me know...
