[HN Gopher] Show HN: Zaplib - Speed up your webapp with Rust+Wasm
___________________________________________________________________
Show HN: Zaplib - Speed up your webapp with Rust+Wasm
Author : stevekrouse
Score : 104 points
Date : 2022-04-08 18:06 UTC (4 hours ago)
(HTM) web link (zaplib.com)
(TXT) w3m dump (zaplib.com)
| janpaul123 wrote:
| 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?
|
| (You may have seen my blog yesterday about the subtleties about
| Wasm vs JS/TS: https://zaplib.com/docs/blog_ts++.html)
| [deleted]
| FullyFunctional wrote:
| 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.
| nrabulinski wrote:
| None of the demos work in Safari on iOS.
|
| iPhone XS on iOS 15.0.2
| janpaul123 wrote:
| Safari only very recently added support for threading in Wasm,
| which we use. Try upgrading to the latest iOS (15.4.1)?
|
| It's definitely bleeding-edge stuff; we should add some
| backwards compatibility for (slightly) older browsers though.
| priansh wrote:
| 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.
| ayanb wrote:
| >> this is how Java, .NET, etc packaging is done for interop
| with Electron
|
| not certain if this should be the status quo for the longer
| term.
| heavyset_go wrote:
| What's Zapium? I searched for it, but nothing relevant came up.
| price wrote:
| Looks to be this: https://zaplib.com/docs/zapium.html
|
| > 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.
| chaosprint wrote:
| 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:
|
| https://glicol.org
|
| 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.
| janpaul123 wrote:
| That looks awesome!
|
| For debugging we support full Rust source maps in the browser
| (using DWARF). :D (This is something that wasm-bindgen doesn't
| support, for example!) See
| https://zaplib.com/docs/developer_environment.html#chrome-de...
| for how to set it up.
|
| 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.
| chaosprint wrote:
| really cool. I will try to test it on the weekend.
| janpaul123 wrote:
| 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.
| chaosprint wrote:
| 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.
| janpaul123 wrote:
| Yeah exactly; the headers are such a pain to set up!
| chaosprint wrote:
| I always encourage users to use vite, and it is quite
| easy for the dev server.
|
| https://github.com/vitejs/vite/issues/3909
|
| For deployment it's a different story then but for
| example netlify has a quite intuitive way to set headers
| for CORS:
|
| https://github.com/padenot/ringbuf.js/blob/master/public/
| _he...
| ggerganov wrote:
| 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:
|
| [0] https://github.com/ocornut/imgui
|
| [1] https://github.com/ggerganov/ggweb
| janpaul123 wrote:
| 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).
| rozgo wrote:
| 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.
| janpaul123 wrote:
| Oh cool; you're also using this for robotics I presume (based
| on your Twitter profile)? Makes sense; lots of data to
| process there.
| cglong wrote:
| 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 :)
| janpaul123 wrote:
| 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 :)
| cglong wrote:
| Yeah, it's probably the animation. The startup time was super
| fast for me! :)
| areis wrote:
| Super cool! I'm sure this is highly situational, but roughly how
| much faster can Rust -> WASM be than vanilla JS? 2x, 10x, 100x?
| janpaul123 wrote:
| 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).
| mattgreenrocks wrote:
| Wow, only a 2x difference? That is fantastic on the Wasm
| side.
| jxjshaw wrote:
| this is dope!!
___________________________________________________________________
(page generated 2022-04-08 23:00 UTC)