Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

11–20 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#11
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…

> 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?

Re: When Is WebAssembly Going to Get DOM Support?

#12
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…

WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet

So what should they have used to share logic between backend and frontend in a type safe way?

Re: When Is WebAssembly Going to Get DOM Support?

#13
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…

WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet

WASM enables things like running a 20 year old CAD engine written in C++ in the browser. It isn’t a scripting language, it’s a way to get high-performing native code into web apps with a sensible bridge to the JS engine. It gets us closer to the web as the universal platform.

Re: When Is WebAssembly Going to Get DOM Support?

#14
post #10

Earlier quoted context omitted.

WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet

Actually, WASM will enable many languages better for web scripting than Javascript.

WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.

Re: When Is WebAssembly Going to Get DOM Support?

#16
post #15

Has anybody written a nice DOM wrapper for C++/Rust? So you can do everything from the comforts of the C++/Rust application? The API whould match JavaScript APIs as much as possible.

Sure, in Rust the web-sys [1] crate provides auto-generated bindings for pretty much all the browser APIs.

Has been used by most of the Rust web frontend frameworks for years.

It all has to go through JS shims though, limiting the performance potential.

[1] https://docs.rs/web-sys/latest/web_sys/

Re: When Is WebAssembly Going to Get DOM Support?

#17
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…

WASM as it is, is good enough for non-trivial graphics and geometry workloads - visibility culling (given octree/frustum), data de-serialization (pointclouds, meshes), and actual BREP modeling. All of these a) are non-trivial to implement b) would be a pain to rewrite and maintain c) run pretty swell in the wasm.

I agree WASM has it’s drawbacks but the execution model is mostly fine for these types of task where you offload the task to a worker and are fine waiting a millisecond or two for the response.

The main benefit for complex tasks like above is that when a product needs to support isomorphic web and native experience - quite many use cases actually in CAD, graphics & gis) - based on complex computation you maintain, the implementation and maintenance load drops to a half. Ie these _could_ be eg typescript but then maintaining feature parity becomes _much_ more burdensome.

Re: When Is WebAssembly Going to Get DOM Support?

#18
post #10

Earlier quoted context omitted.

Actually, WASM will enable many languages better for web scripting than Javascript.

WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.

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-us/apps/aspnet/web-apps/blaz...

Beyond the browser, Wasmer does WebAssembly on the serverside: https://wasmer.io/

Fermyon too: https://www.fermyon.com/

Extism is a framework for an application to support WebAssembly plugins: https://extism.org/

Re: When Is WebAssembly Going to Get DOM Support?

#19
post #12

Earlier quoted context omitted.

WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet

So what should they have used to share logic between backend and frontend in a type safe way?

If the logic is compute heavy, Rust with Wasm can be a good approach. TypeScript on both ends is also a pragmatic choice. You can still have a boundary in the backend for lower level layers in Rust.

If the logic is merely about validation, then an IDL with codegen for TS and some backend language is probably better. There are also some more advanced languages targeting transpilation to both JS and a backend language such as Haxe, but they all have some trade-offs.

Re: When Is WebAssembly Going to Get DOM Support?

#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 the interest in that development is low.
Post reply on HN