Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

Post reply on HN
Print view View original

21–30 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#21

Post by flohofwoe »

sfvisser wrote: post #3

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer…

> I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often.

It's fine and fast enough as long as you don't need to pass complex data types back and forth. For instance WebGL and WebGPU WASM applications may call into JS thousands of times per frame. The actual WASM-to-JS call overhead itself is negligible (in any case, much less than the time spent inside the native WebGL or WebGPU implementation), but you really need to restrict yourself to directly passing integers and floats for 'high frequency calls'.

Those problems are quite similar to any FFI scenario though (e.g. calling from any high level language into restricted C APIs).

Re: When Is WebAssembly Going to Get DOM Support?

#22

Post by criticalfault »

I've been reading about this for a while. Will it. Won't it.

Does anybody know why is it such a big problem to add dom access to wasm?

In worst case, we should have a second option to Js (which is not typescript - typescript is just a lipstick on a pig). If wasm is not it, why not something different? Having dart in would be great.

Re: When Is WebAssembly Going to Get DOM Support?

#23

Post by flohofwoe »

theSherwood wrote: post #20

I want DOM access from WASM, but I don't want WASM to have to rely on UTF-16 to do it (DOMString is a 16-bit encoding). We already have the js-string-builtins proposal which ties WASM a little closer to 16-bit string encodings and I'd rather not see any more moves in that direction. So I'd prefer to see an additional DOM interface of DOMString8 (8-bit encoding) before providing WASM access to DOM apis. But I suspect…

Tbh I would be surprised if converting between UTF-8 and JS strings is the performance bottleneck when calling into JS code snippets which manipulate the DOM.

In any case, I would probably define a system which doesn't simply map the DOM API (objects and properties) into a granular set of functions on the WASM side (e.g. granular setters and getters for each DOM object property).

Instead I'd move one level up and build a UI framework where the DOM is abstracted away (quite similar to all those JS frameworks), and where most of the actual DOM work happens in sufficiently "juicy" JS functions (e.g. not just one line of code to set a property).

Re: When Is WebAssembly Going to Get DOM Support?

#24

Post by flohofwoe »

criticalfault wrote: post #22

I've been reading about this for a while. Will it. Won't it. Does anybody know why is it such a big problem to add dom access to wasm? In worst case, we should have a second option to Js (which is not typescript - typescript is just a lipstick on a pig). If wasm is not it, why not something different? Having dart in would be great.

> Does anybody know why is it such a big problem to add dom access to wasm?

Well, the article does a pretty good job of answering this specific question ;)

Re: When Is WebAssembly Going to Get DOM Support?

#25

Post by boomskats »

BlackFly wrote: post #4
sfvisser wrote: post #3

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer…

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organi…

> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access

I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're implying here.

> The browser is the main driving force for WASM, as I see it

This hasn't been the case for a while. In your first paragraph you yourself say that 'the people furthering WASM are [...] building a whole new VM ecosystem that the browser people aren't interested in' - if that's the case, how can the browser be the main driving force for Wasm? It's true, though, that there's verey little revenue in browser-based Wasm. There is revenue in enterprise compute.

> because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container

Not exactly true when you consider that docker containers are orders of magnitude bigger, slower to mirror and start up, require architecture specific binaries, are not great at actually 'containing' fallout from insecure code, supply chain vulns, etc.. The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. They just rarely make it to the hn frontpage, because they really are boring.

However, the Wasm push in enterprise compute is real, and the value is real. But you're right that the ecosystem and its sponsorship is still struggling - in some part due to lack of support for the component model by the browser people. The component model support introduced in go 1.25 has been huge though, at least for the (imho bigger) enterprise compute use case, and the upcoming update to the component model (wasi p3) should make a ton of this stuff way more usable. So it's a really interesting time for Wasm.

Re: When Is WebAssembly Going to Get DOM Support?

#26

Post by flohofwoe »

weinzierl wrote: post #5
jauntywundrkind wrote: post #2

Law of question marks on headlines holds here: no / never seems to be the answer. Article l also discussed ref types, which do exist and do provide... Something. Some ability to at least refer to host objects. It's not clear what that enables or what it's limitstions are. Definitely some feeling of being rug-pulled in the shift here. It felt like there was a plan for good integration, but fast forward half a decade+…

"Definitely some feeling of being rug-pulled in the shift here." Definitely feeling rug-pulled. What I think all the people that hark on the "Don't worry, going through JS is good enough for you." are missing is the subtext of their message. They might objectively be right, but in the end what they are saying is that they are content with WASM being a second class citizen in the web world. This might be fine for ever…

> that they are content with WASM being a second class citizen in the web world

Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity.

Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution.

I think what people need to understand is that the idea of having 'pure' WASM browser applications which don't involve a single line of Javascript is a pipe dream. There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript.

Some web APIs have started to 'appease' WASM more by adding 'garbage free' function overloads, which IMHO is a good thing because it may help to reduce overhead on the JS side, but this takes time and effort to be implemented in all browser (and most importantly, a will by mostly "JS-centric" web people to add such helper functions which mostly only benefit WASM).

Re: When Is WebAssembly Going to Get DOM Support?

#29

Post by pjmlp »

BlackFly wrote: post #4
sfvisser wrote: post #3

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer…

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organi…

Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.

Re: When Is WebAssembly Going to Get DOM Support?

#30

Post by nikeee »

Havoc wrote: post #28

> Wasm includes various JavaScript APIs that allow compiler-generated glue code One of the reasons I’m interested in wasm is to get away from the haphazardly evolved JS ecosystem…

I wouldn't be that sure if we'd want to exchange that for an ecosystem that consists of many different languages that all have their own ecosystem wich may not be compatible with WASM. Imagine needing nuget, maven and cargo -- all in their specific version -- to build a project.
Post reply on HN