Snappy UIs with WebAssembly and Web Workers • Hacker News Board

Re: Snappy UIs with WebAssembly and Web Workers

#11

Post by afavour » Mon, Aug 07, 2023, 4:09 PM UTC

ramesh31 wrote: post #6

afavour wrote: 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…

>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 dreamed of 5 years ago

Like what? I ask the question genuinely. WebAssembly makes it dramatically easier to do a lot of performance-sensitive things but to my mind it doesn't actually enable a whole lot of new functionality. I don't mean to write off making things easier, it's a huge deal. But if anyone asserts that we absolutely must use WebAssembly for Project X I'd really want to dive into exactly why. "It's fast" is not a good enough answer.

Re: Snappy UIs with WebAssembly and Web Workers

#12

Post by [deleted] » Mon, Aug 07, 2023, 4:21 PM UTC

afavour wrote: 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…

[deleted]

Re: Snappy UIs with WebAssembly and Web Workers

#13

Post by eyelidlessness » Mon, Aug 07, 2023, 4:25 PM UTC

afavour wrote: 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…

I think they’re vastly understating/oversimplifying how they use WASM. For audio analysis and operations on audio binary/encoded data, it’s quite possible that WASM is a very good fit. Maybe offloading that work to a JS worker would be sufficient—you’re right that JS VMs are extremely fast—but I wouldn’t necessarily discount this WASM use case either. And I’m saying that having explored these kinds of optimizations enough to generally recommend against using WASM unless you have strong reason to believe you’d benefit from it (ideally with benchmarks to prove it).

I’d also caution that using Web Workers isn’t always so obvious either (and the same applies to server side threading eg on Node). There’s significant overhead (runtime) in spinning up a worker, and in every communication between threads—enough to negate their benefit for many use cases. Both WASM and workers have roughly the same perf downsides, and both should generally be justified by real measurement of their impact.

Re: Snappy UIs with WebAssembly and Web Workers

#14

Post by karaterobot » Mon, Aug 07, 2023, 4:27 PM UTC

jauntywundrkind wrote: post #7

ramesh31 wrote: 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.

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 relatively few people you can hire for it, versus quite possibly the most well-known, well-supported language in the world. They identified some significant advantage that made the cost-benefit analysis line up.

Normally, I don't like the argument that because somebody did it, it must be the right choice. But, Figma made so many correct decisions out of the gate that, in this case, I'd give them the benefit of the doubt.

Re: Snappy UIs with WebAssembly and Web Workers

#15

Post by k__ » Mon, Aug 07, 2023, 4:28 PM UTC

ramesh31 wrote: post #6

afavour wrote: 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…

>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've used quite some graphic editing web apps, and I wouldn't count Figma to the snappy ones.

It's a bit like the Slack of graphic software.

Re: Snappy UIs with WebAssembly and Web Workers

#16

Post by eyelidlessness » Mon, Aug 07, 2023, 4:29 PM UTC

kevingadd wrote: post #10

I would caution anyone looking to make their UI "snappy": while webassembly performance for things like raw compute - especially with simd - is superior, any time you need to interface with browser APIs like the DOM to update your UI you're now going to pay a bunch of interop costs that aren't present in native JavaScript. For some workloads this will make wasm meaningfully slower - especially ones that use strings.

Or really just anything “chatty” with the main thread. Doesn’t have to be strings, or DOM, just heavy cross-VM/cross-thread interaction.

Re: Snappy UIs with WebAssembly and Web Workers

#17

Post by samwillis » Mon, Aug 07, 2023, 4:30 PM UTC

WASM and Web Workers - unless carefully used - won't magically make your UI snappy.

There are three reasons (for the vast majority of apps) that a UI feels sluggish:

1. The network! Requesting data from a server is slow, by far the slowest aspect of any app. As a start, prefetch and cache, use a CDN, try edge platforms that move data and compute closer to the user. However, if you can explore Local First (http://localfirstweb.dev), for a web app it is the way we should be looking to build in future.

2. They are doing work on the UI thread that takes longer than 16ms. This is where Web Workers are perfect, the DX around them isn't perfect, as another comment suggested Comlink helps, but there is a lot of opportunity here to build abstractions that help devs.

3. Excessive animations that delay user interaction - there is so much bad UX where animations have been added that only make things slower. Good animations have a purpose, showing where something came from or is going, and never get in the way.

Finally, we are well into diminishing returns with front end frameworks optimising the way they do templating and update the DOM. The key thing there now is DX, that is how you pick a framework, benchmarks are almost always useless.

Re: Snappy UIs with WebAssembly and Web Workers

#18

Post by kettlecorn » Mon, Aug 07, 2023, 4:34 PM UTC

afavour wrote: 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…

> Unfortuately the API for doing so on the web is extremely clunky, passing messages back and forth between a page context and a worker context.

This is one of the advantages to using WebAssembly: you can use a language like Rust that makes multithreaded code easier to write and faster to run.

Out of the box with JavaScript if you want to share an object with a worker you need to send a message (which internally serializes / deserializes the object) or manually manage serializing / deserializing bytes to a SharedArrayBuffer.

With Rust/Wasm + Web Workers you can use Rust's synchronization primitives and just pass a pointer to the worker. You pay no cost for serialization / deserialization.

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly.

As you pointed out the JavaScript VM is incredibly optimized but where Wasm shines is consistency. JavaScript requires some care to not produce garbage every frame, otherwise you may unpredictably trigger a lengthy garbage collection. With most Wasm languages you can easily avoid allocating any JavaScript garbage.

The lower-level Wasm languages also tend to be easier to reason about performance. When assessing Rust code performance you typically want to look for Big-O and excessive memory allocations. If you do find a performance bottleneck typically you know where to try to improve. With JavaScript you'll sometimes hit situations where you fall off the VM's golden path, or where one JavaScript VM performs fine and another does not.

Re: Snappy UIs with WebAssembly and Web Workers

#19

Post by [deleted] » Mon, Aug 07, 2023, 4:47 PM UTC

afavour wrote: 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…

[deleted]

Re: Snappy UIs with WebAssembly and Web Workers

#20

Post by jalk » Mon, Aug 07, 2023, 4:48 PM UTC

samwillis wrote: post #17

WASM and Web Workers - unless carefully used - won't magically make your UI snappy. There are three reasons (for the vast majority of apps) that a UI feels sluggish: 1. The network! Requesting data from a server is slow, by far the slowest aspect of any app. As a start, prefetch and cache, use a CDN, try edge platforms that move data and compute closer to the user. However, if you can explore Local First ( http://loc…

> Good animations have a purpose, showing where something came from or is going

Many websites will slowly slide a newsletter sign up form up from the bottom. We already know that it comes from the underworld, so the animation absolutely pointless there.