It's an incredible success story, and the engineering they did upfront (primarily led by co-founder Evan Wallace) that set the stage for their success is the stuff of legends. https://madebyevan.com/figma/ has links to numerous blog posts breaking it down, but here are some choice quotes:
> [Evan] developed the hybrid C++/JavaScript architecture for Figma's editor that made it possible to build a best-in-class design tool in the browser. The document representation and canvas area is in C++ while the UI around the canvas is in JavaScript (the team eventually settled on TypeScript + React for this). This let us heavily optimize the document representation to reduce memory usage and improve editing speed while still using modern UI technologies for fast iteration on our UI. C++ development was done using Xcode (not in the browser) to provide a better debugging environment.
> Even though the contents of Figma documents are similar to what HTML can display, Figma actually does all of its own document rendering for cross-browser consistency and performance. Figma uses WebGL for rendering which bypasses most of the browser's HTML rendering pipeline and lets the app work closely with the graphics card. The rendering engine handles curve rendering, images, blurs, masking, blending, and opacity groups, and optimizes for high visual fidelity.
> [Evan] developed Figma's multiplayer syncing protocol, worked on the initial version of the multiplayer live collaboration service (a kind of specialized real-time database), and added multiplayer syncing support to Figma's existing editing application. The initial version was written in TypeScript but [he] later ported it to Rust for improved performance and stability.
It's a great reminder that it's not premature optimization if your UI's fluidity is your distinctive feature and your calling card! And the business acumen to turn this into such a wildly successful product in the context of competitors with kitchen-sink feature lists can't be understated, either. I have an incredible amount of respect for this team, and they should inspire all of us to tackle ambitious projects.
I was one of their first Enterprise customers way back in 2017’ish-give-or-take.
The brilliance of the system he built was that it allowed for real time collaboration. Which was god send from the Sketch -> Zeplin -> Invision -> Avocode (version management) ‘stack’ that lost Enterprise design orgs were using.
Which was already a large leap from what Adobe was expecting us to do with Photoshop/Illustrator (after they depreciated Fireworks).
Figma made handoff much easier. Made version control dead simple. Made my life as a UX leader much much better. I remembered talking to a few now-Gigantic companies back then and we all plotted the move together
It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering. It’s just that the benefits far outweighed the small drop in snappiness.
And for anyone who’s going to say “Sketch was Mac only that’s why it failed!” I assure you that had nothing to do with it. For the same reasons an entire generation of UX/UI designers stopped using Axure. But we would need to start talking about Invision 7 and Invision Studio if you wanted to get into the nitty gritty.
> And for anyone who’s going to say “Sketch was Mac only that’s why it failed!”
Why would anyone say that? Sketch is still alive and (presumably) well. Apple themselves continue to officially release design files for Sketch with every OS release. They share more resources for Sketch than any other app, including Figma and Photoshop.
I’ve been seeing that word used a lot in this context, so just wanted to point out (I’d appreciate if someone did the same for me) that what you mean is “deprecated” (no “i”), as depreciating is a different thing.
> It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering.
Writing this from the perspective of someone who used to spend all day every day in Photoshop/Sketch/Figma for decades. This markedly contradicts my recollection of the state of Sketch at the time Figma was in its first public beta. Sketch's performance was abhorrent and it was constantly crashing while working with libraries. I was very skeptical about web-technology based tool in terms of performance, but Figma blew me away. It was FAST.
> It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering. It’s just that the benefits far outweighed the small drop in snappiness.
yep, even though i personally prefer sketch, if i was running a company i'd most likely go with figma as well because of the collaborative capabilities; its just a huge productivity boost for collaborative teams
After the Adobe/Figma deal fell through a few years ago I thought they might breath new life into XD, it's a good program that integrates with your Creative Cloud libraries. No idea why they've put it on ice, especially without Figma.
As a former figma engineer, let me be the first to say that Evan Wallace is, in fact, a legend. A true 100x-er. There's still parts of the codebase basically no one at Figma really understands that Evan wrote back in the day.
One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
Font rendering is indeed complex, but the anecdote seems to be misleading readers into thinking Evan wrote obscure code.
I worked extensively in the parts of the Figma where Evan wrote a lot of foundational code, and have also worked directly with him on building the plugin API.
One of Evan's strong points as a CTO is that he was very pragmatic and that was reflected in his code. Things that could be simple were simple, things that needed complexity did not shy away from it.
While all codebases have early decisions that later get changed, I'd say that largely speaking, Figma's editor codebase was built upon foundations that stood the test of time. This includes choices such as the APIs used to build product code, interact with multiplayer, the balance between using OOP v.s. more functional or JS-like patterns, the balance between writing code in C++/WASM v.s. JS, etc. Many of these choices can be credited to Evan directly or his influence.
Subsequent engineers that joined were able to build upon the product without causing a spiraling mess of complexity thanks to those good decisions made early on. In my opinion, this is why Figma was able to ship complex new features without being bogged down by exploding tech debt, and a major contributing factor to the business's success as a whole.
I don’t know anything about shaders and this is not personal against Evan, but if someone wrotes code that nobody understands, isn’t it bad thing and not good thing? I thought similarly (admired) many years ago, that those people are wizards and that is cool, but the older I get, less I think so. You often can write the same thing so that it is also easier for others to understand. In most cases, when we talk about compiled languages, compiler optimises it anyway, if you use some extra variables and so on.
> which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
I don’t mean this to throw shade, but isn’t the whole point of writing code that someone else can understand it? I worked with some crazy smart people when I was in academia, and when one of them left it was not worth trying to maintain what they left behind because it was so often inscrutable.
The way you’re telling it, that feels like a really weird thing to praise. “There are majorly important parts of the code base with a bus factor of one” isn’t something to celebrate or be proud of.
I understand where you're coming from and the admiration for someone for whom no problem is seemingly impossible.
I wouldn't glorify "brilliant code" that much though because code should be made to be changed. If it isn't, it's a fragility trait, not a positive trait. Code that no one knows how to change is opportunity lost.
I do understand that it may be hard to create stuff for others when you're alone and going very fast but I don't think praising it is the right idea.
That it works is testimony to the intelligence put towards the code. That no one else can grep it tells me it was solved in a manner which was suboptimal.
I cannot believe Figma hired engineers who could not follow along already-tread footsteps. That’s a nonsensical assertion. Novel code may be inscrutable but the problem-solving and techniques should have been clear and repeatable by those who follow, even if they require adaptation.
Evan Wallace basically said screw it, I'm writing a custom WebGL renderer and multiplayer protocol, when everyone else was slapping together existing libraries.
Most of us would have built a janky Electron app and called it a day. Instead they went nuclear on performance because that WAS their product differentiation.
Hasn't he all but washed his hands of Figma? I have a hard time being interested in something that has such a painful freemium tier, tries to merge with Adobe, and trademarked "Dev Mode".
Maybe the real webpage also needs a better stack and designers need to worry less about things they can't control and think more about usability and simplicity.
I work on a large web based application, with designers, who use Figma. It's just too easy to lose the plot and come up with things that don't work well. Not because of Figma. Something about the balance between the software stack(s), the domain, the focus of designers today, the front end engineering, and product management is broken. It's interesting that Figma did (IMO) a great job at addressing the stack so they can build a product that does what they want it and then is used by so many to build products that don't always do what their customers want. Asking Figma to use the wrong stack for their product (which is what I'm reading between the lines) is not really the right answer...
I’ve been thinking about a box-first approach to design tooling. The overall layout workflow would consist only of adding boxes (block-level elements) to a blank web page, or inside other boxes. Boxes could also contain other elements like inputs, buttons, images, etc.
True... this was a conscious trade-off at Figma since it needs to support designs for web, iOS, Android, etc. That unfortunately means it doesn't map 1:1 to any of them.
Don't forget that Evan is the author of esbuild[1], which started a wave, eventually resulted in 10x performance improvements in frontend tooling, and even recent TypeScript rewrite to go[2].
While I like the product, the net income would worry me if I were to participate in the IPO. $280M net income in 2023 after they received $1B for the failed merger and $730M net loss because of RSU/Stock Awards in 2024 is not great when the total revenue for the company was $500M in 2023 and $750M in 2024.
> Our vision for the future of design tools is one where both the tool and the content are easily available to anyone, anywhere
> The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
> We fully control memory layout and can use compact 32-bit floats or even bytes when appropriate instead of JavaScript’s 64-bit doubles...The generated code is completely in control of allocation, which makes it much easier to hit 60fps by avoiding GC pauses. All C++ objects are just reserved ranges in a pre-allocated typed array so the JavaScript GC is never involved.
> One big issue for us was that certain browser configurations couldn’t allocate large ranges of continuous address space for the huge typed array that contains the entire emscripten memory space. The worst case was 32-bit Chrome on Windows which sometimes couldn’t even allocate a 256mb typed array because ASLR was fragmenting the address space. This has since been fixed.
A great example of making a single bold architectural decision (building a design tool on the web instead of as an app) in service of a vision (prioritize live collaboration), and then thoughtfully resolving all of the performance tradeoffs that stem from this route.
Don't forget the incredible lock in Figma has in the design space.
Figma just has to jack up the price in order to appease Wall Street quarterly.
Business wise it's got a great margin, but the avaricious nature of Wall St. will force them to enshittify the entire product, the engineering doesn't matter unless Wall St. is satisfied.
I’m in a monthly meetup with designers (not randos, these are typically people who are known in the industry), and half the time is spent shitting on Figma. It’s not necessarily the quality of their design product, it’s the business model and their general focus as a company.
There are several things designers need that Figma has dragged their feet on for years, and when they do release them, they’re usually behind the enterprise paywall. Or they don’t release them at all, instead opting to build some horizontal product like Slides because their investors want a bigger TAM.
Figma has the power of the network effect at present, but you can only charge people to use variables for so long before they look for an alternative.
RE: the webgl being used to render a site thing - I'd always thought this should be done so that we can use a nice, clean grid co-ord system same as iOS/Android, etc.
None of this "designed for newspaper print" style layout. Yes, I know flexbox is very good. But it's still a hack (imo).
"Immediately following the completion of
this offering, and assuming no exercise of the underwriters’
over-allotment option, Dylan Field, our Chair of our Board of
Directors, Chief Executive Officer, and President will hold or
have the ability to control approximately % of the
voting power of our outstanding capital stock, including
% of the voting power pursuant to the Wallace Proxy. As a result, following this offering, Mr. Field will have the ability to control the outcome of matters submitted to our
stockholders for approval, including the election of our
directors and the approval of any change of control
transaction."
That generally makes me more inclined to invest as I find that the biggest problem with a lot of public companies is they manage to Wall Street which means putting the short term over the long term, and those are often at odds with each other.
There are a whole lot of companies that are run to benefit their management and not their shareholders. At best, they might be making no money but keeping a bunch of people in work.
There's a good reason public shareholders historically demanded accountability - maybe it's fine for now, but all it takes is some management that you can't kick out, paying themselves extortionate salaries and driving the company into the ground at the same time to recognise the problems with "owning" a company you have no right to actually control (via replacing management and so on)
Short term focus is not a control issue it's a fact of life with public ownership. They still need to manage to market expectations or they will be punished, now one person can do whatever it takes to stay focused on only the next 2 quarters.
> The table above does not reflect our renewed cloud hosting agreement with a third-party provider, entered into on May 31, 2025. Under the terms of the non-cancellable agreement, we committed to purchase a minimum of $545.0 million in cloud hosting services over the next five years. This renewed agreement replaces a previous agreement with the provider.
$300k/DAY AWS bill. I wonder what the "non-cancellable" savings is.
why is it so high? all of their high performance stuff is on device wasm, so all of that just to host their website and like collab features or some such?
There's plenty of server-side components to Figma that are substantially more complex and expensive than that of the typical website.
Multiplayer means that every file that are user loads is loaded onto a compute server and retained in-memory on that server, processing every mutation to the document. Figma documents can get quite large -- they can contain the design system of an entire organization, dozens of variations of a product feature, etc. This means the server cost scales per active session at a given time, a higher "number" than active requests.
In addition to multiplayer, Figma attempts to keep most other parts of the application real-time. If another user adds a file to a project, you will see it without refreshing the page. That's a simple example, but certain types of queries/mutation can get much more complex.
Figma is an enterprise app, and the data models needed to support complex use cases (permissions, etc) means that DB load is a real challenge.
While the DAU count of Figma might not be as high as other consumer apps, the amount of time those users spend in Figma is often substantially higher.
Those are some of the things that contribute to a high bill. While Figma is most known for the frontend editor, the infra work is plenty interesting too.
Not sure why you are being downvoted for asking a question. One POV is that Figma’s technology can afford to be run expensively. Their on device ie in browser stuff is running on very expensive computers too. It isn’t necessarily optimal. We don’t know.
Congratulations to the Figma team! Well earned. It was such an exciting product when it hit the scene. It became the standard so fast, and it was easy to see why. When there were talks of them being bought for $20 billion I thought it was a great deal for Adobe - and that was before seeing these impressive financials.
I will admit I have waned enthusiasm a on Figma over the past couple of years. I find the UI churn confusing. The new features, i.e. dev mode and variables, feel out of place. I find the plugin ecosystem cumbersome. Doing simple things has become complex. I'm putting out real "who moved my cheese?" energy here I know. I suppose I'm wondering if others feel the same.
Others do, and an IPO and the resultant financial pressure means we’ll be looking for a different platform to migrate to. Products simply never get better at this point from a customer’s perspective.
I actually have the opposite problem with Figma. It is way too basic and simple, targeting every kind of design and the average designer skill level.
I work in complex SAAS product design. Basic things I can do in CSS I can't do in Figma. Things like a table? Yeah it is entirely faked and awful in Figma. Don't even get me started on anything more complicated than flex rows and columns.
Half the debate over designer/dev handoff in the industry right now is simply because of Figma's limitations and the refusal of designers and front-end devs alike to learn HTML and CSS.
We need a Blender-like tool for web and app product design. Highly capable and advanced, you aren't expected to know all of it, and it can do anything you want it to.
I need a tool that is more than just a fancy rectangle drawer.
I agree with many of your statements but draw the opposite conclusion.
HTML and CSS are expressive, have a vast selection of libraries and tools, and can actually result in shippable code. Designers and front-end devs should learn and use it.
But I don't see the point in creating a design tool unless it's meaningfully simpler than HTML/CSS. I reach for Figma when I need to quickly mock up a dozen iterations using our design system and fancy rectangles. It's fast enough that I can make mockups in realtime during discussions with developers and subject matter experts. But if I'm actually going to take the time to set constraints to make things flex properly or make a real table then why not use HTML and CSS directly?
There are also Adobe Illustrator and Photoshop, both of which were used for UI design until Sketch/Figma appeared. Both harder to learn and more expensive.
The problem then was that the designs could be too cumbersome to implement (and also that you couldn't share files with developers as easily, but Sketch has the same problem). You can really do just about anything in PS/AI, whereas with Figma and Sketch it's almost like they limit you to what an average developer can implement with CSS.
That being said, we're in the age where you can do pretty much anything with CSS, and I totally agree with you that Figma's controls are very basic (especially for typography, there's just not enough options).
As a dev who only really uses the read-only version of Figma for the most part, I really like what they do. I can't speak for designers but having the Figma diagrams match the libraries and the design system we use is very very nice. no guessing about colors, typography, spacing. I can just copy and paste into my CSS for front end work. The interface is smooth and fast for us non-design focused devs
What about variables that don't use pixel units? Often values appear as hardcoded in dev-mode when they are actually meant to be a % unit or something else Figma doesn't support because Figma doesn't actually use CSS for rendering.
When my devs just copy whats in Figma dev-mode they get so much stuff wrong.
as someone whos worked in a bad figma before, dont forget to give credit to your designers for setting up the design system that well that you can copy and paste like that. there are many designers who do not give two shits about how it looks in the dev handoff - figma tries but often fails to put them on guardrails to keep consistency to THEIR OWN designs lol
I'm a little surprised by this comment because both dev mode and variables are the main ways I use Figma. Our design team creates the design and then the Devs use dev mode to implement what they designed. Dev mode has been great for our team!
FY Ended December 31, in millions except percentage
| 2023 | 2024 | YoY
---------------------------|------|------|------
research and development | $165 | $751 | 356%
sales and marketing | $201 | $472 | 134%
general and administrative | $168 | $316 | 88%
And most of that increase came from a one-time charge from allowing employees to sell their RSUs. While not a cash cost for Figma, it was booked as an expense and allocated as follows:
| 2024
---------------------------|------
cost of revenue | $25
research and development | $463
sales and marketing | $187
general and administrative | $184
total | $858
If you subtract the one-time charge, you get:
| 2023 | 2024 (adj.) | YoY
---------------------------|------|-------------|------
research and development | $165 | $288 | 75%
sales and marketing | $201 | $285 | 42%
general and administrative | $168 | $132 | (21)%
total | $534 | $705 | 32%
Initially Tepid about AI. Didn’t want to upset their base like Adobe was (seemingly) doing. Look at that year’s Figcon for evidence. The keynote led with the new Figma, front loaded anything. He quickly moved past it and spent 90% of the rest of the time on non-consequential features.
Then that AI feature they highlighted was pulled off production because it was cloning iOS.
The AI heavy product dump we just got are lessons from that time.
The missing piece that this perspective leaves out is that Figma's success is at least partially due to timing of the rise of flat design. I wrote about this in my analysis of software transitions, here's the relevant section (https://blog.robenkleene.com/2023/06/19/software-transitions...):
> In the section on Photoshop to Sketch, we discussed an underappreciated factor in Sketch’s, and by extension, Figma’s, success: That flat design shifted the category of design software from professional creative software to something more akin to an office suite app (presentation software, like Google Slides, being the closest sibling). By the time work was starting on Figma in 2012, office suite software had already been long available and popular on the web, Google Docs was first released in 2006. This explains why no other application has been able to follow in Figma’s footsteps by bringing creative software to the web: Figma didn’t blaze a trail for other professional creative software to move to the web, instead Sketch blazed a trail for design software to become office suite software, a category that was already successful on the web.
It's still difficult for me to wrap my head around that this has actually happened, because it's unheard of in other media editing industries for software to go backwards in capabilities. I always compare it to if movies suddenly stopped needing special effects, then of course the entire existing movie-making pipeline would be re-evaluated.
this downplays what they've actually built. Their technology is first-mover and incredibly impressive in the enterprise app space, and they've built a big business around it.
That was certainly not my intention. Nothing but respect for what they’ve built. Only pointing out that they entered a crowded space that already had “winners” in it, and succeeded.
> Let it be a lesson for anyone worried that “their idea has been taken” or “there already solutions for this” out there.
I have nothing but respect for Figma's tech, but I'm not really sure this lesson is generalizable to 99.9% of other people. By all accounts Evan Wallace has skills and talent the vast majority of software developers don't have and never will have. The reason Figma was able to succeed in this space is that their engineering team was like the 90s-era Chicago Bulls of software development.
And to emphasize, that's one reason I'm very happy for Figma's success. Figma didn't succeed because they "got lucky", or just happened to be in the right place at the right time, or had great marketing. They succeeded because they were able to create a brilliant technical solution to a problem that lesser engineers and engineering teams were simply not able to solve.
Yea I'm not trying to take away from any of that, nor provide generalized advice. Only addressing the crowd of people who will shy away from pursuing (or poo poo others) when their idea isn't some sort of original innovation that nobody's ever thought of before.
Every successful company had some sort of edge. Some sort of advantage that other companies in the space don't have. For Figma that was high level tech execution. For something like, say, LaunchDarkly, that was a killer enterprise sales team. For something like Liquid Death, it was pure marketing and positioning. Just to use some other examples of companies that launched into crowded spaces and succeeded.
It could be anything, but it's always something, and no advice should be generalized.
> The reason Figma was able to succeed in this space is that their engineering team was like the 90s-era Chicago Bulls of software development.
Huge contracts are built to extract as much wealth from the customer as possible without letting the victim know. Not by engineering talent. Huge contracts are what make Figma a success story.
To me, an IPO by them at this moment let me think that they know that they are on top of the wave and that it is better to cash-in before growth starts to stale.
They got a huge influx of users when image editing AI started to be a thing, I'm not quite sure that they haven't already conquered most of new users that could join them.
Could be. It also could be that they feel comfortable raising money in the public markets for expansion, and to reward/retain their organization. We don’t really know if they tried doing a databricks or a stripe and raise billions in the private market, maybe they did, maybe they found there’s more upside in an IPO…
Readit News
Their highlighted metrics page: $821M LTM revenue, 46% YoY revenue growth, 18% non-GAAP operating margin, 91% gross margin.
It's an incredible success story, and the engineering they did upfront (primarily led by co-founder Evan Wallace) that set the stage for their success is the stuff of legends. https://madebyevan.com/figma/ has links to numerous blog posts breaking it down, but here are some choice quotes:
> [Evan] developed the hybrid C++/JavaScript architecture for Figma's editor that made it possible to build a best-in-class design tool in the browser. The document representation and canvas area is in C++ while the UI around the canvas is in JavaScript (the team eventually settled on TypeScript + React for this). This let us heavily optimize the document representation to reduce memory usage and improve editing speed while still using modern UI technologies for fast iteration on our UI. C++ development was done using Xcode (not in the browser) to provide a better debugging environment.
> Even though the contents of Figma documents are similar to what HTML can display, Figma actually does all of its own document rendering for cross-browser consistency and performance. Figma uses WebGL for rendering which bypasses most of the browser's HTML rendering pipeline and lets the app work closely with the graphics card. The rendering engine handles curve rendering, images, blurs, masking, blending, and opacity groups, and optimizes for high visual fidelity.
> [Evan] developed Figma's multiplayer syncing protocol, worked on the initial version of the multiplayer live collaboration service (a kind of specialized real-time database), and added multiplayer syncing support to Figma's existing editing application. The initial version was written in TypeScript but [he] later ported it to Rust for improved performance and stability.
It's a great reminder that it's not premature optimization if your UI's fluidity is your distinctive feature and your calling card! And the business acumen to turn this into such a wildly successful product in the context of competitors with kitchen-sink feature lists can't be understated, either. I have an incredible amount of respect for this team, and they should inspire all of us to tackle ambitious projects.
The brilliance of the system he built was that it allowed for real time collaboration. Which was god send from the Sketch -> Zeplin -> Invision -> Avocode (version management) ‘stack’ that lost Enterprise design orgs were using.
Which was already a large leap from what Adobe was expecting us to do with Photoshop/Illustrator (after they depreciated Fireworks).
Figma made handoff much easier. Made version control dead simple. Made my life as a UX leader much much better. I remembered talking to a few now-Gigantic companies back then and we all plotted the move together
It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering. It’s just that the benefits far outweighed the small drop in snappiness.
And for anyone who’s going to say “Sketch was Mac only that’s why it failed!” I assure you that had nothing to do with it. For the same reasons an entire generation of UX/UI designers stopped using Axure. But we would need to start talking about Invision 7 and Invision Studio if you wanted to get into the nitty gritty.
Why would anyone say that? Sketch is still alive and (presumably) well. Apple themselves continue to officially release design files for Sketch with every OS release. They share more resources for Sketch than any other app, including Figma and Photoshop.
http://developer.apple.com/design/resources/
> after they depreciated Fireworks
I’ve been seeing that word used a lot in this context, so just wanted to point out (I’d appreciate if someone did the same for me) that what you mean is “deprecated” (no “i”), as depreciating is a different thing.
Writing this from the perspective of someone who used to spend all day every day in Photoshop/Sketch/Figma for decades. This markedly contradicts my recollection of the state of Sketch at the time Figma was in its first public beta. Sketch's performance was abhorrent and it was constantly crashing while working with libraries. I was very skeptical about web-technology based tool in terms of performance, but Figma blew me away. It was FAST.
One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
I worked extensively in the parts of the Figma where Evan wrote a lot of foundational code, and have also worked directly with him on building the plugin API.
One of Evan's strong points as a CTO is that he was very pragmatic and that was reflected in his code. Things that could be simple were simple, things that needed complexity did not shy away from it.
While all codebases have early decisions that later get changed, I'd say that largely speaking, Figma's editor codebase was built upon foundations that stood the test of time. This includes choices such as the APIs used to build product code, interact with multiplayer, the balance between using OOP v.s. more functional or JS-like patterns, the balance between writing code in C++/WASM v.s. JS, etc. Many of these choices can be credited to Evan directly or his influence.
Subsequent engineers that joined were able to build upon the product without causing a spiraling mess of complexity thanks to those good decisions made early on. In my opinion, this is why Figma was able to ship complex new features without being bogged down by exploding tech debt, and a major contributing factor to the business's success as a whole.
yikes
I wouldn't glorify "brilliant code" that much though because code should be made to be changed. If it isn't, it's a fragility trait, not a positive trait. Code that no one knows how to change is opportunity lost.
I do understand that it may be hard to create stuff for others when you're alone and going very fast but I don't think praising it is the right idea.
I cannot believe Figma hired engineers who could not follow along already-tread footsteps. That’s a nonsensical assertion. Novel code may be inscrutable but the problem-solving and techniques should have been clear and repeatable by those who follow, even if they require adaptation.
Deleted Comment
And thats how you get designers whining that their design looks great in figma but not in a real webpage
I work on a large web based application, with designers, who use Figma. It's just too easy to lose the plot and come up with things that don't work well. Not because of Figma. Something about the balance between the software stack(s), the domain, the focus of designers today, the front end engineering, and product management is broken. It's interesting that Figma did (IMO) a great job at addressing the stack so they can build a product that does what they want it and then is used by so many to build products that don't always do what their customers want. Asking Figma to use the wrong stack for their product (which is what I'm reading between the lines) is not really the right answer...
I’ve been thinking about a box-first approach to design tooling. The overall layout workflow would consist only of adding boxes (block-level elements) to a blank web page, or inside other boxes. Boxes could also contain other elements like inputs, buttons, images, etc.
[1] https://github.com/evanw/esbuild [2] https://github.com/microsoft/typescript-go
Not because they can't be leaders in the space, but because there won't be any moat.
> Our vision for the future of design tools is one where both the tool and the content are easily available to anyone, anywhere
> The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
> We fully control memory layout and can use compact 32-bit floats or even bytes when appropriate instead of JavaScript’s 64-bit doubles...The generated code is completely in control of allocation, which makes it much easier to hit 60fps by avoiding GC pauses. All C++ objects are just reserved ranges in a pre-allocated typed array so the JavaScript GC is never involved.
> One big issue for us was that certain browser configurations couldn’t allocate large ranges of continuous address space for the huge typed array that contains the entire emscripten memory space. The worst case was 32-bit Chrome on Windows which sometimes couldn’t even allocate a 256mb typed array because ASLR was fragmenting the address space. This has since been fixed.
A great example of making a single bold architectural decision (building a design tool on the web instead of as an app) in service of a vision (prioritize live collaboration), and then thoughtfully resolving all of the performance tradeoffs that stem from this route.
Figma just has to jack up the price in order to appease Wall Street quarterly.
Business wise it's got a great margin, but the avaricious nature of Wall St. will force them to enshittify the entire product, the engineering doesn't matter unless Wall St. is satisfied.
There are several things designers need that Figma has dragged their feet on for years, and when they do release them, they’re usually behind the enterprise paywall. Or they don’t release them at all, instead opting to build some horizontal product like Slides because their investors want a bigger TAM.
Figma has the power of the network effect at present, but you can only charge people to use variables for so long before they look for an alternative.
Aren't designers mad at Adobe for doing exactly this?
None of this "designed for newspaper print" style layout. Yes, I know flexbox is very good. But it's still a hack (imo).
How the legends have fallen
"Immediately following the completion of this offering, and assuming no exercise of the underwriters’ over-allotment option, Dylan Field, our Chair of our Board of Directors, Chief Executive Officer, and President will hold or have the ability to control approximately % of the voting power of our outstanding capital stock, including % of the voting power pursuant to the Wallace Proxy. As a result, following this offering, Mr. Field will have the ability to control the outcome of matters submitted to our stockholders for approval, including the election of our directors and the approval of any change of control transaction."
There's a good reason public shareholders historically demanded accountability - maybe it's fine for now, but all it takes is some management that you can't kick out, paying themselves extortionate salaries and driving the company into the ground at the same time to recognise the problems with "owning" a company you have no right to actually control (via replacing management and so on)
$300k/DAY AWS bill. I wonder what the "non-cancellable" savings is.
Multiplayer means that every file that are user loads is loaded onto a compute server and retained in-memory on that server, processing every mutation to the document. Figma documents can get quite large -- they can contain the design system of an entire organization, dozens of variations of a product feature, etc. This means the server cost scales per active session at a given time, a higher "number" than active requests.
In addition to multiplayer, Figma attempts to keep most other parts of the application real-time. If another user adds a file to a project, you will see it without refreshing the page. That's a simple example, but certain types of queries/mutation can get much more complex.
Figma is an enterprise app, and the data models needed to support complex use cases (permissions, etc) means that DB load is a real challenge.
While the DAU count of Figma might not be as high as other consumer apps, the amount of time those users spend in Figma is often substantially higher.
Those are some of the things that contribute to a high bill. While Figma is most known for the frontend editor, the infra work is plenty interesting too.
I will admit I have waned enthusiasm a on Figma over the past couple of years. I find the UI churn confusing. The new features, i.e. dev mode and variables, feel out of place. I find the plugin ecosystem cumbersome. Doing simple things has become complex. I'm putting out real "who moved my cheese?" energy here I know. I suppose I'm wondering if others feel the same.
Create a product sell or IPO. Revenue pressure increases. Product cost is increased or staff is cut. New software takes crown. Rinse and repeat.
I work in complex SAAS product design. Basic things I can do in CSS I can't do in Figma. Things like a table? Yeah it is entirely faked and awful in Figma. Don't even get me started on anything more complicated than flex rows and columns.
Half the debate over designer/dev handoff in the industry right now is simply because of Figma's limitations and the refusal of designers and front-end devs alike to learn HTML and CSS.
We need a Blender-like tool for web and app product design. Highly capable and advanced, you aren't expected to know all of it, and it can do anything you want it to.
I need a tool that is more than just a fancy rectangle drawer.
HTML and CSS are expressive, have a vast selection of libraries and tools, and can actually result in shippable code. Designers and front-end devs should learn and use it.
But I don't see the point in creating a design tool unless it's meaningfully simpler than HTML/CSS. I reach for Figma when I need to quickly mock up a dozen iterations using our design system and fancy rectangles. It's fast enough that I can make mockups in realtime during discussions with developers and subject matter experts. But if I'm actually going to take the time to set constraints to make things flex properly or make a real table then why not use HTML and CSS directly?
The problem then was that the designs could be too cumbersome to implement (and also that you couldn't share files with developers as easily, but Sketch has the same problem). You can really do just about anything in PS/AI, whereas with Figma and Sketch it's almost like they limit you to what an average developer can implement with CSS.
That being said, we're in the age where you can do pretty much anything with CSS, and I totally agree with you that Figma's controls are very basic (especially for typography, there's just not enough options).
When my devs just copy whats in Figma dev-mode they get so much stuff wrong.
Is this an uncommon use case?
From an accounting perspective, it was an $800 million stock-based compensation expense, though it didn't really cost Figma anything.
So the numbers for the year before IPO may have no relation to future.
Then that AI feature they highlighted was pulled off production because it was cloning iOS.
The AI heavy product dump we just got are lessons from that time.
> In the section on Photoshop to Sketch, we discussed an underappreciated factor in Sketch’s, and by extension, Figma’s, success: That flat design shifted the category of design software from professional creative software to something more akin to an office suite app (presentation software, like Google Slides, being the closest sibling). By the time work was starting on Figma in 2012, office suite software had already been long available and popular on the web, Google Docs was first released in 2006. This explains why no other application has been able to follow in Figma’s footsteps by bringing creative software to the web: Figma didn’t blaze a trail for other professional creative software to move to the web, instead Sketch blazed a trail for design software to become office suite software, a category that was already successful on the web.
It's still difficult for me to wrap my head around that this has actually happened, because it's unheard of in other media editing industries for software to go backwards in capabilities. I always compare it to if movies suddenly stopped needing special effects, then of course the entire existing movie-making pipeline would be re-evaluated.
I have nothing but respect for Figma's tech, but I'm not really sure this lesson is generalizable to 99.9% of other people. By all accounts Evan Wallace has skills and talent the vast majority of software developers don't have and never will have. The reason Figma was able to succeed in this space is that their engineering team was like the 90s-era Chicago Bulls of software development.
And to emphasize, that's one reason I'm very happy for Figma's success. Figma didn't succeed because they "got lucky", or just happened to be in the right place at the right time, or had great marketing. They succeeded because they were able to create a brilliant technical solution to a problem that lesser engineers and engineering teams were simply not able to solve.
Every successful company had some sort of edge. Some sort of advantage that other companies in the space don't have. For Figma that was high level tech execution. For something like, say, LaunchDarkly, that was a killer enterprise sales team. For something like Liquid Death, it was pure marketing and positioning. Just to use some other examples of companies that launched into crowded spaces and succeeded.
It could be anything, but it's always something, and no advice should be generalized.
Huge contracts are built to extract as much wealth from the customer as possible without letting the victim know. Not by engineering talent. Huge contracts are what make Figma a success story.
They got a huge influx of users when image editing AI started to be a thing, I'm not quite sure that they haven't already conquered most of new users that could join them.