I agree, I'd love to be able to explicitly annotate a certain function for pre-optimization even if there was some initialization cost but that would also guarantee its performance throughout the app's lifetime. I'm not sure if that can be achieved with the dynamic nature of JS. Anecdotally also, in my benchmarks what I observe is that you get optimizations only for things that run consecutively i.e in a loop. When you switch to other paths and return it treats it like a cold path all over again. So when you're switching paths very often you may never get any optimization benefits and then the only option, at least for now, is to use WASM.
Also, all of this without ever mentioning GC, which is extremely hard to avoid using vanilla JS and will certainly cause hiccups.
I also agree that tooling around WASM could be improved but we should give it some time given that it's a fairly new thing (I think it's less than a decade even if you include asm.js). I believe it will become relevant not necessarily because it can run on the web, but because of the feature that it's a sandboxed target environment that is extremely portable. WASM runs almost everywhere already and I think that's it's main winning point and not so much the browser side.
Also, all of this without ever mentioning GC, which is extremely hard to avoid using vanilla JS and will certainly cause hiccups.
I also agree that tooling around WASM could be improved but we should give it some time given that it's a fairly new thing (I think it's less than a decade even if you include asm.js). I believe it will become relevant not necessarily because it can run on the web, but because of the feature that it's a sandboxed target environment that is extremely portable. WASM runs almost everywhere already and I think that's it's main winning point and not so much the browser side.