Comment by weinzierl
3 years ago
I suspect that in the long run, compile-to-JS type systems will go away and will be replaced by compile-to-WASM type systems.
3 years ago
I suspect that in the long run, compile-to-JS type systems will go away and will be replaced by compile-to-WASM type systems.
After having used WASM on the client side, I have my doubts.
It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits.
The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
> WASM is good for things that need to be as fast as possible
i would've thought that WASM was really only "good" for reusing existing software written in other languages not intended for the web, by recompiling it into WASM.
For example, you want to create a web version of an app written with QT or some other widgeting framework which could get a WASM target.
Isn’t the idea that wasn’t means you can expose the web etc APIs to any language? Eventually there will be tooling that will make this a doddle.
It doesn’t approach the convenience of JS dev tools.
For example, you can’t have a REPL and high-level debugger combo, you just get a very basic low-level debugger. It’s a 90s debugging experience.
You can’t even have a modern low-level debugger because you can’t control how the browser executes your WASM, unlike in a native executable where you can run a debugger and then run your code inside it.
I guess you could have a WASM based debugger that has a WASM interpreter inside, and then you run your code inside that, but my God if that’s the future then I want no part of it.
In my experience and in other benchmarks I’ve seen WASM runs basically the same as JS. Faster in some benchmarks, slower in others.
The JIT in V8 and others is pretty solid.