Live data from Hacker News

Snappy UIs with WebAssembly and Web Workers

mofi.loud.red

21–30 of 68 posts

Re: Snappy UIs with WebAssembly and Web Workers

#21
Web Workers are a really great feature for performance. The way they want the worker code to live in a separate file makes them slightly annoying if you're using a bundler, but each bundler has a loader or similar feature for this, so all is mostly well.

But the thing I haven't found a solution for is, the case where you want to use web workers inside a library that other people will be importing into their own project, and you don't know what bundler they'll use (or transpiler, minifier, etc). I can think of hairy ways to do it, that involve pre-building the worker JS and storing that text in your library, piping it into a file blob at runtime, or the like. But does anyone know a clean way of handling this?

Re: Snappy UIs with WebAssembly and Web Workers

#23
post #11
post #6

Earlier quoted context omitted.

>I'm fascinated by WebAssembly and love that it exists but if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. The Figma team would say differently. For 99% of CRUD app use cases you are absolutely correct. But WASM has enabled functionality on the web we could have only dreamed of 5 years ago.

I'd argue that's part of the interrogation. "We should use WebAssembly because Figma does and Figma is fast" is faulty logic. Are you making a product with the level of complexity of Figma? OK but are you really ? Are you sure WebAssembly is what makes Figma fast? If so, what are they using WebAssembly for? Is there an overlap with what you're doing? > WASM has enabled functionality on the web we could have only drea…

WebAssembly doesn't provide any new functionality much in the same way cars did not when compared to horse-drawn carriages. You can argue that everything you can do with Wasm can be done with JavaScript, but often it involves significantly greater effort.

Where Wasm is a massive improvement:

* Ability to use existing C++/C/Rust code without a rewrite.

* Performance consistency through languages with manual memory-management and more straightforward performance characteristics.

* Performance of working with multithreaded code by using languages that can pass pointers and avoid message-passing overhead.

* This last point is somewhat unproven as it's related to my own personal work, so take it with a grain of salt! Wasm has unique properties that allow it to be augmented to run complex, seemingly unnetworked, code perfectly synchronized between computers with very little latency in the UX. I'm convinced it can eliminate a whole class of complex networking / sync issues. I first demonstrated the concept earlier this year with tanglesync.com, but I'm currently working on a follow-up.

Re: Snappy UIs with WebAssembly and Web Workers

#24

Earlier quoted context omitted.

It's an impressive app but I as the parent said, I'd expect JS would have worked just fine & let you do all the same things, at essentially the same speed. The key differentiation, as the parent says, is using Web Workers to make sure you're not doing work on the main thread.

> I'd expect JS would have worked just fine & let you do all the same things, at essentially the same speed I think you would be wrong about that. Certainly, it's not just WASM that makes Figma fast, but it's an important piece. Look at it this way: why would they have built out the product with WASM five years ago if Javascript was just as good for their use case? It's a huge investment in a new technology with rela…

> They identified some significant advantage that made the cost-benefit analysis line up.

I don't know if this is true or not but I don't rate the fact that they used it as much evidence that they should have used it. IME decisions like this are because some early engineer wanted to use that particular bit of technology.

Re: Snappy UIs with WebAssembly and Web Workers

#25
post #3

I'm fascinated by WebAssembly and love that it exists but if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. I don't want to speak to this example too deeply because I don't know it (I see they're doing all sorts of stuff with audio so maybe they do need WebAssembly) but modern JavaScript VMs are very, very fast. 99% of webapps are absolutely f…

Those are good recommendations, and they confirm my own findings and experience trying to improve performance for Spectrogram and Waveform generation in a heavy audio focused web app.

AssemblyScript and Rust/WASM implementation of these relatively simple but computationally heavy algorithms didn’t result in any meaningful improvements of their JS counterparts. In the end moving computations that took 10ms or more (some up to 700ms) off main thread and using tooling to simplify the WebWorker API was definitely more gainful, simpler and better for code hygiene, and in most cases as fast or faster than the WASM implementations.

Re: Snappy UIs with WebAssembly and Web Workers

#26
Even just JavaScript Web Workers can be really helpful for doing heavy compute outside of the UI thread. JavaScript is pretty fast, it just needs to be unblocked. I used them once to sort a six-digit array of objects client side, while keeping the UI snappy (it took a couple seconds to process, but the UI was responsive the whole time)

Of course for some tasks you'll still need more than that, which very well may have been true for the OP, but benchmarking is good etc

Re: Snappy UIs with WebAssembly and Web Workers

#27
> Running Fast(er) With WebAssembly

How much faster?

I have to ask because people frequently make claims about perform based upon unmeasured assumptions that are wrong more often than not. Worse than that, many of these imagined claims about performance tend to be off by one or more orders of magnitude.

Re: Snappy UIs with WebAssembly and Web Workers

#29
post #11

Earlier quoted context omitted.

I'd argue that's part of the interrogation. "We should use WebAssembly because Figma does and Figma is fast" is faulty logic. Are you making a product with the level of complexity of Figma? OK but are you really ? Are you sure WebAssembly is what makes Figma fast? If so, what are they using WebAssembly for? Is there an overlap with what you're doing? > WASM has enabled functionality on the web we could have only drea…

WebAssembly doesn't provide any new functionality much in the same way cars did not when compared to horse-drawn carriages. You can argue that everything you can do with Wasm can be done with JavaScript, but often it involves significantly greater effort. Where Wasm is a massive improvement: * Ability to use existing C++/C/Rust code without a rewrite. * Performance consistency through languages with manual memory-man…

Already offered by PNaCL, and CrossBridge, in 2010, in what concerns C and C++.

https://adobe-flash.github.io/crossbridge/

Still waiting for those wonderful WebAssembly + WebGL games that can match Infinity Blade for iOS from 2010, the game Apple used to show off iOS GL ES 3.0 capabilities.

Or something better that citadel demo, beyond the asm.js port done by Mozzilla .

Re: Snappy UIs with WebAssembly and Web Workers

#30
post #3

I'm fascinated by WebAssembly and love that it exists but if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. I don't want to speak to this example too deeply because I don't know it (I see they're doing all sorts of stuff with audio so maybe they do need WebAssembly) but modern JavaScript VMs are very, very fast. 99% of webapps are absolutely f…

> 99% of webapps are absolutely fine using JavaScript.

as a user, much less than 99% of apps are "absolutely fine" to use.

Post reply on HN