When Is WebAssembly Going to Get DOM Support? • Hacker News Board

Re: When Is WebAssembly Going to Get DOM Support?

#111

Post by octopoc » Wed, Jul 23, 2025, 4:19 PM UTC

serbuvlad wrote: post #108

rkangel wrote: post #102

Earlier quoted context omitted.

These numbers are true, but you'd be amazed and the number of organisations that have containers that are just based on ubuntu:latest, and don't strip package cache etc.

ubuntu:latest is also 30MB, like Debian. Obviously an unoptimized C++/Python stack that depends on a billion .so's (specific versions only) and pip packages is going to waste space. The advantage of containers for these apps is that it can "contain" the problem, without having to rewrite them. The "modern" languages: Go and Rust produce apps that depend either only on glibc (Rust) or on nothing at all (Rust w/ musl a…

You know what would be cool? A built in way for your browser to automatically download and run local-first software as a docker container, in the background without user confirmation.

The problem with that idea is docker isn’t as secure as wasm is. That’s one big difference: wasm is designed for security in ways that docker is not.

The other big difference is that wasm is in-process, which theoretically should reduce overhead of switching between multiple separate running softwares.

Re: When Is WebAssembly Going to Get DOM Support?

#112

Post by Doohickey-d » Wed, Jul 23, 2025, 4:28 PM UTC

tcfhgj wrote: post #78

tlb wrote: post #60

Earlier quoted context omitted.

I use it for a web version of some robotics simulation & visualization software I wrote in C++. It normally runs on as an app on Mac or Linux, but compiling to WASM lets me show public interactive demos. Before WASM, the options were: - require everyone to install an app to see visualizations - just show canned videos of visualizations - write and maintain a parallel Javascript version Demo at https://throbol.com/she…

> Throbol requires WebGPU. Try with Chrome, Edge, Safari, or Opera.

It's almost there: firefox has shipped it for windows (to begin with): https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-...

And safari is coming soon.

So not too long untill it'll be usable.

Re: When Is WebAssembly Going to Get DOM Support?

#113

Post by jazzypants » Wed, Jul 23, 2025, 4:28 PM UTC

CrimsonRain wrote: post #61

breve wrote: post #18

Earlier quoted context omitted.

It is happening. Leptos is an example: https://www.leptos.dev/ Dioxus is another: https://dioxuslabs.com/ C# with Avalonia for a different use case: https://avaloniaui.net/ Avalonia solitaire demo: https://solitaire.xaml.live/ Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/ Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-…

how'd you compare dioxus and leptos?

If you're familiar with JS frameworks, you can think of it like this:

Dioxus : React :: Leptos : SolidJS

The key for me is that Leptos leans into a JSX-like templating syntax as opposed to Dioxus's H-like function calls. So, Leptos is a bit more readable in my opinion, but that probably stems from my web dev background.

The Dioxus README has a whole section comparing them -- https://github.com/DioxusLabs/dioxus#dioxus-vs-leptos

Re: When Is WebAssembly Going to Get DOM Support?

#114

Post by adastra22 » Wed, Jul 23, 2025, 4:29 PM UTC

Aardwolf wrote: post #99

adastra22 wrote: post #86

Earlier quoted context omitted.

The fact that we said “Java” and you went to thinking about “Java applets” is part of the problem. Java was meant to be a universal executable format. It ended up confined to the web (mostly, at least in the popular consciousness).

Well actually that was because the topic of the article was webassembly :) I have seen Java used for backends / software as well (and other than the lack of unsigned integers for e.g. crypto/hashing/compression/..., and lack operator overloading for e.g. vectors/matrices/bigints/..., it's 'fine' to me)

But that’s the point! “Web” Assembly really has nothing to do with the web, or browsers :) It came out of the web standards groups, that’s all. It is an architecture agnostic executable format.

Re: When Is WebAssembly Going to Get DOM Support?

#115

Post by jkcxn » Wed, Jul 23, 2025, 4:33 PM UTC

jffry wrote: post #82

MisterTea wrote: post #80

I am confused by this. If WASM is a VM then why would it understand the DOM? To me it akin to asking "When will Arm get DOM support?" Seems like the answer is "When someone writes the code that runs on WASM that interacts with the DOM." Am I missing something? (not a web dev.)

The WASM VM doesn't have any (direct) access to the DOM, so there's no code you can write in it that would affect the DOM. There's a way to make JS functions callable by WASM, and that's how people build a bridge from WASM to the DOM, but it involves extra overhead versus some theoretical direct access.

That's like saying WASM doesn't have a direct way to allocate memory or print to the console. Of course it doesn't, it doesn't have access to anything, that's the whole point.

Re: When Is WebAssembly Going to Get DOM Support?

#116

Post by xg15 » Wed, Jul 23, 2025, 4:35 PM UTC

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy.

This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs fast, but requires so many switching steps that all performance benefits are undone again.

Re: When Is WebAssembly Going to Get DOM Support?

#117

Post by valorzard » Wed, Jul 23, 2025, 4:38 PM UTC

hardwaresofton wrote: post #31

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects Just a note, but there is burgeoning support for this in "modern" WebAssembly: https://github.com/bytecodealliance/jco/tree/main/examples/c... If raw WebIDL binding generation support isn't interesting enough: https://github.com/bytecodealliance/jco/blob/main/packages/j... https://github.com/bytecodealliance/jco/blob/main/p…

You should write an article about this stuff and post it here since this is the first time I’m hearing about all of this

Re: When Is WebAssembly Going to Get DOM Support?

#118

Post by xg15 » Wed, Jul 23, 2025, 4:46 PM UTC

jkcxn wrote: post #115

jffry wrote: post #82

Earlier quoted context omitted.

The WASM VM doesn't have any (direct) access to the DOM, so there's no code you can write in it that would affect the DOM. There's a way to make JS functions callable by WASM, and that's how people build a bridge from WASM to the DOM, but it involves extra overhead versus some theoretical direct access.

That's like saying WASM doesn't have a direct way to allocate memory or print to the console. Of course it doesn't, it doesn't have access to anything, that's the whole point.

I think a good analogy would be between user-space and kernel-space code.

It's just weird that by this logic, JavaScript - the more high-level, less typesafe and less performant language - would be the kernel, while performance-optimized WASM code would be the userspace program.

Re: When Is WebAssembly Going to Get DOM Support?

#119

Post by naikrovek » Wed, Jul 23, 2025, 4:47 PM UTC

The fact that this needs to be explained with mentions of pointers and data alignment and garbage collection tells me that the decisions that the web standards committees make continue to be just completely disconnected from anything sane.

maybe my read is wrong, but everything i look at today just screams to me that the web is extremely poorly designed; everything about it is simply wrong.

Re: When Is WebAssembly Going to Get DOM Support?

#120

Post by fabrice_d » Wed, Jul 23, 2025, 5:00 PM UTC

nothrabannosir wrote: post #95

chrismorgan wrote: post #11

Earlier quoted context omitted.

> Why create a generic bytecode execution platform and limit the use case so much? How would you make such a thing without limiting it in some such way?

By giving it dom support

Which meant having garbage collection working accross the WASM/JS barrier. This is now possible, but was not exactly trivial to design. It's a good thing that this was not rushed out.