3 ms·
There is an in-between, which is the world we live in right now. JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is
by azakai 2y ago
There is an in-between, which is the world we live in right now.
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.
- weinzierl 2y agoI'd bet the current state is not sustainable and we will see a consolidation one way or another. 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.
- bakkoting 2y agoJavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.) 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/proposals/js-string-builtins/Overview.md https://github.com/WebAssembly/js-string-builtins/blob/main/... [2] https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration https://github.com/WebAssembly/esm-integration/tree/main/pro... [3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#wasmgc-interoperability https://github.com/tc39/proposal-structs?tab=readme-ov-file#...