[ramesh31]

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

[afavour]

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.

[kettlecorn]

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.

[pjmlp]

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 .

[k__]

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.

[jauntywundrkind]

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.

[karaterobot]

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

[treis]

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

[afavour]

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

[crabmusket]

Figma were already compiling C++ to asm.js, and then switched over to WASM.

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

[kevingadd]

asm.js was capable of most of the same stuff, wasm just takes it further (with simd and native int64)

[PrimeMcFly]

> But WASM has enabled functionality on the web we could have only dreamed of 5 years ago.

Like what?