Hey HN, one of the creators here! I made it at Cruise because it was super painful to develop <a href="https://webviz.io" rel="nofollow">https://webviz.io</a> with manual memory management (lots of ArrayBuffers), WebWorkers, etc. I thought that there must be a better way.<p>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?<p>(You may have seen my blog yesterday about the subtleties about Wasm vs JS/TS: <a href="https://zaplib.com/docs/blog_ts++.html" rel="nofollow">https://zaplib.com/docs/blog_ts++.html</a>)
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!<p>I can't really say much else about it, but it looks interesting.<p>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:<p><a href="https://glicol.org" rel="nofollow">https://glicol.org</a><p>The audio runs in AudioWorklet thread while I guess for Zaplib it runs in Workers, right? Did you use SAB in Zaplib?<p>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.
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).<p>If you are interested, checkout my Github template repo [1] - it contains a few examples:<p>[0] <a href="https://github.com/ocornut/imgui" rel="nofollow">https://github.com/ocornut/imgui</a><p>[1] <a href="https://github.com/ggerganov/ggweb" rel="nofollow">https://github.com/ggerganov/ggweb</a>
This looks awesome. I have been playing with WASM and rust, trying to get rusqlite to work with persistence, among other things.<p>I notice that you also came to the conclusion that having all io async is not the way to go for rust.<p>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)..<p>Somewhat related is a library I've been working on to generate an ffi between Rust and js code: <a href="https://github.com/cloudpeers/ffi-gen" rel="nofollow">https://github.com/cloudpeers/ffi-gen</a><p>Also I really like your <i>universal_thread</i> abstraction, hiding the whole web worker mess. I did a similar thing here: <a href="https://github.com/wngr/wasm-futures-executor" rel="nofollow">https://github.com/wngr/wasm-futures-executor</a>
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.<p>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.
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 :)