6 ms·

> Direct DOM access doesn't make any sense as a WASM feature. …proceeds to explain why it does make sense…

flohofwoe 1y ago
It's not a WASM feature, but would be a web browser feature outside the WASM standard. E.g. the "DOM peeps" would need to make it happen, not the "WASM peeps". But that would be a massive undertaking for minimal benefit. There's much lower hanging fruit in the web-API world to fix (like for instance finally building a proper audio streaming API, because WebAudio is a frigging clusterf*ck, and if any web API would benefit from an even minimal reduction of JS <=> WASM marshalling overhead it would be WebGL2 and WebGPU, not the DOM. But even for WebGL2 and WebGPU the cost inside the browser implementation of those APIs is much higher than the WASM <=> JS marshalling overhead.
- dustingetz 1y ago
  so the feature does make sense, it’s just the implementation crosses a Conway’s law boundary (I also want this feature, to drive DOM mutations from an effect system)
  - afiori 1y ago
    Sorta, in practical terms once WASI is ready the browsers can define a DOM world in WIT and maybe support components using it
- creata 1y ago
  > WebAudio is a frigging clusterf*ck Out of curiosity, what issues do people have with WebAudio since audio worklets became widely supported?
  - flohofwoe 1y ago
    Audio worklets are a step into the right direction for streaming audio, but for a simple audio-streaming API you don't need the complex node-based architecture of WebAudio, you just need a JS callback which writes samples into an ArrayBuffer. With audio worklets this callbacks runs in a separate audio thread, and with the (deprecated) ScriptProcessNode this callback runs on the main thread. E.g. a "good" web audio API replacement would only offer a callback that runs in a separate audio thread plus a convenience function call which allows to push small sample-packets from the main thread to the audio thread (at the cost of increased latency to avoid starving) - this push-function would basically be the replacement for ScriptProcessorNode. In general, see here for a pretty good overview why WebAudio as a whole is a badly designed API: https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/ https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud... TL;DR: WebAudio's original design requires a lot of complexity and implementation effort for use cases that are not relevant to most of its users - and all that effort could be used instead to implement a much smaller and focused web audio API that covers actually relevant use cases. Specifically for audio worklets: those mainly make sense when the entire audio stream generation can happen on the audio thread. But if you need to generate audio on the main thread (such as in emulators: https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/), unless you want to run the entire emulator in the audio thread, you need an efficient way to communicate the audio stream which is generated on the main thread to the audio thread. For this you ideally need shared-memory multithreading, and for this you need control over the COOP/COEP response headers, and for this you need control over the web server configuration (which excludes a lot of popular web hosters, like Github Pages). For this situation (generate sample stream on browser thread and communicate that to the audio thread) you're basically re-implementing ScriptProcessorNode, just less efficiently and limited by COOP/COEP. So at the very least ScriptProcessorNode should be un-deprecated.

It's not a WASM feature, but would be a web browser feature outside the WASM standard. E.g. the "DOM peeps" would need to make it happen, not the "WASM peeps". But that would be a massive undertaking for minimal benefit. There's much lower hanging fruit in the web-API world to fix (like for instance finally building a proper audio streaming API, because WebAudio is a frigging clusterf*ck, and if any web API would benefit from an even minimal reduction of JS <=> WASM marshalling overhead it would be WebGL2 and WebGPU, not the DOM. But even for WebGL2 and WebGPU the cost inside the browser implementation of those APIs is much higher than the WASM <=> JS marshalling overhead.

dustingetz 1y ago
so the feature does make sense, it’s just the implementation crosses a Conway’s law boundary (I also want this feature, to drive DOM mutations from an effect system)
- afiori 1y ago
  Sorta, in practical terms once WASI is ready the browsers can define a DOM world in WIT and maybe support components using it
creata 1y ago
> WebAudio is a frigging clusterf*ck Out of curiosity, what issues do people have with WebAudio since audio worklets became widely supported?
- flohofwoe 1y ago
  Audio worklets are a step into the right direction for streaming audio, but for a simple audio-streaming API you don't need the complex node-based architecture of WebAudio, you just need a JS callback which writes samples into an ArrayBuffer. With audio worklets this callbacks runs in a separate audio thread, and with the (deprecated) ScriptProcessNode this callback runs on the main thread. E.g. a "good" web audio API replacement would only offer a callback that runs in a separate audio thread plus a convenience function call which allows to push small sample-packets from the main thread to the audio thread (at the cost of increased latency to avoid starving) - this push-function would basically be the replacement for ScriptProcessorNode. In general, see here for a pretty good overview why WebAudio as a whole is a badly designed API: https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/ https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud... TL;DR: WebAudio's original design requires a lot of complexity and implementation effort for use cases that are not relevant to most of its users - and all that effort could be used instead to implement a much smaller and focused web audio API that covers actually relevant use cases. Specifically for audio worklets: those mainly make sense when the entire audio stream generation can happen on the audio thread. But if you need to generate audio on the main thread (such as in emulators: https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/), unless you want to run the entire emulator in the audio thread, you need an efficient way to communicate the audio stream which is generated on the main thread to the audio thread. For this you ideally need shared-memory multithreading, and for this you need control over the COOP/COEP response headers, and for this you need control over the web server configuration (which excludes a lot of popular web hosters, like Github Pages). For this situation (generate sample stream on browser thread and communicate that to the audio thread) you're basically re-implementing ScriptProcessorNode, just less efficiently and limited by COOP/COEP. So at the very least ScriptProcessorNode should be un-deprecated.