I think at this point we just have to wait for a good support for webassembly on all main browsers and then everyone can have its own ""isomorphic"" stack and we can finally stop these wars about how to modify javascript and what features to introduce because we all will finally have other alternatives to choose.
Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.
Parsing Javascript can also be a performance bottleneck for some applications as Javascript parsing is somewhat expensive in comparison with Webassembly.
Performance and size. You can't get better performance or smaller size than a manual written js solution. wasm is supposed to give you both( better performance and smaller payload size). I'm wondering how many people will see value in JS once wasm and compiled to wasm languages are first class citizens. I doubt there will be many(excluding the js developers who may be biases)
> You can't get better performance or smaller size than a manual written js solution.
Except in cases where the handwritten solution must be transformed to a different pattern (doing essentially the same thing). For example, the handwritten solution may write:
element.innterHTML = '<div><span>x</span></div>';
While the compiler will unpack that and would use document.createElement() and would append these nodes together. The example may be lame, but most people would prefer a short string over 4+ lines of createElement() calls in their handwritten version. (Same old story with assembly vs. compiled C code).
Similar pattern may arise for various parts of the JS execution profiles and/or browser runtime quirks.
