> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). You are comparing different

> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). You are comparing different ratios: munificent was comparing against JS and your "2 times" prediction is against native performance of the compiled VM. > there are interesting results even there, see pypy.js. Yes, the most interesting result is that you have to warm up pypy.js with a blow torch, otherwise performance is abysmal. > I think that approach could work for Dart as well. Have you seen people complaining about size of dart2js output? Can you imagine how big emscripten output would be? I have been arguing that dart2js could have been using hand-written JIT compiler on the client side, but the startup performance compared to AOT would really be a big deal. I think a combination of AOT and JIT would be the best, but sadly it is also true that JavaScript lacks right level of abstraction. It is either too low-level (typed arrays, hand rolled allocations etc) or too high-level.