[1]: https://dropbox.tech/tech/2018/06/building-better-compressio...
[2]: https://thenewstack.io/adobe-developers-use-webassembly-to-i...
[3]: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
I think that WASM in the browser will either largely replace JavaScript or will wither away like Java applets did. I fear there is no in-between and if it is only because no one will support two languages and ecosystems in parallel and in the long run. Not the big companies and certainly not the small ones.
JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is focused on pure computation (forcing it to bundle its standard library, for example). But wasm has predictable performance that is close to native builds, and sometimes you need that.
Very few web pages use only wasm. Most uses of wasm on the wasm are as part of a JavaScript site, for the parts where wasm makes sense.
The danger for WASM is that JavaScript doesn't stand still either and we might as well see improvements that make the gap to WASM's selling points smaller.
Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].
[1] https://github.com/WebAssembly/js-string-builtins/blob/main/...
[2] https://github.com/WebAssembly/esm-integration/tree/main/pro...
[3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#...