Keeping Figma Fast: perf-testing the WASM editor(figma.com)
figma.com
Keeping Figma Fast: perf-testing the WASM editor
https://www.figma.com/blog/keeping-figma-fast/
98 comments
Absolutely! Evan and the early team laid a strong foundation when Figma was ported to WASM + WebGL. It happened before my time at Figma, but check out these earlier posts from Evan and Jamie on the transition, perf testing, and graphs back from 2017-2018:
https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://www.figma.com/blog/figma-faster/
https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://www.figma.com/blog/figma-faster/
Also the creator and maintainer of ESBuild!
What do your mean? Did he contribute to the WASM standard?
Former?! When did Evan step down?
"I cofounded Figma in 2012 with Dylan Field and worked on Figma as CTO for the better part of a decade, leaving in 2021"
From https://madebyevan.com/figma/
From https://madebyevan.com/figma/
That's kind of wild to me to see an app like Figma that's a commercial success, but also a demonstration of technical excellency. My brain automatically assumes that you can't pick both commercial success and technical excellency at the same time and must compromise on the latter to build more features. But maybe there is hope and users actually love the benefits of a better tech stack (performance, consistency, stability) and maybe it's easier to build features with an excellent technical foundation.
Your assumption was correct most of the time. 99% of tech startups are not innovating technically. They are applying existing tech to new problems. In these cases, quality engineering is low priority.
But there is that other 1% that is making new things possible. And if they are extremely lucky, they’ll build new tech and figure out how to turn it into a product. Figma is an example of what can happen when that mix hits.
Most technical innovations, though, will be licensed/sold/etc. to other companies which fall into the first group.
All that said, it turns out customers love software that works well. Startups (and most software companies, really) undervalue quality because it’s hard and not strictly necessary when there’s no direct competition.
But there is that other 1% that is making new things possible. And if they are extremely lucky, they’ll build new tech and figure out how to turn it into a product. Figma is an example of what can happen when that mix hits.
Most technical innovations, though, will be licensed/sold/etc. to other companies which fall into the first group.
All that said, it turns out customers love software that works well. Startups (and most software companies, really) undervalue quality because it’s hard and not strictly necessary when there’s no direct competition.
Sometimes commercial success is due to technical excellence. Especially in overcrowded fields just being better is enough.
> My brain automatically assumes that you can't pick both commercial success and technical excellency at the same time
The problem is your anchor point. Your idea of what software can and should be is based on? Gmail? Salesforce? The GTAV loading screen? The iOS warning that you’re running out of icloud storage space?
Silicon Valley software expectations are tainted by recency bias and private equity excrement.
The current ceiling to aspire to is literally “CI passes”
The problem is your anchor point. Your idea of what software can and should be is based on? Gmail? Salesforce? The GTAV loading screen? The iOS warning that you’re running out of icloud storage space?
Silicon Valley software expectations are tainted by recency bias and private equity excrement.
The current ceiling to aspire to is literally “CI passes”
Really awesome work! If the authors happen to drop by, I'd be curious if some of the work in their pipeline might be able to help for other types of GUI applications with Wasm. I'm also very curious to see what role, if any the Wasm engine's performance plays in the overall story, and be able to distill out any key workloads that can help Wasm engines improve.
Thank you for your comment!
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.
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.
+1 to heap size limit speaking as a PM over here at Figma. We regularly see files with hundreds of thousands of layers, and trying to keep those enormous files under 2GB of memory for usage across all supported browsers is a constant struggle.
Would love to see that cap get raised across the board, it'd enable us and others to do so much more.
Would love to see that cap get raised across the board, it'd enable us and others to do so much more.
It's amazing what we lost moving from desktop to retrograde world of the web. I wonder what's next in the indirection game?
If you think the web is bad, check out what Apple is planning for their AR headset. The future is apparently a platform so locked down that as a developer you can't directly access the primary input device (eye tracking) at all, you can only pick from a palette of predefined UI behaviors. You can't have access to the cameras to do any custom computer vision; hope you like the primitives Apple deigns to provide to you. And you can't even write your own shaders to render custom graphics; you'll have a preset material model and you'll like it. https://twitter.com/Tojiro/status/1667028702734209025
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.
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.
If you put a shareable state into desktop apps it could swing the other way. I'm not a designer but to just put a url to a mock-up is amazing.
VR. Super constrained.
AR like how Microsoft and apple envision it is freeing in a lot of ways.
Circular interfaces? No worries. Persistent always on top but small and low utilization? Not a problem. spatial contact aware apps? Gimme.
Dev Ex Is going to suck hard for a long time, but good AR hardware will be the opposite of constrained.
Circular interfaces? No worries. Persistent always on top but small and low utilization? Not a problem. spatial contact aware apps? Gimme.
Dev Ex Is going to suck hard for a long time, but good AR hardware will be the opposite of constrained.
Seeing a 20% margin of error for some of their tests (due to VMs, noisy neighbors), makes me curious how others solve this problem. Dedicated hardware seems like a good investment, otherwise you need to constantly overcompensate with multiple runs.
Hey, I am one of the authors of the article and the systems described.
The default 20% margin of error is indeed pretty wide, and it is intended to catch large obvious regressions (e.g. an algorithm accidentally becoming quadratic instead of being linear)
As we described in the blog post, we have the second system based on the real hardware. This system is on-demand. If an engineer has a suspect commit or an experimental change that might affect performance, they would schedule a 30min-1hr run on that queue, where we run selected benchmarks 9-15 times each on laptops of various strength. In this configuration, the margin of error is closer to 2-3% from our observations so far. To get more confidence, you would want to run even more trials, typically we advise 9 iterations, though.
We also do all our daily benchmarking on those laptops too.
Edit: in addition to preventative testing, we also track production metrics in a similar way as described by the sibling comment
The default 20% margin of error is indeed pretty wide, and it is intended to catch large obvious regressions (e.g. an algorithm accidentally becoming quadratic instead of being linear)
As we described in the blog post, we have the second system based on the real hardware. This system is on-demand. If an engineer has a suspect commit or an experimental change that might affect performance, they would schedule a 30min-1hr run on that queue, where we run selected benchmarks 9-15 times each on laptops of various strength. In this configuration, the margin of error is closer to 2-3% from our observations so far. To get more confidence, you would want to run even more trials, typically we advise 9 iterations, though.
We also do all our daily benchmarking on those laptops too.
Edit: in addition to preventative testing, we also track production metrics in a similar way as described by the sibling comment
Thanks for your reply. Can you share how these laptops are managed? I took another look at the article but didn't find that information there.
I.e I'm curious if there's a cloud provider managing them for you or you guys keep them in a closet somewhere.
I.e I'm curious if there's a cloud provider managing them for you or you guys keep them in a closet somewhere.
We omitted the details for the sake of brevity (the article is already really long), but we run agents on the test devices and plug them into CI. Agents allow remote access for servicing remotely, and that's enough most of the time.
For things like system updates and taking care of the hardware - we do it manually today. The fleet is still small, so it is manageable but in the future we would like to consider a vendor, if we can find one.
For things like system updates and taking care of the hardware - we do it manually today. The fleet is still small, so it is manageable but in the future we would like to consider a vendor, if we can find one.
Thanks!
Hey,
I worked on a really perf sensitive system and for perf tests we would run the last x commits each time to get rid of the busy vm syndrome.
It meant that the margin of error could be much less.
You might want to consider it as a mid way step between vm’s and scheduling on laptops (those poor laptop batteries!)
Ed
I worked on a really perf sensitive system and for perf tests we would run the last x commits each time to get rid of the busy vm syndrome.
It meant that the margin of error could be much less.
You might want to consider it as a mid way step between vm’s and scheduling on laptops (those poor laptop batteries!)
Ed
That's a good way to address the noise on VMs! We do something different but in a similar spirit: when we compare to the main branch, we calculate the baseline based on 1-2 weeks worth of historical data on main (we identify the latest step change with a simple linear regression). This way we approximate the baseline based on ~100 data points which also helps to address the variance.
Of course re-running the code from main and the PR on the same VM side by side would be the best, and it would cost a lot more money (especially once you factor in GPUs). We considered it but opted to the strategy I outlined above, it's mainly a trade-off between accuracy vs costs
Of course re-running the code from main and the PR on the same VM side by side would be the best, and it would cost a lot more money (especially once you factor in GPUs). We considered it but opted to the strategy I outlined above, it's mainly a trade-off between accuracy vs costs
At Framer (framer.com) we actually had a bit lower variance (I think it was closer to 15%) after spending three months of solid engineering, ending up with a dedicated Mac Mini running Chrome.
Apart from the admin overhead (things got stuck on OS updates) we ended up abandoning the setup because the variance was too big to get anything useful out of running tests for every pr.
The most reliable way for us to monitor performance today is to count slow frames (>16ms) across all actual users and divide them by total time spent in app. It’s a rough proxy, but pretty accurate at showing us when we mess up.
Apart from the admin overhead (things got stuck on OS updates) we ended up abandoning the setup because the variance was too big to get anything useful out of running tests for every pr.
The most reliable way for us to monitor performance today is to count slow frames (>16ms) across all actual users and divide them by total time spent in app. It’s a rough proxy, but pretty accurate at showing us when we mess up.
This is definitely an interesting challenge!
Often CPU steals are visible in cloud environments. This could be useful for finding some noisy neighbor behaviors, and deciding to either adjusting expectations or rerun.
But things like IO, GPU or memory contestation also could be responsible. There are some fancy new-ish extensions for controlling memory throughput. Intel has Memory Bandwidth Allocation controls in their Resource Director Technology, which is a suite of capabilities all designed for observing & managing cross system resources. There's also controls available for setting up cache usage/allocation.
Often CPU steals are visible in cloud environments. This could be useful for finding some noisy neighbor behaviors, and deciding to either adjusting expectations or rerun.
But things like IO, GPU or memory contestation also could be responsible. There are some fancy new-ish extensions for controlling memory throughput. Intel has Memory Bandwidth Allocation controls in their Resource Director Technology, which is a suite of capabilities all designed for observing & managing cross system resources. There's also controls available for setting up cache usage/allocation.
Yeah, I think I/O has bit us before. Running on AWS, you may randomly get a huge spike in I/O latency (maybe Amazon adjusted the physical hardware, drive failed, etc) and have no idea why.
Is Figma fast? I see huge lag on loading files. Sometimes images don't load for 10+ seconds after the file opens. Based in EU we often don't get thought about in testing.
The answer to "is x fast?" is always "compared to what?"
Having been a long-time user of Figma's somewhat-trailing (at this point) competitor, Sketch, speed is surprisingly one of Figma's most immediately-apparent advantages despite being web-based rather than MacOS-native.
At a previous job, we had a Sketch file that contained more or less an entire B2B app, and at hundreds of megabytes, it took tens of seconds to load (not asynchronously, either, blocking the UI until the whole thing was in memory). A similar everything-file at a more recent job where we used Figma was like night and day: something like three seconds until the file was usable, and perhaps a few more seconds for any big images to load.
Then there's Figma's upstart competitor, Penpot. In my initial explorations, it felt about as responsive as Figma, but when I loaded one of their tutorial files – not even a mega-B2B-app file – everything slowed considerably. The load time wasn't bad, but the frame rate for simply scrolling around the artboards dropped like a rock. While I'm bullish on Penpot, they have a long optimization road ahead of them.
Having been a long-time user of Figma's somewhat-trailing (at this point) competitor, Sketch, speed is surprisingly one of Figma's most immediately-apparent advantages despite being web-based rather than MacOS-native.
At a previous job, we had a Sketch file that contained more or less an entire B2B app, and at hundreds of megabytes, it took tens of seconds to load (not asynchronously, either, blocking the UI until the whole thing was in memory). A similar everything-file at a more recent job where we used Figma was like night and day: something like three seconds until the file was usable, and perhaps a few more seconds for any big images to load.
Then there's Figma's upstart competitor, Penpot. In my initial explorations, it felt about as responsive as Figma, but when I loaded one of their tutorial files – not even a mega-B2B-app file – everything slowed considerably. The load time wasn't bad, but the frame rate for simply scrolling around the artboards dropped like a rock. While I'm bullish on Penpot, they have a long optimization road ahead of them.
The most telling point to me is when people outside of product, design, or engineering use figma for the first time.
In my experience they dive in and don't think about it, it's just natural to use. Not to say the UX is ideal, because imho it sucks hard, but no one complains about *having to use a webapp when they open figma.
In my experience they dive in and don't think about it, it's just natural to use. Not to say the UX is ideal, because imho it sucks hard, but no one complains about *having to use a webapp when they open figma.
Last time I checked, Penpot was creating/destroying actual SVG elements in the dom. I get the sentiment of wanting to use open technology, but for the average user Figma's "copy as svg" is probably open enough. And switching to canvas based rendering would probably improve performance a lot.
Imagining a future where Penpot gets Blender-level resources and implements an SVG VM in WASM that renders to WebGL.
Sounds like y'all might have a lot of large images or raster files?
That I have files with enormous thousands of components and Figma doesn't miss a beat. If you're able to get vector versions of those, then the speed shouldn't be an issue. Obviously if there are a lot of photos, that might be tough.
That I have files with enormous thousands of components and Figma doesn't miss a beat. If you're able to get vector versions of those, then the speed shouldn't be an issue. Obviously if there are a lot of photos, that might be tough.
I want to write only: https://penpot.app/
Figma is anything but fast. Whenever I need to open a file it takes a minute to load on my half a gigabit connection. It's strange how much people are willing to put up with slow software nowadays.
How fast is it after opening the file? I’d imagine there are trade-offs being made where some aspect of performance are sacrificed to improve others but I haven’t used Figma (sadly, it looks really nice)
It does pretty well after the initial loading. But the loading is excruciating for me because I need to open different files again and again throughout the day, and it takes the same amount of time to load every file every time.
(author of the article)
I want to acknowledge that the load-times for Figma go up linearly with the complexity of your design file + its dependencies. It is always painful when users rightfully complain about giant design files taking a while to load and fully render.
The team is working on changing that so hopefully your experience gets better over time.
This is not my area of expertise, so I am not in the position to promise anything on this forum but I just want to say that the testing framework described in the article is also used to continuously test and measure the file load/parsing time as folks are working towards algorithmic improvements.
I want to acknowledge that the load-times for Figma go up linearly with the complexity of your design file + its dependencies. It is always painful when users rightfully complain about giant design files taking a while to load and fully render.
The team is working on changing that so hopefully your experience gets better over time.
This is not my area of expertise, so I am not in the position to promise anything on this forum but I just want to say that the testing framework described in the article is also used to continuously test and measure the file load/parsing time as folks are working towards algorithmic improvements.
Like many other commenters, I found this article surprising. Figma is anything but fast for me. Do you performance-test your software on any Linux distributions?
Figjam on Firefox on Ubuntu is painfully slow and laggy. On a 32-core Ryzen machine, drawing lines on an empty file visibly lags. Doing the same thing in Excalidraw, on the other hand, is extremely responsive.
Figjam on Firefox on Ubuntu is painfully slow and laggy. On a 32-core Ryzen machine, drawing lines on an empty file visibly lags. Doing the same thing in Excalidraw, on the other hand, is extremely responsive.
Hey there
we test on macs, windows and linux laptops, it is very surprising that drawing 1 rectangle is painfully slow.
Sometimes it happens when your browser does not enable hardware acceleration or when your Linux distro does not know how to switch to the discrete GPU.
We won't be able to tell without getting more of your hw specs and debug information, feel free to reach out to the Figma support or email me at [email protected] - this is exactly the type of issues that elud us when looking at prod metrics in aggregation.
we test on macs, windows and linux laptops, it is very surprising that drawing 1 rectangle is painfully slow.
Sometimes it happens when your browser does not enable hardware acceleration or when your Linux distro does not know how to switch to the discrete GPU.
We won't be able to tell without getting more of your hw specs and debug information, feel free to reach out to the Figma support or email me at [email protected] - this is exactly the type of issues that elud us when looking at prod metrics in aggregation.
To be fair, Excalidraw and Figma are vasty different in terms of scope.
Is your GPU doing any work? What are the results from here? https://pmndrs.github.io/detect-gpu/
Is your GPU doing any work? What are the results from here? https://pmndrs.github.io/detect-gpu/
I have the displeasure of using Figma at my job. I have a very low opinion of anything that locks up my browser for multiple seconds (Chrome or Safari) whenever I open it in a tab.
Then it takes a few seconds to load the file, which I don’t care much about.
But locking my entire browser is inexcusable.
It’s nice they’re working on performance once you get going, but launch performance is abysmal for me (x86-64 Mac).
Then it takes a few seconds to load the file, which I don’t care much about.
But locking my entire browser is inexcusable.
It’s nice they’re working on performance once you get going, but launch performance is abysmal for me (x86-64 Mac).
I’ve seen this happen, but I don’t understand why that is possible. Chrome tabs are separate process, how can one tab freeze the whole browser even when running the worst code in existence?
> I’ve seen this happen, but I don’t understand why that is possible. Chrome tabs are separate process, how can one tab freeze the whole browser even when running the worst code in existence?
Because if anything takes up 100% of CPU, other things starts being unresponsive as there is not enough CPU to go around. Happens easily when dealing with concurrency and parallism, which I'm guessing Figma happily uses.
Because if anything takes up 100% of CPU, other things starts being unresponsive as there is not enough CPU to go around. Happens easily when dealing with concurrency and parallism, which I'm guessing Figma happily uses.
Chrome starts a process per tab. On a modern operating system, one process should not be able to starve another equally-privileged process of CPU, so it sounds like there is more going on here.
This is not the case. Maybe people have already forgotten what using computers was like when everyone had only 1 core, but having a few desktop apps pegging their share of cpu doesn't hurt interactivity much even on single-core computers.
All the other apps are fine. It’s whatever browser is trying to load Figma that freezes.
I’ve had a mouse cursor move slowly when doing some tasks in Chrome. And all other apps barely reacting. Still a mystery to me. I hope that was not a sign of some backdoor being installed through a Chrome vulnerability.
This should not be the case even on a single CPU machines that run interactive jobs. This is a shoddy process scheduling work.
Figma is beyond chrome, it's a quantum app: it's both in a state that will lock up my pc while everyone on zoom waits for the screen to load and a journey in following designer's instructions: "no a bit more left, no actually right, ok go down, no up, ok back go the left a bit, ok here it is!", same vibe as rally racing lol
For #1: don’t use it in chrome, download the app (it seems like it takes advantage of the wrapper pretty well); for #2, just click on the designer’s name in the top corner to zoom your screen to theirs and let them drive for a second!
Sounds like either processes are waiting on each other, or the OS sucks.
Requiring figma at a job should be a human rights violation :). I'm off the grid and whenever I use figma it drains my batteries with a high CPU load. I have to be careful to open it during the dead winter, if I leave it open I could drain my entire 5kw setup. If I throttle my CPU, it's totally unusable. Hopefully I can get a more efficent setup (currently an old 2400GE minipc). Usually I take a screen snapshot because this has happened.
When I read stuff like this I can never tell if it is someone making a joke or just extreme complaining.
The computer you mentioned comes with a 65 watt AC/DC converter which should last 77 hours minimum on a 5kw battery.
Then there is the nonsense about blaming a web page for not having enough power after choosing to do a tech job while living off a battery.
The computer you mentioned comes with a 65 watt AC/DC converter which should last 77 hours minimum on a 5kw battery.
Then there is the nonsense about blaming a web page for not having enough power after choosing to do a tech job while living off a battery.
didn't want to hijack the thread about my personal setup, but that's almost about right amount of power usage I aim at entirely, about 120-200 watts per hour: but there are other things plugged in besides my desktop like ... my entire house. Lights, freezer, monitor, radio, DC adapters, starlink. Another 30-50w is just insane to run Figma. My freezer chest uses less and at least I can grab a steak.
You're doing it wrong. What you need is a good exhaust on that mini pc; then you can use Figma as an inefficient heater during that dead winter.
You should get a mac laptop, you can run figma all day without even needing to plug in the laptop to charge.
I hope this is satire. The glaring problem with software performance nowadays is corporations having convinced consumers to work around their slow and terrible software by throwing more hardware at it and buying multi-thousand dollar computers.
Software companies must be a non-trivial driver of e-waste.
I always use it as a separate app (I guess it's Electron?) and it's generally fast. At least not feeling slower than Photoshop and Illustrator, while it's not a very high bar.
I used Figma recently on a decent laptop. I used it both in-browser and within its desktop app. it was anything but fast. lightning speed compared to Android studio, but slow compared to anything else
Nice post. Figma's engineering blog looks great; right up there with Airbnb's and Etsy's which I also enjoy.
Airbnb is a great example of a terrible experience that just keeps getting worse. It makes my M1 Mac, my 32 core workstation and my top of the line android device chug.
The shininess of the engineering blog and the actual product seem to be completely disconnected. All the major players (Airbnb, Instagram, Facebook, Twitter) go on about all these often genuinely impressive perf optimizations, but if you actually try the product they're borderline unusable. It's pretty clear that the blogging is just a clout chasing exercise, but the cognitive dissonance is still palpable.
I think Airbnb is the worst offender by far though. Instagram, Facebook and Twitter (just using your examples) operate very dynamic applications at a global scale. AirBnB is a crud app with almost no dynamic content other than the booking system. According to the first site I saw online, they process 6 bookings per second, which I could handle on literally anything with an internet connection. Of all of them, its the one I understand the least.
I thought this sounded way too low but the most generous figure I can find is 12 per second in 2022. What the hell? I thought it would be more. Should I have thought that? I guess not.
6 bookings per second at $200 per booking is $103M processed per day.
Each booking likely represents dozens to hundreds of requests. Then, for every visit resulting in a booking there’s probably hundreds of non-booking visits.
Each booking likely represents dozens to hundreds of requests. Then, for every visit resulting in a booking there’s probably hundreds of non-booking visits.
If your CRUD app's booking endpoint internally fans out to 100s of requests, you're doing something extremely wrong and/or you've dug yourself into microservice hell.
> 6 bookings per second at $200 per booking is $103M processed per day.
I don't doubt that they don't prcess a lot of money - that's besides the point.
They're a cookie cutter CRUD app (that happens to process a lot of money) that takes _hundreds_ of requests and 12 seconds to load on a 32 core workstation with a gigabit fibre internet connection. They have no business writing a blog on performance engineering.
I don't doubt that they don't prcess a lot of money - that's besides the point.
They're a cookie cutter CRUD app (that happens to process a lot of money) that takes _hundreds_ of requests and 12 seconds to load on a 32 core workstation with a gigabit fibre internet connection. They have no business writing a blog on performance engineering.
From experience at Facebook: there are extremely good people working on performance and making heroic optimizations. The blog content is real. However, these are necessary precisely because the politics and culture of the organization make it impossible to avoid bloat that accumulates faster than the small minority of perf-conscious folks can improve things.
No RSS feed though afaict :(
No, but there is atom (https://www.figma.com/blog/feed/atom.xml) and jsonfeed (https://www.figma.com/blog/feed/feed.json)
We didn't have a problem with Figma's technology, but we did have problems with their UI. For example, it confused "teams" and "projects," making managing your work and granting access to people a baffling pain in the ass. It took a week of E-mailing people for me to gain the necessary access to my own team's files when we adopted Figma, most likely because of the inept segregation and presentation of these entities.
Has there been any UI overhaul since acquisition?
Has there been any UI overhaul since acquisition?
> We recently developed stress test scenarios for rendering complex scenes—like thousands of layers edited by 50 multiplayer users—and took a very deep dive into CPU and GPU profiles.
I don't really know what any of this means. You're running a single-thread graphics API (OpenGL) in a browser (does WASM support background threads?). On any modern PC, that's gonna look like 1 CPU thread doing all the work and the GPU idling 80% of the time waiting for something to happen.
I don't really know what any of this means. You're running a single-thread graphics API (OpenGL) in a browser (does WASM support background threads?). On any modern PC, that's gonna look like 1 CPU thread doing all the work and the GPU idling 80% of the time waiting for something to happen.
> does WASM support background threads?
yes
Figma is able to use more than 1 CPU core and also claim a lot of your GPUs capabilities.
Don't believe me? Open Figma, load a large file and watch it use multiple CPU cores using htop. Driving the GPU is not all the application does. It also has to work with a largish model and abstract syntax tree and do lots of complex things with that before it goes anywhere near the GPU and opengl. Driving that probably happens on the main thread.
On a modern M1, the app is fast and responsive. It only uses a few worker threads (less than the number of CPU cores) and the GPU is fast enough to keep framerates high if you do things like zooming and panning the view. It's the older and slower laptops that are going to be more challenging.
yes
Figma is able to use more than 1 CPU core and also claim a lot of your GPUs capabilities.
Don't believe me? Open Figma, load a large file and watch it use multiple CPU cores using htop. Driving the GPU is not all the application does. It also has to work with a largish model and abstract syntax tree and do lots of complex things with that before it goes anywhere near the GPU and opengl. Driving that probably happens on the main thread.
On a modern M1, the app is fast and responsive. It only uses a few worker threads (less than the number of CPU cores) and the GPU is fast enough to keep framerates high if you do things like zooming and panning the view. It's the older and slower laptops that are going to be more challenging.
[deleted]
Occasionally I wonder what could have happened to front-end web application development over the past few years if Figma had open-sourced their WebGL-based GUI library.
We've had ~15 years of focus on the DOM with the progression of jQuery to Backbone to Vue, and many other libraries. At least what I've heard of the Figma approach almost sounds like the Adobe Flash/Flex runtime.
That might only make sense for applications with high levels of information density and snappy reactivity requirements like Figma or Google Docs or a web map -- not for content-focused websites. Still, it's interesting to wonder if our arguments would be more interesting these days if we were discussing those types of approaches, rather than just fighting about React vs. Svelte, or this JavaScript module loader vs. that one...
We've had ~15 years of focus on the DOM with the progression of jQuery to Backbone to Vue, and many other libraries. At least what I've heard of the Figma approach almost sounds like the Adobe Flash/Flex runtime.
That might only make sense for applications with high levels of information density and snappy reactivity requirements like Figma or Google Docs or a web map -- not for content-focused websites. Still, it's interesting to wonder if our arguments would be more interesting these days if we were discussing those types of approaches, rather than just fighting about React vs. Svelte, or this JavaScript module loader vs. that one...
It would not.
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
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
I do some graphics work and I wouldnt say that there is a world of difference between the capabilities of Illustrator and Figma. Photoshop is obviously a completely different tool. Very textural digital painting of the kind that photoshop excells at would be pretty tricky in a browser. (Theres a webversion of Heavypaint now, but thats vector-based of course.
Check out Photopea, it has a ton of features and is fairly performant in the browser. It also seemingly copies the UI of Photoshop but impressive nonetheless.
Figma definitely had a killer advantage with Evan Wallace around. He might be known now for esbuild but he is a WebGL demon of epic proportion.
Woah I had never connected the dots - I had used https://github.com/evanw/glfx.js for a realtime photo editor and then wrote https://github.com/inssein/jsfx to render the same without WebGL for printing.
It's worth noting that a lot of Figma's UI outside of the canvas is React (panels, toolbars, menus, etc).
You'd likely get something like Flutter. It's actually gotten quite good these days with their web version, 300 ms to load a counter app, and 150 ms with WASM enabled.
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.
https://news.ycombinator.com/item?id=34612696
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.
https://news.ycombinator.com/item?id=34612696
There are multiple ui frameworks now starting to target wasm. I'm keeping an eye on Jetbrain's multi platform compose, which is extending Google's Jetpack Compose for Android to IOS (alpha releas available with 1.5 released a few days ago), Desktop, and Wasm (experimental support available but a work in progress).
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.
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.
Couldn’t agree more. Would love more discussion of stuff like this in front end
Could someone compile Skia to WASM and add a layer for some UI niceties like flexbox? I wonder what the layer they have consists of.
Yes, which is what Flutter basically does.
Figma was considered ... good?
Every time I have used it, it feels incredibly laggy with a crapton of useless animations.
Maybe it's better on Windows?
Every time I have used it, it feels incredibly laggy with a crapton of useless animations.
Maybe it's better on Windows?
PM over here at Figma - would love to know where you're experiencing lag / where you're seeing useless animations.
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 [email protected].
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.
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 [email protected].
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.
Chrome on Ubuntu using your "Diagram Basics" template.
Dragging any object is laggy--particularly so over the slightly pinkish/purplish background area.
Dragging any object is laggy--particularly so over the slightly pinkish/purplish background area.
Not for me... well, I'm on Windows.
It is currently the best tool for me, as a non designer, to smash together (design) icons and export in my choice of format.
It is currently the best tool for me, as a non designer, to smash together (design) icons and export in my choice of format.
I'm mostly on Windows, if someone sends me a Figma link I open it in a different browser because half the time it locks up for a few minutes then crashes the whole thing.
Would prefer to be sent a PDF, and you won't often catch me saying that.
Would prefer to be sent a PDF, and you won't often catch me saying that.
I use it daily on Windows and I have to say it seems pretty fast. Never noticed any lagging or unnecessary animations.
For everything outside the canvas (sidebars, toolbars, etc) figma is a react app.
[deleted]
[deleted]
https://github.com/evanw