Writing an entire web frontend in Zig with wasm-api: when does it make sense?

I have recently tried out a cool library called wasm-api. This library allows you to create a entire web frontend in Zig (event listeners included).

On the JS host side (i.e. the browser) you just need to instantiate a WasmBridge object. On the Zig side you implement your UI components and your event handlers.

It seems to me that wasm-api (and its supported libraries wasm-api-dom, wasm-api-canvas and wasm-api-schedule) aims to be something similar to Yew in Rust.

My question is: does anybody know of some use cases when it actually make sense to implement a UI (or a fraction of an entire UI) in WebAssembly instead of in JS? Is anybody aware of any benchmarks in this regard? This is the only relevant link I was able to find:

https://www.reddit.com/r/rust/comments/s4pw6n/frontend_rust_framework_performance_prognosis/

7 Likes

I found this video relatively good regarding performance:

But this is from the Leptos maintainer so it is slightly biased.

This is the performance test used in the video: Interactive Results

As far as I remember: Architecture matters regarding performance. E.g. Leptos and other frameworks (js or not) use different architecture then React ir Yew, which is part of the reason they are more performant.

I think the main reason to use non-JS frameworks for Web frontend is, tgat you don’t want to use JavaScript. With WASM this is now possible. Using JS may still be the best option.

6 Likes

With Autodoc we originally considered using wasm but it seemed that the performance hit would have been non-insignificant compared to just using JS.

Now that development has gone forward and that we started thinking of new functionality to add to Autodoc (including but not limited to being able to reuse Zig code), the wasm approach is back on the table.

The annoying part of using wasm to drive the frontend is that, even setting aside the clunkyness of passing around references to dom elements, the wasm side and the JS side can’t share strings, so if you want to have both sides to reason about a token (in the case of autodoc, for example), then those bytes will need to be somehow duplicated on both sides.

There’s a WASM proposal to improve interop, but I don’t know when it’s going to be accepted, or if it will at all as JS engines seem to hate the idea of switching to utf8, which IMO is a prerequisite for this proposal to make any kind of sense.

If you wait a bit, you’ll be able to see how we fare in Autodoc :^)

9 Likes