3 ms·
I'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 eit
by weinzierl 2y ago
I'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#...