Live data from Hacker News

Snappy UIs with WebAssembly and Web Workers

mofi.loud.red

31–40 of 68 posts

Re: Snappy UIs with WebAssembly and Web Workers

#31
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…

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

Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrot to zoom in endlessly, and more. All running at 120fps. The presentation is for the most part live-coding with this setup.

What they want to do is bring coders and designers closer together, and while some code is in Rust they developed a DSL for the GUI parts that is close to how Figma works. These GUI's can run anywhere.

And I couldn't help thinking "Why would people have complicated stacks to create Web 2.0 apps for the Google Web, when they have this?", in other words an opportunity to break out of the browser straitjacket.

Btw. WebAssembly/WebGL isn't the only way in which Makepad is available. And while running well in the browser for a time, there were issues to be solved here (addressed in the presentation). And tbh this isn't a real answer to your assertion. Greg Johnston, creator of Leptos, has made a video with performance comparisons [2].

Edit: Adding a link to the synthesizer app I just found [3].

[0] https://github.com/makepad/makepad

[1] https://www.youtube.com/watch?v=rC4FCS-oMpg

[2] https://www.youtube.com/watch?v=4KtotxNAwME

[3] https://makepad.nl/makepad/examples/ironfish/src/index.html

Re: Snappy UIs with WebAssembly and Web Workers

#32

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.

No doubt. But we don’t know what that advantage was. You could assume it was for performance related reasons. But maybe they wanted cross-platform compatibility, something WASM allows far more than JS. Or maybe they hired a load of developers experienced in making a graphic design tool rather than making a webapp and decided to use WASM to provide those developers with a more familiar environment.

Anyway, without knowing any of this it’s very difficult to say “Figma did it so we should too”.

Re: Snappy UIs with WebAssembly and Web Workers

#33
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.

This is not a Javascript problem, this is a Javascript ecosystem problem. A standard web page will load megabytes of JS code that was packaged from hundreds of dependancies for the reason that "this is how everyone does it".

I just finished a UI that requires a few HTTP requests to the API and a bit of dynamic behavior (but not a ton), and it's done inline with ES6, with no transpilers or minifiers, using ArrowJS. It does the job, and it rips.

Re: Snappy UIs with WebAssembly and Web Workers

#34
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.

Having them in wasm won't always improve them so this is a bit of a statistical fallacy.

Re: Snappy UIs with WebAssembly and Web Workers

#35
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.

You are arguing a very separate point, one that I tackle in the next paragraph.

Re: Snappy UIs with WebAssembly and Web Workers

#36

> runs at speeds you would not be able to achieve with just JavaScript Is that true? Last I heard wasm was significantly slower than vanilla JavaScript in synthetic benchmarks. Has that changed recently?

I’m interested too to see those benchmarks

Re: Snappy UIs with WebAssembly and Web Workers

#37

> 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.

I love the idea of blazor, but I have seen first hand that it can be slows as balls. But that might not be WASMS fault, it could be .net

Re: Snappy UIs with WebAssembly and Web Workers

#39
post #31
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…

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrot to zoom in endlessly, and more. All…

> And I couldn't help thinking "Why would people have complicated stacks to create Web 2.0 apps for the Google Web, when they have this?", in other words an opportunity to break out of the browser straitjacket.

Perhaps because they still believe in the promise of Web 1.0, where their app is a graceful-enhancement over an initial server-rendered document, that can be easily worked with at a DOM level by any HTML scraper, easily baked to a PDF and printed, easily re-laid-out for better readability just by changing the browser font size, easily text-to-speech'ed (including ARIA roles, alt text, etc), easily re-styled with a user-agent stylesheet, easily intermediated by browser extensions, and so forth.

I've yet to see a WASM-driven web application that's any less opaque to these technologies than a Flash or ActiveX applet would be.

Re: Snappy UIs with WebAssembly and Web Workers

#40
post #31
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…

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrot to zoom in endlessly, and more. All…

That demonstrates that you can use WebAssembly to make a snappy UI, it does not demonstrate that you must use WebAssembly.

It's nearly ten years old now but I remember being absolutely blown away by React Canvas, a UI toolkit that leveraged React but instead of rendering DOM nodes it rendered to a tag. Beautiful, 60fps stuff. All written in JS. Unfortunately all the demos seem to have disappeared since but here's a blog post about it:

https://engineering.flipboard.com/2015/02/mobile-web

Point is, both Makepad and React Canvas have something in common: they ditched the DOM. There are both advantages and disadvantages to doing so but the relevant point is that you don't need to use WebAssembly to do it.

Post reply on HN