4 ms·

Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested

Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d... Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding. Some people wrongly thought that WASM was trying to kill JS, but nobody working on standardizing WASM in browsers believed in that goal.

pjmlp 1y ago
People have to look at it, from the same point of view Google sees the NDK on Android. "However, the NDK can be useful for cases in which you need to do one or more of the following: - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. - Reuse your own or other developers' C or C++ libraries." And I would argue WebGL/WebGPU are preferably better suited, given how clunky WebAssembly tooling still is for most languages.
mallets 1y ago
A bit unrelated, but are there any recent benchmarks comparing it with native perf? Hard to believe it can compete with V8 JIT anytime soon. Might be easier to integrate fast vector libraries within javascript engines.
yoden 1y ago
That's the issue with WASM. Very, very few people want a limited VM that's only good for CPU-intensive pure functions. The WASM group has redirected a huge amount of resources to create something almost nobody wants.
apatheticonion 1y ago
It's really not that hard. Node.js has a very mature C FFI for interacting with JavaScript. Just agree on some basic bindings wasb_create_u32(env: *const env, value: u32, result *mut value) -> status wasb_create_string_utf8(env: *const env, str: *const c_char, length: i32, result: *mut value) -> status There is even a shim that ports the Node.js C FFI to wasm: https://github.com/devongovett/napi-wasm/blob/main/index.mjs#L400 https://github.com/devongovett/napi-wasm/blob/main/index.mjs... Heck, just include that in the browser so it doesn't need to be loaded at runtime Stack that with support in the browser for wasi and you have everything you need to work with the DOM from wasm as well as things like threading

pjmlp 1y ago

People have to look at it, from the same point of view Google sees the NDK on Android. "However, the NDK can be useful for cases in which you need to do one or more of the following: - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. - Reuse your own or other developers' C or C++ libraries." And I would argue WebGL/WebGPU are preferably better suited, given how clunky WebAssembly tooling still is for most languages.

mallets 1y ago

A bit unrelated, but are there any recent benchmarks comparing it with native perf? Hard to believe it can compete with V8 JIT anytime soon. Might be easier to integrate fast vector libraries within javascript engines.

yoden 1y ago

That's the issue with WASM. Very, very few people want a limited VM that's only good for CPU-intensive pure functions. The WASM group has redirected a huge amount of resources to create something almost nobody wants.

apatheticonion 1y ago

It's really not that hard. Node.js has a very mature C FFI for interacting with JavaScript. Just agree on some basic bindings wasb_create_u32(env: *const env, value: u32, result *mut value) -> status wasb_create_string_utf8(env: *const env, str: *const c_char, length: i32, result: *mut value) -> status There is even a shim that ports the Node.js C FFI to wasm: https://github.com/devongovett/napi-wasm/blob/main/index.mjs#L400 https://github.com/devongovett/napi-wasm/blob/main/index.mjs... Heck, just include that in the browser so it doesn't need to be loaded at runtime Stack that with support in the browser for wasi and you have everything you need to work with the DOM from wasm as well as things like threading