Hey HN, one of the creators here! I made it at Cruise because it was super painful to develop https://webviz.io with manual memory management (lots of ArrayBuffers), WebWorkers, etc. I thought that there must be a better way.
Very curious to hear stories from other folks building intensive stuff in the browser. How are you dealing with performance issues in Javascript? Have you tried using Rust or C++ with WebAssembly for parts of your apps? How did you make 2d/3d rendering faster? Would you want to use something like Zaplib?
Curious as to what the JS bridge overhead is like for both latency and throughput. What would the performance look like if you tried to serialize DOM updates over the bridge and replay them on the JavaScript side so that you could build DOM UIs? Have you measured # of updates per ~16ms?
(I know there is some proposal that might allow WASM to interact with the DOM directly too, but I don't know how likely it will be merged.)
Overhead of calling into JS from Wasm is very low; DOM calls are no problem since the DOM call itself is much slower than the overhead of switching from Wasm to JS. See e.g. this article from ~4 years ago: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
There are even some libraries that try to mimic React directly from Rust, such as https://yew.rs/ (though in my experience they can be a bit harder to use than Zaplib, since they require you to learn about traits, closures, etc, and tend to also run into borrow checker issues more often -- all of those are things we try to avoid having to learn in Zaplib!)
Hot damn I nearly got a seissure from watching the demo page. I'm sure flickering mess I see with Firefox 98.0.2 wasn't what they intended!
I can't really say much else about it, but it looks interesting.
ADD: not complaining about the down votes, but I wasn't kidding. I think it's malfunctioning in my browser in a literally dangerous way. I would record a video of it if it wasn't so annoying to upload. I'm guess nobody else sees this?
Great work. Put it on my favourite list now. Do you have any tips for debugging? I use the same combo Rust-WASM for my Glicol music programming language:
The audio runs in AudioWorklet thread while I guess for Zaplib it runs in Workers, right? Did you use SAB in Zaplib?
For me, one use case is to use Zaplib for visualising the audio. The built-in canvas and 2d drawing is really slow. Yet one concern is for the support on Safari. It really has a slow support for SAB. I have to switch to postMessage on Safari as a compromise.
Since we also support running the Rust code natively (even when doing rendering!) you can also use that and attach whatever native debugger you like. That same page also has info on how to set up native debugging with VSCode.
Re audio: yeah we currently only use Web Workers and we don't have audio support yet. We do use SAB, but we're thinking of adding support for running without SAB so you can use it with older browsers.
That would be a smart move as SAB also requires CORS now, which adds more trouble for getting started. It can be a feature to keep for some context that really needs to get rid of GC such as audio.
I've been using a similar stack (C++ and WASM) to build some simple applications and I enjoy it very much. For the UI components, text rendering and layout I use Dear ImGui [0] as I am very familiar with it and it allows me to implement GUIs very fast. The biggest convenience is that you can run the same code both as a native application and as a web app. The biggest drawback is you usually get 100% CPU usage when there is an active animation in the WebGL canvas because you need to redraw everything (similar to the OP's example).
If you are interested, checkout my Github template repo [1] - it contains a few examples:
Very cool! We do throttle our animations to the screen's refresh rate using requestAnimationFrame, so you shouldn't necessarily get 100% CPU unless the animation takes up the entire "frame budget" (on my machine the main example in the introduction is more like ~40-50% CPU on Chrome).
Usually not an issue with very interactive apps. We have a similar workflow targeting web and desktop, but Rust + WASM. Using BevyEngine for real-time apps, and Yew for web apps.
This looks awesome. I have been playing with WASM and rust, trying to get rusqlite to work with persistence, among other things.
I notice that you also came to the conclusion that having all io async is not the way to go for rust.
How do you wrap the async js io apis so they can be used in sync rust? I have seen different approaches for this: 1. an additional service worker / thread and atomics. 2. rewrite the entire WASM in some sort of continuation passing style.
Nice project, although pretty opinionated. But I guess you have to do that when targeting the crazy browser environment with all its weird quirks (at least for non-web devs)..
This is really cool but I can’t say I’m a fan of Zapium given it would move to a commercial license in the future. If you have to ship CEF anyhow, what is the performance advantage to licensing and using Zapium over just compiling WASM and shipping binaries with Electron? FWIW — this is how Java, .NET, etc packaging is done for interop with Electron.
I can understand from an ease of use perspective to have the bridge in between but it wouldn’t be worth subjecting a codebase to commercial licensing IMO. It’s not a whole lot more work to use process calls instead there so it seems an odd choice to commercialize that aspect in particular.
> Zapium is the native, cross-platform Zaplib runtime. It converts Zaplib web apps to desktop apps, where the Rust code runs natively, not via WebAssembly.
> This is Zaplib's equivalent of Electron -- for an extra speed boost.
Great question! I wrote a blog post yesterday going into the nuances of this a bit: https://zaplib.com/docs/blog_ts++.html The short of it is that Rust+Wasm isn't much faster than highly optimized JS in most situations, but it's hard to optimize it. In Rust it's a lot easier to get to the same level of performance as highly optimized JS.
We also support building compiling to native though, and we've found that the typical difference between Wasm and native apps is about 2x (on most metrics).
Just tried opening this on my cheap Android phone; really appreciate that the whole page stayed usable! There was some noticable lag though, which I don't see on advanced Three.js apps. So some further performance tuning might be needed :)
Yeah, might be the continuous animation that we're doing! Or do you mean the startup time? There's definitely still a lot of room for us to optimize stuff :)
Very curious to hear stories from other folks building intensive stuff in the browser. How are you dealing with performance issues in Javascript? Have you tried using Rust or C++ with WebAssembly for parts of your apps? How did you make 2d/3d rendering faster? Would you want to use something like Zaplib?
(You may have seen my blog yesterday about the subtleties about Wasm vs JS/TS: https://zaplib.com/docs/blog_ts++.html)