Parent mentioned the lack of tooling, and that is indeed where most of the cost of using WebAssembly lies.
You don’t really need to learn the assembly language itself since you’ll probably just be calling emcc.
However, you may need to build code to marshall more than just ints and strings to the JS code. Even after you do, you’ll run into the classical issues of keeping track of object references across a GC & non-GC system.
You may need debugging and find that in-browser debuggers for WASM are primitive/non-existent. You may need to figure out how unmangle stack traces —- including mixed JS/WASM traces. Third-party tools like Sentry for error reporting may not have built support (they sort of recently have and is very under-documented).
All solvable problems, but it’s a lot of time spent not building the product. There are plenty of good uses cases but it’s usually not the ones based on the false premise that native is somehow always better than interpreted.
You don’t really need to learn the assembly language itself since you’ll probably just be calling emcc.
However, you may need to build code to marshall more than just ints and strings to the JS code. Even after you do, you’ll run into the classical issues of keeping track of object references across a GC & non-GC system.
You may need debugging and find that in-browser debuggers for WASM are primitive/non-existent. You may need to figure out how unmangle stack traces —- including mixed JS/WASM traces. Third-party tools like Sentry for error reporting may not have built support (they sort of recently have and is very under-documented).
All solvable problems, but it’s a lot of time spent not building the product. There are plenty of good uses cases but it’s usually not the ones based on the false premise that native is somehow always better than interpreted.