> X-to-JavaScript compilers were available for decades now, still most write their stuff in JavaScript.
A lot of that is friction and fear of pigeon holing, that using something that transpiles to JS will limit project/career options later more so than plain JS will. I don't see that as a big issue as long as you keep an eye on developments elsewhere, at least it is no bigger issue than using a particular framework for your application. Then again I've out of date in this area (I keep an eye on developments and played with some of them, but have used-in-anger very little newer than jQuery), having specialised somewhat data-side when I'm not working on legacy projects, so I could be wrong there.
> What WASM will change
I think the key difference between JS transpilers and using WASM is that the latter promises significant performance improvements for some work where the former is more syntactic sugar for the developers (improving their performance rather than the application's, or perhaps even sometimes at the cost of a little app performance due to the extra abstraction). I see WASM finding a very useful niche in libraries for number-crunching, AI, and other compute intensive tasks, while the majority of any project's code outside that (where there is no practical performance gain to be had) remains JS.
A lot of that is friction and fear of pigeon holing, that using something that transpiles to JS will limit project/career options later more so than plain JS will. I don't see that as a big issue as long as you keep an eye on developments elsewhere, at least it is no bigger issue than using a particular framework for your application. Then again I've out of date in this area (I keep an eye on developments and played with some of them, but have used-in-anger very little newer than jQuery), having specialised somewhat data-side when I'm not working on legacy projects, so I could be wrong there.
> What WASM will change
I think the key difference between JS transpilers and using WASM is that the latter promises significant performance improvements for some work where the former is more syntactic sugar for the developers (improving their performance rather than the application's, or perhaps even sometimes at the cost of a little app performance due to the extra abstraction). I see WASM finding a very useful niche in libraries for number-crunching, AI, and other compute intensive tasks, while the majority of any project's code outside that (where there is no practical performance gain to be had) remains JS.