3 ms·

“People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative.” It’s not a complete replacement yet but you c

• apatheticonion 3y ago
  > use JS as glue code if you want You can and this makes it appropriate for tech demos but it's a huge point of contention for engineers who are concerned about performance sensitive applications - particularly where boot time (TTI, TFP, etc) is important. Further, deferring the loading of a wasm module to js evaluation forgoes the browser's ability to optimize based on static analysis, dropping launch optimizations. Lastly, the added tooling adds an aspect of distrust. Web development is already saturated with complex tooling. We cannot simply run `cargo build --target wasm32-unknown-unknown` and have it work. Additionally, if you want to code split you would need to split your application up into a wasm executable with dynamically linked wasm libraries - something that isn't supported at present. > That’s… not true? It has been supported in all major browsers for years At present, you must initialize multiple instances of a wasm module and pass a SharedArrayBuffer between those modules to share memory. This means threads are controlled in JS and not in WASM. Additionally, ShareArrayBuffer is not supported in multi-origin websites - making it impossible to use in contexts like established applications which already use subdomains extensively (like Slack, Jira, etc).