1. Wasm based UI libraries exist already, checkout makepad [0] for example.
2. Web app standards are way higher than when flash was around. I highly doubt there would be any serious discussion that would also involve vue/react as alternatives. Almost as ridiculous as asking about using unity ui vs react.
3. Flash was world class media design tool for animation and production design. People were using it to create tv shows. Figma is nowhere close in terms of alternatives like illustrator, adobe ae, etc. So it's value as a runtime for 'cool' effects would be very limited. Which is the only reason to not use html/js because otherwise there's all kinds of small usability issues (like things not scrolling right, or not working with mobile). Figma's biggest value is it's collaborative features which is really important for ui design. I think devs (and other non-designers) overvalue Figma's importance because of lack of famliarity. It's kind of like if people thought you could use google docs or notion as an ide. After all they're both text editors right, even if jetbrains or vscode is better, it's maybe 10-20% better? But of course devs know that they're world's apart, like comparing apples to oranges.
[0] https://makepad.nl/makepad/examples/ironfish/src/index.html
WASM gave Figma a lot of speed by default for a lot of perf-sensitive code like rendering, layouts, applying styles and materializing component instances, our GUI code is mostly React and CSS.
WASM engine performance has not been a problem for us, instead we are constantly looking forward improvements in the devex department: debugging, profiling and modularization.
One of the largest challenges of the platform we face today is the heap size limit. While Chrome supports up to 4GB today, that's not yet the case for all browsers. And even with that, we are still discovering bugs in the toolchain (see this recent issue filed by one of our engineers) https://github.com/emscripten-core/emscripten/issues/20137
The challenge of the perf-testing at scale in our company is helping developers to detect perf regressions when they don't expect them - accidental algorithmic errors, misused caches, over-rendering React components, dangerously inefficient CSS directives, etc.
Overall we're pretty minimal when it comes to animations in product (i.e. here's a quick 22s recording of navigating between screens/opening properties panels in product today: https://video.non.io/video-2940009905.mp4) as we really want to convey that the app is snappy/performant. Definitely keen on diving in if you're experiencing otherwise. Happy to chat here or my email is jake@figma.com.
Regarding platform specific performance - it shouldn't affect things as long as you have GPU acceleration enabled. The majority of us over here at Figma are using OSX FWIW.
https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://www.figma.com/blog/figma-faster/
There's a great post by Ian Hickson, the project lead of Flutter, about how we might have more WASM based web apps while keeping the DOM for content based websites:
> This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.
That will take a while to come together. Key blockers are removal of the feature flags currently needed to enable things like garbage collection in Firefox and Chrome and the completion of Kotlin 2.0 and it's new compiler (K2) which is currently available via a feature flag in the Kotlin 1.9 stable release. My estimation is that we're about 6 months away from those blockers being resolved. IOS support is likely to transition to beta around the same time. From there to being stable and well supported is probably another year or so.
But a lot of stuff works right now already. However, it's not suitable for production usage because of the early development status the various bits and pieces you need and the need for toggling browser feature flags.
There are some nice examples of IOS support in the recent release notes for compose web: https://blog.jetbrains.com/kotlin/2023/08/compose-multiplatf...
They don't really mention Wasm there as this mostly focuses on the IOS support. They had a lot of presentations about that at kotlin conf and the compose web channel in the kotlin slack is very active.
Basically, anyone currently doing mobile development that is used to modern UI frameworks for that, will soon be able to target browsers effortlessly without compromising on their UI frameworks. Compose is one of the frameworks. But there are others. I've seen some nice kotlin-js frameworks targeting canvas and vector graphics. Doodle is a nice example: https://nacular.github.io/doodle/. I have not used that yet but it looks quite slick. A lot of kotlin-js stuff will transition to wasm once the compiler stabilizes.
Web developers seem to be mostly unable to see beyond their comfort zone of DOM/CSS/JS. There are alternative ways of doing UI/UX that are common outside of browsers. Applying that in a browser is transitioning from impossible (a few years ago) to being hard but very feasible (the last few years) to being easy, very common, and widely supported across different developer ecosystems (the next few years). Not a matter of if but when.
Is your GPU doing any work? What are the results from here? https://pmndrs.github.io/detect-gpu/
Honestly I guess it's similar in capabilities to the early web before the introduction of JavaScript, where all custom code had to run on the server. Maybe Apple's plan is to increase capabilities over time the same way the web did. I kind of don't think so, though.