Still no mention of DOM.
<sets alarm for three years from now>
See you all for WASM 4.0.
<sets alarm for three years from now>
See you all for WASM 4.0.
Direct DOM access doesn't make any sense as a WASM feature.
It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory).
If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. Just make sure that the JS code has enough 'meat', e.g. don't call accross the WASM/JS boundary for every single DOM method call or property change. While the call itself is fast, the string conversion from the source language specific string representation on the WASM heap into JS strings and back is not free (getting rid of this string marshalling would be the only theoretical advantage of a 'native' WASM DOM API).
…proceeds to explain why it does make sense…
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.
(I also want this feature, to drive DOM mutations from an effect system)
Out of curiosity, what issues do people have with WebAudio since audio worklets became widely supported?
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-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/), 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.
I disagree. The idea of doing DOM manipulation in a language that is not Javascript was *the main reason* I was ever excited about WASM.
...is already possible, see for instance:
https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht...
You don't need to write Javascript to access the DOM. Such bindings still call JS under the hood of course to access the DOM API, but that's an implementation detail which isn't really important for the library user.
https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
The only thing that might be expensive is translating string data from the language-specific string representation on the WASM heap into the JS string objects expected by the DOM API. But this same problem would need to be solved in a language-portable way for any native WASM-DOM-API, because WASM has no concept of a 'string' and languages have different opinions about what a string looks like in memory.
But even then, the DOM is an inherently slow API starting with the string-heavy API design, the bit of overhead in the JS shim won't suddenly turn the DOM into a lightweight and fast rendering system.
E.g. it's a bit absurd to talk about performance and the DOM in the same sentence IMHO ;)
_Telling the browser how you want the DOM manipulated_ isn't the expensive part. You can do this just fine with Javascript. The browser _actually redrawing after applying the DOM changes_ is the expensive part and won't be any cheaper if the signal originated from WASM.
Anyway I am quite sure that you could almost completely get rid of js glue code by importing the static Reflect methods and a few functions like (a,b)=>a+b for the various operators, add a single array/object References to hold refs and you can do pretty much everything from wasm by mixing imported calls
It's neither directly related to the web, nor is it an assembly syntax.
It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)
So you either create a very concrete JS library that translates specific WASM data into IO actions, or one that serializes and deserialize everything all around but can be standardized.
At this point, none of those options are much more capable than Java applets... Or, in fact, if you put a network call between the WASM and the JS, you won't even add much complexity.
Java applets allowed to load and call into native DLLs via JNI, so they were definitely much more capable than WASM, but also irresponsibly unsafe.
In your own WASM host implementation you could even implement a dlopen() and dlsym() to load and call into native DLLs, but any WASM host which cares about safety wouldn't allow that (especially web browsers).
WebASM is an assembly-like dialect, after all.
From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM relegate that specific useful thing to a particular language? A language that, in the context of what WASM wants to do in making the web "just another platform", is pretty niche (for any non-web-person)?
For me, as a non-web-person, the big allure of WASM is the browser as "just another platform". The one web-specific thing that seems sensible to keep is the DOM. But if manipulating that requires learning web-specific languages, then so be it, I'll just grab a canvas and paint everything myself. I think we give up something if we start going that route.
Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/foreign-funct...), e.g. C APIs are a sort of lingua franca of the computing world.
The DOM is the same thing as those C libraries, an important library that's only available with an API for a single language, but this language is Javascript instead of C.
To use such a JS library API from a non-JS language you need an FFI mechanism quite similar to the C FFI that's been implemented in most native programming languages. Being able to call efficiently back and forth between WASM and JS is this FFI feature, but you need some minimal JS glue code for marshalling complex arguments between the WASM and JS side (but you also need to do that in native scenarios, for instance you can't directly pass a Java string into a C API).
https://component-model.bytecodealliance.org/
In my opinion it's an overengineered boondoggle, since "C APIs ought to be good enough for anything", but maybe something useful will eventually come out of it, so far it looks like it mostly replaces the idea of C-APIs as lingua-franca with "a random collection of Rust stdlib types" as lingua-france, which at least to me sounds utterly uninteresting.
The good news is that you can use very minimal glue code with just a few functions to do most JavaScript operations
The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.
The point stands; maybe a faster VDOM can be built in a compile-to-wasm language, though the bottleneck will remain the browser's DOM API and rendering, not the language interpreter.
My big win on my first AJAX app was splitting read and write into two phases to reduce a page load from 30s on IE6 down to about 2 seconds. I didn’t even have to rearchitect. It was one loop in one (maybe 2) functions. Just had to split it into 2 loops.
If React wins (which I don’t agree that it does, but don’t want to have that argument), it’s that it allows you to compose tricks like this across a whole page instead of one component type.
I’ve always found this a bit specious. And indeed there are any number of libraries out there that are 4x faster than React these days. The problem is not access it’s pipelining. When the DOM is relatively homogenous there are simple code transformations and idioms that increase the render throughput by 10-50x or more. It’s interlacing reads and writes in a sequence that’s murder. So when you get to a heterogenous DOM with many different people working on different parts, it gets awkward to prevent the interlacing.
The virtual DOM is one way to force the separation, but it’s not the only way and it adds a lot of overhead, both computationally and cognitively. I can’t wait for it to die in a fire.
WASM isn't going to magically make the DOM go faster. DOM will still be just as slow as it is with Javascript driving it.
WASM is great for heavy-lifting, like implementing FFMPEG in the browser. DOM is still going to be something people (questionably) complain about even if WASM had direct access to it. And WASM isn't only used in the browser, it's also running back-end workloads too where there is no DOM, so a lot of use cases for WASM are already not using DOM at all.
https://krausest.github.io/js-framework-benchmark/current.ht...
If there ever is a WASM-native DOM API, WASM GC should help a lot with that.
I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably.
Please give us more freedom! This might be the most requested feature and this was how I came across knowing wasm in the first place (leptos video from some youtuber I think, sorry if i forgot)
WASM is just an extremely expensive toy for browsers until it supports DOM access.
The whole js ecosystem evolved to become a damn good environment to write UIs with, people don't know the massive complexity this environment evolved to solve over decades.
Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.
1. Non browser application (lightweight cloud, plugins, sandboxing)
2. Performance kernels (like compiling a game/rendering engine or AI stuff)
3. Compiling js-like applications from other languages (eg blazor wasm and others)
The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding.
Direct DOM access is otherwise mostly a red herring