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.
> Why would anyone say that? Sketch is still alive and (presumably) well
When people deep into the startup-woods say "Fail" what they really mean is "Didn't take over the world". Their perspective of "winning / failing" is a bit more black and white than the average person.
With that said, Sketch certainly didn't become more popular because the macOS requirement even for viewing the files. I remember that there was some hacks to be able to at least view them on Linux, and other things like Zepplin (or similar) made it even easier, but it was still cumbersome.
Then Figma appeared, offered more or less the same features, slightly worse performance than Sketch, but worked absolutely everywhere and was easy to open and inspect things for everyone on the team. Obviously, Figma ate a lot of the Sketch user-base, which is something I saw in multiple companies myself.
> When people deep into the startup-woods say "Fail" what they really mean is "Didn't take over the world". Their perspective of "winning / failing" is a bit more black and white than the average person.
Good point (also, “deep into the startup-woods” is a great way to put it). I suspect there’s a major overlap between those people and the ones who are obsessed with products “killing” another. The same kind of people who are hyped by any new shiny pebble as if it’s the second coming of Christ and immediately eschew everything which came before. The people who are so blind to context they shouted “zOMG Google is dead because of ChatGPT” because they were incapable of thinking for two seconds that Google has a ton of cash to survive in the long run, were already leading research in the field, and (of course) wouldn’t just fold their arms and stay still. In short, people not worth listening to.
This is 1 part hilarious and 1 part bewildering. You wrote an entire silly imaginary novel about my life based on a poorly worded (to your standards) sentence.
Sketch dominated the landscape. Now they are a small percentage of the landscape. I characterized that as a 'fail'. Sure, maybe an inexact word but what else do you call going from 60%+ of the market share down to below 20%? And btw I currently pay Sketch $120 for a personal license (so they obviously haven't failed in that sense).
And spare me the 'context' thing. Because my context on this subject is as a individual contributor, leader of multiple large design orgs with dozens of designers all in the same tools, as an early Sketch, Figma, Invision and Framer X customer. The context is up there with the Console Wars but I don't have the room for that here.
Er, my friend, you utterly misunderstood my comment. I wasn’t thinking about you at all when I wrote that (I didn’t have any individual in mind, just an amalgamation of opinions I’ve seen shared in multiple places). Why would I? The way I understood (and replied) to your original comment, you weren’t one of the people saying Sketch had failed. I was supporting and continuing your point, not refuting it, though now I understand you were indeed agreeing with your imaginary users saying Sketch failed but disagreeing with their imaginary reasons. My bad, I misunderstood that about your argument.
But if you felt attacked, that is entirely on you. It wasn’t at all my intention, and my comment is pretty clearly a continuation of what the other user said, which in my view also didn’t attack anyone specifically. Yours was one of the strangest and most unexpected responses I got in recent memory, and it took me a bit to even understand why you were so mad and thumping your chest. Hilarious and bewildering indeed.
People say it all of the time. Go onto any other platform discussing this topic and you'll see it as the most cited reason for Figma's dominance.
Yes, Sketch's logo has been featured in a Apple keynote before. I'm familiar with their relationship with Apple and it seems like their team is perfectly happy not being the gargantuan that Figma is.
Sometimes I feel like people just want to find any reason to disagree on here.
Lastly, maybe you should just make a depreciation (sic) bot.
Of course we would say that, with the exception of my current employer, and I am approaching 50 years, no one else has used Apple gear on the office, designers working at my previous employers had to put up with Windows if they wanted a job, and I can vouch we always had plenty of candidates looking for one.
> 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.
There's definitely others that shared your perspective. A commonly cited reason of early Figma adopters was that they felt it was faster than Sketch.
Of course, the reality was that performance is a super nuanced thing. It's always measured in relation to specific things, but ultimately summarized via a "feeling".
Aspects of performance include:
- Loading a (blank/medium/large) file from (scratch/cache/etc)
- Performance when editing (what?), panning, zooming (small or large doc?)
- Performance with a large number of simple objects, or complex objects (components? variables? nested components? drop shadows/background blurs?)
I haven't personally done some performance comparisons between the two apps since ~2018 but at the time there were definitely things where Figma was noticeably faster than sketch, a lot of things that were comparable, some things that were slower. My own very biased feeling was that Figma was faster more often than not but it's always up to the individual use case, how their file is setup, what they are doing within that file, and how they mentally weigh those different scenarios.
I definitely didn't feel like being on the web was a limiting factor. In some theoretical state, with infinite resources to optimize everything, native could be faster since you have access to lower-level APIs. In practice, that's the same argument as "it could be faster in hand-written assembly". Almost never did we get to the point where we'd use those abilities even if we had them, due to their cost on development and impact on the correctness/maintainability of the code.
> 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
thats the biggest one probably; saw it firsthand at a large company that was using sketch but managers and others using windows or devs on linux wanted to see the designs for work and nobody was gonna change to mac for that so figma it was...
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.
The perception at the time was that Adobe had abandoned UX designers and wasn't willing to tailor any of their tools to them. So they (we) moved on.
I was at a SXSW session with XD's product team in the early weeks/months of that products existence. The Q&A section was filled with a lot of dismissive statements and questions. XD was never going to survive.
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.
+1 from another Figma engineer who happened to work on the text engine back in the day.
I think that Evan generally wrote code that was as simple as possible — there was no unnecessary complexity. In this case there indeed is some inherent, unavoidable complexity due to the math involved and the performance requirements, but otherwise I found our text rendering pipeline very understandable.
It’s a clever trick. But can it render a textured text? Transparent text, gradient fills? Maybe it can, I dont know. But why not just triangulate the glyph shapes, and represent each glyph as a set of triangles. This triangulation can be done offline, making rendering very lightweight.
The linked post was about Evan's side project, but within Figma, all of that is indeed possible. The glyphs are transformed into vector networks[0], which has a fill pipeline that supports transparency, gradients, images, blending, masking, etc.
It is incredible how easy this stuff spirals out of control and why I'm not too worried about AI yet.
Every now and then I'm writing a PoC or greenfield project that you put down for 6 months. And sometimes when I pick it up to extend it, it will just so rapidly feel like it's getting out of control (I'm actually listening to the chemical brothers song of the same name at the moment!). I can at least usually fix that with some refactoring, but why didn't I get it right at the time? I don't know.
And it's often hard to figure out why, what architectural decision did you make to cause this. Pointing at the particular interface or pattern or method call chain that is the cause of a ton of complexity that could be fixed is much, much, much harder than most jobs in programming. And beyond the ability of 90% of developers.
The -2000 story popped up here again recently (https://news.ycombinator.com/item?id=44381252), and it's of the same vein, why had no-one else done that? Because it takes extreme skill to simplify existing code. It's beyond most developers.
I think it's why we as an industry often obsess about things like space/tabs/semi-colons or not/etc. They're obvious improvements to an architecture, and everyone can join in. But really, they're a small improvement to a codebase, not a massive one.
And then you get the Evans of the world who just do it, almost effortlessly. I've worked with an Evan, and sometimes you'd look at his code and think "why?", but any attempt to change or improve it invariably made it worse. He'd picked that pattern or structure or method call chain and it was always the right choice. And after a day of poking at it, exploring the edges, trying to change it, you'd realize why.
And yes, sometimes the code was so complex other developers couldn't get it. And then they'd call me over to help because I could get it. And I'd look at it and realize it was complicated because it had to be like that. He'd actually done it in the simplest way possible.
And years later I still make the wrong choice sometimes, and I always think of Simon and wish I had his magic touch.
Even if he used to name functions Thing() and DoStuff() and forget to update them.
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.
The first startup I worked at was in typography. Writing a full typographic rendering engine in webGL shaders is going to result in code that is difficult for others not experienced in webGL and typography.
It’s inherently (and likely irreducibly) difficult, not accidentally/gratuitously difficult.
It’s a bad thing if you make a simple thing more complicated than it needs to be.
But there are plenty of Hard Problems out there, for which no sufficient code could be called “simple.” Plenty of aspects of font rendering fall within this bucket. It’s notoriously difficult.
That's what I was thinking, but then, it is very specialized and high performance code well outside of my domains (font rendering, shaders, C++, high performance / frequently called code is very much not my bread and butter). I frequently glaze over whenever trying to read a post about some optimization problem. Fast inverse square root [0] is succinct and cleanly written even though it uses math symbols instead of variable names, but I have no idea how it works and don't have the math basics to even know when / where / why to use it.
Usually it is dangerous to let such people write application level code, but according to the reports in the comments, the guy might be one of the few exceptions, who gets the low level right, but also created flexible extensible structure of code in other places, without it becoming obscure on the application level.
Usually when I see some mathematical code that's not explained at all and has obvious flaws in terms of simple improvements that could be made to improve readability or even something as simple as some comments, I just keep thinking: "Please don't let this person touch application level code!"
As others have pointed out: if the complexity is in the domain then that's perfectly acceptable. I always remember reading some lines of code in Linux that had a comment above them: "This code is meant to be read by a CPU, not by a human."
The hard part is knowing when the code is complex because the domain/performance requirements demand it be that way vs when the code is complex because the engineer was just trying to appear smarter than they are.
Computer typography is a dark art. It requires understanding a whole domain with its own terminology and traditions as well as aesthetic sense, then combine that with the programming knowledge.
Exactly, I had the same issue when I was younger. I thought if I read code I could not understand was because the other dev was a legend. Now its the opposite, I am amazed by code that does its job well, its understandable and has low complexity.
> 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 reason to write code is to solve a problem. If the problem domain is complex, then the code to solve said problem will be inherently complex. He solved a problem.
Font rendering code is a nightmare because the problem is really damn hard. Font files are complex, and actual real world usage is even worse.
Any code that involves parsing old school binary file formats is going to look ugly to modern day developers who are used to JSON everything, even if the code is actually very well structured.
Even well-written code can be hard to understand -- practically impossible, even -- if what it's doing is sufficiently complex. Cryptography and certain areas of graphics have humbled me, for instance. I followed the flow, and I appreciated the comments, but I did not understand.
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.
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.
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.
I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient.
Code that doesn't need to change is a really good sign that you've got something good.
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".
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.
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...
Is this alignment the issue with your application? Are there design alternatives that would be impacted less by some rendering engine differences?
What about other browsers? Versions? Platforms? OS? Resolution/screen size? My huge frontend team can't handle this, even before we used Figma.
Isn't the problem trying to get this "web platform" do something it was never meant to do? How would this be solved by Figma using a rendering engine that would grind their product to a halt?
I'm old enough to have done a lot of native platform UI work, the web stack in many ways was a step backwards. It has obviously a lot of advantages (run anywhere) but in some ways it's more like IBM terminals on a mainframe vs. a native UI where you have full control. I (obviously) use and make web apps all the time, but they often suck, and this isn't Figma's fault.
I've been fighting the way figma interprets fonts for years. It's not too bad at my current company, but at my last company things would look great in figma but with the exact same styles applied they'd be wrong in every browser. That's the sort of thing people are complaining about here.
I'm sure there's something fundamentally wrong with the font files. In both cases, they're not standard, widely available fonts. With that said, browsers render the fonts consistently with each other, but not Figma.
There's also a lot of ways that figma can lead designers down the unhappy path. They'll put together two different screens that look great, wave their hands around the idea of "just make it responsive" and when you go in and look, there's nonsensical crap like absolute positioning on elements, or arrangements that don't work with block layouts and force you into convoluted grid stuff.
Figma is clearly built to be useful for web development. It has tons of gaps that lead designers off the happy path. Take out all the "browsers / versions / os / screen size" differences from the argument; my points above would apply to any design tool built for any product. If it doesn't accurately reflect what is possible or how something is done, it's not a perfect fit.
PS: I prefer figma over pretty much every other tool I've used. With that said, there's no pretending that it is perfect, nor any reason to deflect accurate criticism elsewhere.
My solution in these cases was to build prototype sites that sync in real time from the figma file. So the designer can see how their work actually looks, and treat the figma view as just a low fidelity preview.
Could you point to any resources on how to achieve this? At work we're increasing our Figma usage, and this approach sounds like something better implemented sooner than later
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.
Don't quite follow you, but if you're talking about a box-based layout for the web, that's a little overly simplistic as "the" layout, but is already possible. Keep in mind the historical underpinings; web documents were always more like scrolls than screens.
Not really, I’m not thinking to replace CMS builders like Wix or Squarespace either.
More like ”no-code design directly in HTML and CSS”, but with familiar Figma/Sketch-line controls for sizing, alignment, etc. Responsive by default, boxes full-width and vertically sized by content by default, manual pixel sizing of elements heavily discouraged in favor of block/inline-block/inline. Sane defaults for theme tokens, but easily customizable.
In other words, a hands-on design tool for web layouts, working directly on the DOM and stylesheet, preferring the flow for positioning and leveraging (normalized) HTML/CSS defaults.
My thinking is mostly born out of frustration with the performance of flexbox-inside-flexbox layouts and the total disparity of text layout between web and existing design tools.
See https://every-layout.dev for a mind-blowingly well-thought-out approach to CSS that builds from first principles and leverages sane primitives and a typographic scale to compose dynamic layouts... it's boxes, and it's beautiful.
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.
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).
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.
I'm curious what the missing features are in Figma from a designers perspective. You've mentioned the paywalled variables, what else? (I haven't been a product engineer in years, and have barely touched Figma in the last ~5 years)
- Clunky component and variable system; inadequate for more complex stuff with lots of parameters.
- Can't set connectors on Design files (used for documenting the navigation flow between different pages of an app).
- You can set connectors on FigJam files, but if you want to bring your components from Design files then you can't keep the instances synchronised to the component definition. And you can't attach the connector endpoint to some element inside the Design component. It's essentially just an image export of the Design component.
- Prototyping is very clunky and trying to build a flow that has elements reacting to interactions on other distinct elements is either variable hell or downright impossible.
Those are just off the top of my mind. I'm always finding threads from 5 years ago on their community forums with loads of people on the same boat and no activity from Figma side.
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.
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.
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).
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?
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.
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!
> 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.
> 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.
This, “permissions, etc”, isn't just an enterprise-scale problem, any multi-tenant system can and probably will hit it.
Working out who can access what can sound simple enough, but it gets rather less pleasant when the rules can be set with more complex ACLs¹ and because people can move around dynamically it is both potentially resource heavy to derive and difficult to cache² both safely and³ efficiently. It is natural to think “well, we can simplify the permissions model”, but you really can't when selling to different enterprises: many have their own idiosyncratic workflows, or local tweaks if using an “industry standard” workflow, and they will make a noise if your software to support them without extra tricks on their part.
We are at a much smaller scale⁴, in another industry, but this is an issue we have to be very careful about.
--------
[1] Is this person in a given group? Does that give or remove permission? Can they just access, or edit, add, …? also: different elements on the same screen could have very different ACLs to each other and at different times in a process
[2] missing changes for a time could cause significant issues if users are working on something commercially important or otherwise sensitive
[3] Safe is easy: don't cache at all. Efficient is easy: don't care about a bit of staleness and accept a bit of “eventual consistency”/“eventual correctness”. Achieving both takes a pile of resource even with a great design.
[4] We don't have to worry about consistently spreading data and processing over a set of DCs as our product has natural borders between tenants so splitting off into distinct DBs⁵ is an easy answer to some of the scale & efficiency issues.
[5] rather than needing everything in on “public” system because anyone can potentially want to share access with any other user.
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.
"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)
There are certainly downsides to it, but you’ll notice that most of the biggest companies of the last 20 years had a dual class stock structure that gives the founders a high level of control.
The most efficient government is a benevolent dictatorship, the problem, of course is that benevolent dictators don’t live forever and sooner or later you get a non-benevolent one.
These sorts of dual class share structures avoid that issue by generally becoming common stock on transfer so it turns into a democracy with the end of the dictator.
With an IPO you at least got to spend several years seeing how the dictator did.
It's actually a crime in the US not to manage a public company in the interest of the shareholders. (There was a large case which Ford lost establishing the way this is interpreted now which many people argue is why it gets interpreted in such a shortsighted way so often although personally I'm not sure.)
It makes sense, you're disposing of the capital the shareholders own.
Dodge v. Ford Motor Co. was a civil case, not a criminal case. And it was in the Michigan Supreme Court so has no standing in the other 49 states.
And in practice the "business judgement rule" makes it very easy for businesses to do whatever they want as long as they have a vaguely plausible explanation for how it helps the business as a whole. ("We need to buy a private jet for our CEO because he is integral to our growth and success.")
SEC and most states like delaware where companies incorporate do have minority shareholder protections, regardless of these terms.
A board of directors can screw shareholders even without one controlling director.
The protections for minority shareholder are seperate.
Also the news of malpractice by directors like you mention leads to SEC investigations and stocks come crashing down before they can sell it (as they must declare their stock sales a few days before doing it)
Given cases like Elon moving to less protective jursidictions, those protections are not necessarily as protective as you might prefer, especially if you sign them away at some point in the past.
It's going to be a lot harder to protect your rights, especially around the margins, if you agree to terms like the above.
The alternative is enshittification of the entire product lineup to include ads, exorbitant subscription prices, reduced functionality along a painful price gradient, morphing into a dopamine social product, or a goal to rent real-life assets for to an increasingly impoverished population. Pee in your piss bottle while delivering that Amazon package until we can figure out how to automate your job away too. The shareholders demand it!
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.
It’s not really punishment if you don’t care what your share price is. A lower share price doesn’t hurt a company unless perhaps they are trying to do a secondary offering or something.
It does, however, hurt the Wall Street investors. If they have enough power to do so, they will replace the CEO if a share price is too low for too long.
That’s what creates the short term incentive that is a trouble and a lot of public companies. If the CEO has control of the voting shares, that pressure is relieved.
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.
Except it was not a crowded space. They did a bunch of stuff no one else was (or is) doing right from the start. Being entirely in the browser, real-time collaboration, vector networks…
You can define any space as "not crowded" if you narrow it down enough. That was the point really, they entered a crowded space & re-defined it with their offering.
> You can define any space as "not crowded" if you narrow it down enough.
I mean, you’re technically correct¹ but that’s not exactly helpful because the inverse is also true: You can define any space as “crowded” if you widen it enough.
That is to say it is perfectly plausible I am wrong and the space was crowded, but that argument doesn’t really prove or disprove it.
> That was the point really, they entered a crowded space & re-defined it with their offering.
Especially if you allow someone in the space to redefine it. At that point all bets are off and anyone can claim anything.
The product space they entered, UX design tooling, was very crowded. Sketch and InVision were the kings and there were a dozen other reasonable options to choose from (including ones in browser with real time collab and other interesting tech).
Figma entered that market later and won on a combination of technology and product innovation aka execution.
> 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.
That's such an unfair, pessimistic, and "economics-free" take. The giant enterprises with "huge contracts" as you point out are not "victims" - it's not like they're hapless newbies who don't know how enterprise contracts work. Especially in the case of Figma, where there are loads of competitive products (which was the point of the comment I was responding to), clients have plenty of other options. They chose and continue to choose Figma because they believe it gives them value over other possibilities.
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…
Reminds me of the Linear story. You can disrupt a set of established players by focusing on simplicity, opinionated design, and maximum performance via hardcore engineering.
I think the point the parent comment is making is that companies shouldn't be able to trademark common phrases with their usual spelling. 'Dev mode' is a common short form for 'developer mode' which has extensive use.
A bit off-topic, but I really wish we had a system where we could make bets to pit public companies that develop closed source software against its FOSS alternatives.
In the example here: people would bet by either buying $100 worth of Figma shares, or they could buy $50 worth of put options and give $50 to the developers of Penpot.
Would something like that be legal or does it violate any type of trading regulations?
My idea is more about a system that can track and mediate support for the pro-FOSS than anything. For the pro-commercial side of the bet, showing ownership of the shares would be enough I guess.
I see this play out a lot in my country’s stock market. Where numbers are fine and all hunky dory. But in reality all increase in share prices — those meteoric rises has already happened behind the curtain which separates it from the public (and for good). And then IPO comes and the public mostly oays for the final exit.
Is this an IPO where participants (public) will make long term money of it’s already at the top and this is the final stage of “finding someone to hold the bag” and in this case eventually — the public i.e the retail trader, mostly?
More and more companies are now holding bitcoin in their treasuries (including Figma according to the filling). It's interesting, but it makes a lot of sense.
Figma is an incredible product but I don’t like what they’re doing with AI. They should focus on enabling UI/UX designers to do more instead of making a glorified Dreamweaver.
So, this is a cash out before AI or AI-first solutions out do Figma?
Seriously, are people starting to replace Figma with just basic LLM or simpler LLM-based solutions? I'm just trying to understand the timing of the IPO and the market. We used to use Figma, but dropped it as first phases of product design loop ended. Basic LLM does not feel there yet, but it does feel like it could be there very quickly.
Congrats Figma! It annoys me every time I open their UI, billions of dollars in revenue for a web design tool, yet still no way to export tokens natively as CSS.
That said, today it's an incredibly good design tool - worth checking out before shareholders start the enshittification process. Congrats to the devs / founders for making it all the way to an IPO!
With all the AI tools, the market is in a transition period.
Those transitions are crucial for a product's success or failure. For example, the transition from web to mobile with the iPhone, along with the growing pains of using Photoshop and Illustrator for mockups, opened the door to Sketch. Then, the evolution of web apps, like Google Docs, opened the door to Figma (while other products like InVision had a drastic fall). What they accomplished in a web app is an impressive engineering feat, so they have an excellent engineering team.
The good: Figma is implementing multiple product updates to capitalize on the "AI wave". The Figma Make in beta is very similar to Vercel's v0 (and others). Still, the tight integration with Figma could help them leverage their current subscriptions and attract designers, PMs, and developers. Recently, they released an MCP server in beta that enables AI coding tools to obtain information from designs. While many designers may disagree with me, I believe that at least they are trying to maintain a leading position in a rapidly shifting market.
The bad: They are diversifying their product offering too much, trying to compete on many fronts. Figma Site competes with Framer and Webflow, and Figma Buzz aims at digital marketing, which is usually covered by many tools (including Canva). Figma Slides is ideal for designers who use Figma daily, but it may not be as user-friendly for those transitioning from PowerPoint or Keynote.
They switched the focus from the Design->Dev process that made them successful. The dev mode still doesn't resolve many issues, such as versioning, and the variable features seem half-baked; component handling needs more love, and the prototyping options are still limited.
The future... is hard to tell. In terms of UI design tools, they are the leaders. Penpot is far from being stable; Sketch is similar, but their web experience is not as good as Figma. Unless a new player enters the market, their biggest threat is a significant disruption caused by AI tools... but the tools I've seen so far are not different from Figma Make.
Beyond Penpot and Excalidraw, check out Sketch (Mac-only but mature), Lunacy (offline-capable), and Plasmic (code-focused) - all with different trade-offs but less pressure to monetize aggressively.
I find it kind of ridiculous that I need dev mode to get some values that they expose outside of dev mode but in a less dev friendly way. I know there's more to it, but come on...
So now that Figma will be owned by Wall Street, it will only get considerably worse from here. It is now time consider and find and fund open source alternatives.
I know of excalidraw and perhaps penpot are there anymore?
And how would that happen? They already have the product, which can be sold in huge numbers without really needing to scale operations. Are you suggesting they need cash to rewrite or improve the product?
At my company we use Miro a ton. It doesn't have the design tools, just the white boarding and diagramming, so its Figma counterpart is FigJam. But the realtime collaboration features are just as good, and sometimes better. They have a decent desktop Electron app that wraps it, too.
With the biggest differentiator being that in Penpot, everything is a SVG/Open Standards, which for us web folks is a neat addition. Also developed by a local company in Spain, go Spain! And for the nerds, it's open source and built using ClojureScript :)
Oh, so that’s why they’re taking it public: they are turning the company into a crypto investment fund which just happens to provide a SaaS design tool.
> they would offload things like that to not spook investors
Judging by the amount of fairly traditional companies holding Bitcoins, it would seem like holding Bitcoin is no longer spooky. I guess it makes sense when the financial environment is slowly turning into one without any regulations, Bitcoin will thrive in that sort of market.
So much negativity in this thread. I thought we’d be able to celebrate this one. Figma provided an alternative to the evil Adobe empire that was actually better. It’s powered by some amazing tech built originally by one of the founders. It’s still got a generous free plan. I’m happy the employees will get to cash out.
I mean yeah, it's cool and all that the employees and owners get a pay out, but IPOs are generally bad news for users, and I'm sure I'm not the only Figma user here, so makes sense that people are cautious about something that is usually bad news for them.
> Figma provided an alternative to the evil Adobe empire that was actually better
That's the crux, because generally IPOs mean that they'll now slowly turn into whatever it was they were supposed to fix. Maybe Figma will be the 1-in-a-billion products that won't suffer that fate, but it's understandable that people are now starting to casually look for alternatives, given most people's experience with IPOs.
"Great" for the majority of these is a stretch. There's no shortage of complaints about how Spotify treats both artists and customers, and Roblox enjoys yearly controversies from how it provides access to and exploits its customer base of children.
Bruh, Spotify has been absolutely shit, and their practices and push towards AI and completely unusuable suggestions algorithm are making it more and more shit.
It's not a big deal but the cars allowed on Uber has worsened. I remember trying to sign up as a driver a few years ago with a 2009 Corolla and being denied because the car was too old and now see cars from then allowed today. Maybe that's the cost of scaling but I find it worse. Also no more Uber pool.
I like Uber but I was surprised at how bad their mapping is - they get the route to get me home wrong and I've gone through the process of telling them about the mistake in their maps and they just seemed to ignore me.
I like Figma. My disappointment is that I know it's a transient tool. I grew up learning Photoshop, a tool which I now never use because it is expensive and neutered. And Sony Vegas, which is also expensive and pointless when free alternatives do the same thing. And now I can add Figma to the list of tools I learned but will likely never touch for even a free project. Which makes me sad! I like it.
This business model isn't sustainable for individuals, so they're going to naturally be upset. If the B2B market is more lucrative for Figma then they have every right to optimize for it, but they're going to pay the cost in user goodwill. Many startups go through this process.
Also Sketch [1]. Everyone abandoned it when Figma became the pOpUlAr tool, but I still use it every day, nearly 15 years later and it's continued to improve.
I never switched away from Sketch for personal use. Figma’s collab tools are great, but I find it somewhat clunky for usage beyond prototyping (such as creating image assets).
Figma’s cloud-first nature never also sat well with me… I still have the source PSD files for my earliest works from 25 years ago, which can still be viewed and edited perfectly. Will that be true of my Figma documents in 25 years? It’s not even a question with Sketch.
They don't link to the Form S-1 prospectus from their announcement, but it's publicly available at https://www.sec.gov/Archives/edgar/data/1579878/000162828025...
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.
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.
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.
> Why would anyone say that? Sketch is still alive and (presumably) well
When people deep into the startup-woods say "Fail" what they really mean is "Didn't take over the world". Their perspective of "winning / failing" is a bit more black and white than the average person.
With that said, Sketch certainly didn't become more popular because the macOS requirement even for viewing the files. I remember that there was some hacks to be able to at least view them on Linux, and other things like Zepplin (or similar) made it even easier, but it was still cumbersome.
Then Figma appeared, offered more or less the same features, slightly worse performance than Sketch, but worked absolutely everywhere and was easy to open and inspect things for everyone on the team. Obviously, Figma ate a lot of the Sketch user-base, which is something I saw in multiple companies myself.
> When people deep into the startup-woods say "Fail" what they really mean is "Didn't take over the world". Their perspective of "winning / failing" is a bit more black and white than the average person.
Good point (also, “deep into the startup-woods” is a great way to put it). I suspect there’s a major overlap between those people and the ones who are obsessed with products “killing” another. The same kind of people who are hyped by any new shiny pebble as if it’s the second coming of Christ and immediately eschew everything which came before. The people who are so blind to context they shouted “zOMG Google is dead because of ChatGPT” because they were incapable of thinking for two seconds that Google has a ton of cash to survive in the long run, were already leading research in the field, and (of course) wouldn’t just fold their arms and stay still. In short, people not worth listening to.
This is 1 part hilarious and 1 part bewildering. You wrote an entire silly imaginary novel about my life based on a poorly worded (to your standards) sentence.
Sketch dominated the landscape. Now they are a small percentage of the landscape. I characterized that as a 'fail'. Sure, maybe an inexact word but what else do you call going from 60%+ of the market share down to below 20%? And btw I currently pay Sketch $120 for a personal license (so they obviously haven't failed in that sense).
And spare me the 'context' thing. Because my context on this subject is as a individual contributor, leader of multiple large design orgs with dozens of designers all in the same tools, as an early Sketch, Figma, Invision and Framer X customer. The context is up there with the Console Wars but I don't have the room for that here.
What's your context?
Have a great day!
Er, my friend, you utterly misunderstood my comment. I wasn’t thinking about you at all when I wrote that (I didn’t have any individual in mind, just an amalgamation of opinions I’ve seen shared in multiple places). Why would I? The way I understood (and replied) to your original comment, you weren’t one of the people saying Sketch had failed. I was supporting and continuing your point, not refuting it, though now I understand you were indeed agreeing with your imaginary users saying Sketch failed but disagreeing with their imaginary reasons. My bad, I misunderstood that about your argument.
But if you felt attacked, that is entirely on you. It wasn’t at all my intention, and my comment is pretty clearly a continuation of what the other user said, which in my view also didn’t attack anyone specifically. Yours was one of the strangest and most unexpected responses I got in recent memory, and it took me a bit to even understand why you were so mad and thumping your chest. Hilarious and bewildering indeed.
People say it all of the time. Go onto any other platform discussing this topic and you'll see it as the most cited reason for Figma's dominance.
Yes, Sketch's logo has been featured in a Apple keynote before. I'm familiar with their relationship with Apple and it seems like their team is perfectly happy not being the gargantuan that Figma is.
Sometimes I feel like people just want to find any reason to disagree on here.
Lastly, maybe you should just make a depreciation (sic) bot.
Of course we would say that, with the exception of my current employer, and I am approaching 50 years, no one else has used Apple gear on the office, designers working at my previous employers had to put up with Windows if they wanted a job, and I can vouch we always had plenty of candidates looking for one.
> 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.
There's definitely others that shared your perspective. A commonly cited reason of early Figma adopters was that they felt it was faster than Sketch.
Of course, the reality was that performance is a super nuanced thing. It's always measured in relation to specific things, but ultimately summarized via a "feeling".
Aspects of performance include:
- Loading a (blank/medium/large) file from (scratch/cache/etc)
- Performance when editing (what?), panning, zooming (small or large doc?)
- Performance with a large number of simple objects, or complex objects (components? variables? nested components? drop shadows/background blurs?)
I haven't personally done some performance comparisons between the two apps since ~2018 but at the time there were definitely things where Figma was noticeably faster than sketch, a lot of things that were comparable, some things that were slower. My own very biased feeling was that Figma was faster more often than not but it's always up to the individual use case, how their file is setup, what they are doing within that file, and how they mentally weigh those different scenarios.
I definitely didn't feel like being on the web was a limiting factor. In some theoretical state, with infinite resources to optimize everything, native could be faster since you have access to lower-level APIs. In practice, that's the same argument as "it could be faster in hand-written assembly". Almost never did we get to the point where we'd use those abilities even if we had them, due to their cost on development and impact on the correctness/maintainability of the code.
Plus then designers, devs and stakeholders can participate on any OS they wish to use. Which, at least to me, is still important.
thats the biggest one probably; saw it firsthand at a large company that was using sketch but managers and others using windows or devs on linux wanted to see the designs for work and nobody was gonna change to mac for that so figma it was...
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.
The perception at the time was that Adobe had abandoned UX designers and wasn't willing to tailor any of their tools to them. So they (we) moved on.
I was at a SXSW session with XD's product team in the early weeks/months of that products existence. The Q&A section was filled with a lot of dismissive statements and questions. XD was never going to survive.
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.
+1 from another Figma engineer who happened to work on the text engine back in the day.
I think that Evan generally wrote code that was as simple as possible — there was no unnecessary complexity. In this case there indeed is some inherent, unavoidable complexity due to the math involved and the performance requirements, but otherwise I found our text rendering pipeline very understandable.
Evan actually wrote about it if you're curious to learn more: https://medium.com/@evanwallace/easy-scalable-text-rendering...
It’s a clever trick. But can it render a textured text? Transparent text, gradient fills? Maybe it can, I dont know. But why not just triangulate the glyph shapes, and represent each glyph as a set of triangles. This triangulation can be done offline, making rendering very lightweight.
The linked post was about Evan's side project, but within Figma, all of that is indeed possible. The glyphs are transformed into vector networks[0], which has a fill pipeline that supports transparency, gradients, images, blending, masking, etc.
[0]: https://www.figma.com/blog/introducing-vector-networks/
It is incredible how easy this stuff spirals out of control and why I'm not too worried about AI yet.
Every now and then I'm writing a PoC or greenfield project that you put down for 6 months. And sometimes when I pick it up to extend it, it will just so rapidly feel like it's getting out of control (I'm actually listening to the chemical brothers song of the same name at the moment!). I can at least usually fix that with some refactoring, but why didn't I get it right at the time? I don't know.
And it's often hard to figure out why, what architectural decision did you make to cause this. Pointing at the particular interface or pattern or method call chain that is the cause of a ton of complexity that could be fixed is much, much, much harder than most jobs in programming. And beyond the ability of 90% of developers.
The -2000 story popped up here again recently (https://news.ycombinator.com/item?id=44381252), and it's of the same vein, why had no-one else done that? Because it takes extreme skill to simplify existing code. It's beyond most developers.
I think it's why we as an industry often obsess about things like space/tabs/semi-colons or not/etc. They're obvious improvements to an architecture, and everyone can join in. But really, they're a small improvement to a codebase, not a massive one.
And then you get the Evans of the world who just do it, almost effortlessly. I've worked with an Evan, and sometimes you'd look at his code and think "why?", but any attempt to change or improve it invariably made it worse. He'd picked that pattern or structure or method call chain and it was always the right choice. And after a day of poking at it, exploring the edges, trying to change it, you'd realize why.
And yes, sometimes the code was so complex other developers couldn't get it. And then they'd call me over to help because I could get it. And I'd look at it and realize it was complicated because it had to be like that. He'd actually done it in the simplest way possible.
And years later I still make the wrong choice sometimes, and I always think of Simon and wish I had his magic touch.
Even if he used to name functions Thing() and DoStuff() and forget to update them.
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.
The first startup I worked at was in typography. Writing a full typographic rendering engine in webGL shaders is going to result in code that is difficult for others not experienced in webGL and typography.
It’s inherently (and likely irreducibly) difficult, not accidentally/gratuitously difficult.
It’s a bad thing if you make a simple thing more complicated than it needs to be.
But there are plenty of Hard Problems out there, for which no sufficient code could be called “simple.” Plenty of aspects of font rendering fall within this bucket. It’s notoriously difficult.
That's what I was thinking, but then, it is very specialized and high performance code well outside of my domains (font rendering, shaders, C++, high performance / frequently called code is very much not my bread and butter). I frequently glaze over whenever trying to read a post about some optimization problem. Fast inverse square root [0] is succinct and cleanly written even though it uses math symbols instead of variable names, but I have no idea how it works and don't have the math basics to even know when / where / why to use it.
[0] https://en.wikipedia.org/wiki/Fast_inverse_square_root
Usually it is dangerous to let such people write application level code, but according to the reports in the comments, the guy might be one of the few exceptions, who gets the low level right, but also created flexible extensible structure of code in other places, without it becoming obscure on the application level.
Usually when I see some mathematical code that's not explained at all and has obvious flaws in terms of simple improvements that could be made to improve readability or even something as simple as some comments, I just keep thinking: "Please don't let this person touch application level code!"
As others have pointed out: if the complexity is in the domain then that's perfectly acceptable. I always remember reading some lines of code in Linux that had a comment above them: "This code is meant to be read by a CPU, not by a human."
The hard part is knowing when the code is complex because the domain/performance requirements demand it be that way vs when the code is complex because the engineer was just trying to appear smarter than they are.
Computer typography is a dark art. It requires understanding a whole domain with its own terminology and traditions as well as aesthetic sense, then combine that with the programming knowledge.
Exactly, I had the same issue when I was younger. I thought if I read code I could not understand was because the other dev was a legend. Now its the opposite, I am amazed by code that does its job well, its understandable and has low complexity.
> 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.
yikes
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 reason to write code is to solve a problem. If the problem domain is complex, then the code to solve said problem will be inherently complex. He solved a problem.
Font rendering code is a nightmare because the problem is really damn hard. Font files are complex, and actual real world usage is even worse.
Any code that involves parsing old school binary file formats is going to look ugly to modern day developers who are used to JSON everything, even if the code is actually very well structured.
Even well-written code can be hard to understand -- practically impossible, even -- if what it's doing is sufficiently complex. Cryptography and certain areas of graphics have humbled me, for instance. I followed the flow, and I appreciated the comments, but I did not understand.
Any specific lines you can point to as examples in an open source repo?
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.
IIRC a few folks from Mapbox joined Figma years ago. They probably know their way around font rendering in WebGL (unsigned distance fields et al.).
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.
Wait, so no one asked Evan to explain the code? Something smells fishy.
Do you think AI could take a crack at understanding it for you?
Wouldn't know until we try it; I have a suspicion AI would struggle with "rare" code snippets though, given there's not much online like it.
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.
I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient.
Code that doesn't need to change is a really good sign that you've got something good.
That's... not a screaming testimony, dude.
> A true 100x-er
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.
It's incredibly snappy. It works fine on subpar hardware like a late 2013 11" MacBook Air. Truly amazing.
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".
> Hasn't he all but washed his hands of Figma?
Great. What's the point of achieving great things with hard work if one is still stuck working with same product for life.
> I have a hard time being interested in something that has such a painful..
Thats okay. One can always use products that are reasonable to their expense budget. Not every product is to be used by every one.
> The rendering engine handles curve rendering, images, blurs, masking, blending, and opacity groups, and optimizes for high visual fidelity.
And thats how you get designers whining that their design looks great in figma but not in a real webpage
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.
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...
> Maybe the real webpage also needs a better stack
I'll call Google and I'm sure they'll get right on aligning their browser's rendering engine with figma's
Is this alignment the issue with your application? Are there design alternatives that would be impacted less by some rendering engine differences?
What about other browsers? Versions? Platforms? OS? Resolution/screen size? My huge frontend team can't handle this, even before we used Figma.
Isn't the problem trying to get this "web platform" do something it was never meant to do? How would this be solved by Figma using a rendering engine that would grind their product to a halt?
I'm old enough to have done a lot of native platform UI work, the web stack in many ways was a step backwards. It has obviously a lot of advantages (run anywhere) but in some ways it's more like IBM terminals on a mainframe vs. a native UI where you have full control. I (obviously) use and make web apps all the time, but they often suck, and this isn't Figma's fault.
I've been fighting the way figma interprets fonts for years. It's not too bad at my current company, but at my last company things would look great in figma but with the exact same styles applied they'd be wrong in every browser. That's the sort of thing people are complaining about here.
I'm sure there's something fundamentally wrong with the font files. In both cases, they're not standard, widely available fonts. With that said, browsers render the fonts consistently with each other, but not Figma.
There's also a lot of ways that figma can lead designers down the unhappy path. They'll put together two different screens that look great, wave their hands around the idea of "just make it responsive" and when you go in and look, there's nonsensical crap like absolute positioning on elements, or arrangements that don't work with block layouts and force you into convoluted grid stuff.
Figma is clearly built to be useful for web development. It has tons of gaps that lead designers off the happy path. Take out all the "browsers / versions / os / screen size" differences from the argument; my points above would apply to any design tool built for any product. If it doesn't accurately reflect what is possible or how something is done, it's not a perfect fit.
PS: I prefer figma over pretty much every other tool I've used. With that said, there's no pretending that it is perfect, nor any reason to deflect accurate criticism elsewhere.
My solution in these cases was to build prototype sites that sync in real time from the figma file. So the designer can see how their work actually looks, and treat the figma view as just a low fidelity preview.
Could you point to any resources on how to achieve this? At work we're increasing our Figma usage, and this approach sounds like something better implemented sooner than later
Here's a tool I made.
https://github.com/stamen/figmasset
Stamen! One of the OGs at this point.
This is the way to go. Designers should sign off on products, not mockups.
In my experience that's rarely due to low-level rendering differences, and almost always due to the Figma design not accommodating real-world data.
This, so much this.
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.
Don't quite follow you, but if you're talking about a box-based layout for the web, that's a little overly simplistic as "the" layout, but is already possible. Keep in mind the historical underpinings; web documents were always more like scrolls than screens.
Not a layout, but a design tool like Figma, leveraging the default flow of elements.
Something like Webflow then?
Not really, I’m not thinking to replace CMS builders like Wix or Squarespace either.
More like ”no-code design directly in HTML and CSS”, but with familiar Figma/Sketch-line controls for sizing, alignment, etc. Responsive by default, boxes full-width and vertically sized by content by default, manual pixel sizing of elements heavily discouraged in favor of block/inline-block/inline. Sane defaults for theme tokens, but easily customizable.
In other words, a hands-on design tool for web layouts, working directly on the DOM and stylesheet, preferring the flow for positioning and leveraging (normalized) HTML/CSS defaults.
My thinking is mostly born out of frustration with the performance of flexbox-inside-flexbox layouts and the total disparity of text layout between web and existing design tools.
See https://every-layout.dev for a mind-blowingly well-thought-out approach to CSS that builds from first principles and leverages sane primitives and a typographic scale to compose dynamic layouts... it's boxes, and it's beautiful.
> See https://every-layout.dev for a mind-blowingly well-thought-out approach to CSS
Is the book that good?
Now if it only was a design tool like Figma.
Huh?
Designers complaining that their pixel perfect mockup in any software not aligning with layout in actual browsers is a literal decades old complaint.
So? Before Sketch/Figma got popular, designers had been literally passing .psd files as design specs around for a decade.
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].
[1] https://github.com/evanw/esbuild [2] https://github.com/microsoft/typescript-go
I think you're confusing esbuild with ESLint. ESLint was created by Nicholas C Zakas.
Fixed it, thanks for noticing.
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.
They're about to get upstaged by AI too.
Not because they can't be leaders in the space, but because there won't be any moat.
Thanks for sharing - this architecture post is also a great read: https://madebyevan.com/figma/building-a-professional-design-...:
> 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.
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).
We've added that link to the text at the top. Thanks!
Evanw is the 100x developer
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.
I'm curious what the missing features are in Figma from a designers perspective. You've mentioned the paywalled variables, what else? (I haven't been a product engineer in years, and have barely touched Figma in the last ~5 years)
- Clunky component and variable system; inadequate for more complex stuff with lots of parameters.
- Can't set connectors on Design files (used for documenting the navigation flow between different pages of an app).
- You can set connectors on FigJam files, but if you want to bring your components from Design files then you can't keep the instances synchronised to the component definition. And you can't attach the connector endpoint to some element inside the Design component. It's essentially just an image export of the Design component.
- Prototyping is very clunky and trying to build a flow that has elements reacting to interactions on other distinct elements is either variable hell or downright impossible.
Those are just off the top of my mind. I'm always finding threads from 5 years ago on their community forums with loads of people on the same boat and no activity from Figma side.
Adding:
- Poor typography support: can't embed fonts in files, can't tweak type enough (can't do faux italics for example)
- Subpar file/project management: can't do things like nested folders which gets overwhelming with large projects/teams
- Clunky version control: browsing long file histories is inefficient, the entire VCS UI is forced into a narrow sidebar
Also just off the top of my mind. There's also lots more if you're coming from a print design world and are thus used to Adobe Illustrator.
> There's also lots more if you're coming from a print design world
Ah, there's another one you just reminded me:
- Poor paragraph justification algorithm; there's no hyphenation system.
This one is table stakes for professional print design.
> Figma just has to jack up the price in order to appease Wall Street quarterly
Aren't designers mad at Adobe for doing exactly this?
Yup, Figma is likely to become the next Adobe. Shareholders are vastly more important than consumers as we all sadly know.
Yes. Now you can offer something similiar for less than $55 per seat per month, then to quote Bezos: “your margin is my opportunity”.
> team eventually settled on ... React
How the legends have fallen
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.
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.
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).
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?
That sounds awful and after your comment, I'm glad I've stuck with Sketch.
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.
This is tale as old as time honestly.
Create a product sell or IPO. Revenue pressure increases. Product cost is increased or staff is cut. New software takes crown. Rinse and repeat.
It seems so risk adverse right? I couldnt imagine telling my team to explore a new way to design as a result of the coming IPO
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!
Is this an uncommon use case?
> 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.
> 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.
This, “permissions, etc”, isn't just an enterprise-scale problem, any multi-tenant system can and probably will hit it.
Working out who can access what can sound simple enough, but it gets rather less pleasant when the rules can be set with more complex ACLs¹ and because people can move around dynamically it is both potentially resource heavy to derive and difficult to cache² both safely and³ efficiently. It is natural to think “well, we can simplify the permissions model”, but you really can't when selling to different enterprises: many have their own idiosyncratic workflows, or local tweaks if using an “industry standard” workflow, and they will make a noise if your software to support them without extra tricks on their part.
We are at a much smaller scale⁴, in another industry, but this is an issue we have to be very careful about.
--------
[1] Is this person in a given group? Does that give or remove permission? Can they just access, or edit, add, …? also: different elements on the same screen could have very different ACLs to each other and at different times in a process
[2] missing changes for a time could cause significant issues if users are working on something commercially important or otherwise sensitive
[3] Safe is easy: don't cache at all. Efficient is easy: don't care about a bit of staleness and accept a bit of “eventual consistency”/“eventual correctness”. Achieving both takes a pile of resource even with a great design.
[4] We don't have to worry about consistently spreading data and processing over a set of DCs as our product has natural borders between tenants so splitting off into distinct DBs⁵ is an easy answer to some of the scale & efficiency issues.
[5] rather than needing everything in on “public” system because anyone can potentially want to share access with any other user.
Nvidia GPUs/Aws ai offerings?
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.
And yet they still have a ~90% gross margin -- honestly not too shabby!
Figma earns more profit for AWS than it could earn for itself firing everyone.
There's a president-for-life clause:
"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)
There are certainly downsides to it, but you’ll notice that most of the biggest companies of the last 20 years had a dual class stock structure that gives the founders a high level of control.
The most efficient government is a benevolent dictatorship, the problem, of course is that benevolent dictators don’t live forever and sooner or later you get a non-benevolent one.
These sorts of dual class share structures avoid that issue by generally becoming common stock on transfer so it turns into a democracy with the end of the dictator.
With an IPO you at least got to spend several years seeing how the dictator did.
It's actually a crime in the US not to manage a public company in the interest of the shareholders. (There was a large case which Ford lost establishing the way this is interpreted now which many people argue is why it gets interpreted in such a shortsighted way so often although personally I'm not sure.)
It makes sense, you're disposing of the capital the shareholders own.
No, it isn't a crime.
Dodge v. Ford Motor Co. was a civil case, not a criminal case. And it was in the Michigan Supreme Court so has no standing in the other 49 states.
And in practice the "business judgement rule" makes it very easy for businesses to do whatever they want as long as they have a vaguely plausible explanation for how it helps the business as a whole. ("We need to buy a private jet for our CEO because he is integral to our growth and success.")
SEC and most states like delaware where companies incorporate do have minority shareholder protections, regardless of these terms.
A board of directors can screw shareholders even without one controlling director.
The protections for minority shareholder are seperate.
Also the news of malpractice by directors like you mention leads to SEC investigations and stocks come crashing down before they can sell it (as they must declare their stock sales a few days before doing it)
Given cases like Elon moving to less protective jursidictions, those protections are not necessarily as protective as you might prefer, especially if you sign them away at some point in the past.
It's going to be a lot harder to protect your rights, especially around the margins, if you agree to terms like the above.
The alternative is enshittification of the entire product lineup to include ads, exorbitant subscription prices, reduced functionality along a painful price gradient, morphing into a dopamine social product, or a goal to rent real-life assets for to an increasingly impoverished population. Pee in your piss bottle while delivering that Amazon package until we can figure out how to automate your job away too. The shareholders demand it!
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.
It’s not really punishment if you don’t care what your share price is. A lower share price doesn’t hurt a company unless perhaps they are trying to do a secondary offering or something.
It does, however, hurt the Wall Street investors. If they have enough power to do so, they will replace the CEO if a share price is too low for too long.
That’s what creates the short term incentive that is a trouble and a lot of public companies. If the CEO has control of the voting shares, that pressure is relieved.
This is what they call "a W"
From the adobe disaster to this. I am glad Adobe didn’t snuff them out. Cheers and congrats to … fig-mates? : )
They did collect a $1B kill fee.
Let's hope it's not the start of enshittification.
Headline financials:
What happened in 2024 that caused their operating expenses to increase so much?
Mostly a 356% increase in R&D:
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: If you subtract the one-time charge, you get:How'd you manage to summarize these figures so nicely ? Are you good at accounting stuff or are you using some AI tool ?
Manual labor, going back to before LLMs were a thing. I just like reading S-1s.
https://news.ycombinator.com/item?id=27701617#27702669
https://news.ycombinator.com/item?id=26362443#26363190
https://news.ycombinator.com/item?id=25143334#25143800
In May 2024, they removed some of the vesting conditions on RSUs so employees could sell shares in a secondary offering.
From an accounting perspective, it was an $800 million stock-based compensation expense, though it didn't really cost Figma anything.
They received a $1B termination fee in 2023 when their acquisition by Adobe collapsed. They would be losing money in 2023 otherwise
If they were planning to IPO, they will have put in place a strategy to maximise the numbers for the year prior.
So the numbers for the year before IPO may have no relation to future.
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.
Congrats to the team here. Let it be a lesson for anyone worried that “their idea has been taken” or “there already solutions for this” out there.
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.
Except it was not a crowded space. They did a bunch of stuff no one else was (or is) doing right from the start. Being entirely in the browser, real-time collaboration, vector networks…
You can define any space as "not crowded" if you narrow it down enough. That was the point really, they entered a crowded space & re-defined it with their offering.
> You can define any space as "not crowded" if you narrow it down enough.
I mean, you’re technically correct¹ but that’s not exactly helpful because the inverse is also true: You can define any space as “crowded” if you widen it enough.
That is to say it is perfectly plausible I am wrong and the space was crowded, but that argument doesn’t really prove or disprove it.
> That was the point really, they entered a crowded space & re-defined it with their offering.
Especially if you allow someone in the space to redefine it. At that point all bets are off and anyone can claim anything.
¹ The best kind of correct: https://www.youtube.com/watch?v=hou0lU8WMgo
You are confusing technology for product.
The product space they entered, UX design tooling, was very crowded. Sketch and InVision were the kings and there were a dozen other reasonable options to choose from (including ones in browser with real time collab and other interesting tech).
Figma entered that market later and won on a combination of technology and product innovation aka execution.
But they absolutely entered a crowded market.
> 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.
That's such an unfair, pessimistic, and "economics-free" take. The giant enterprises with "huge contracts" as you point out are not "victims" - it's not like they're hapless newbies who don't know how enterprise contracts work. Especially in the case of Figma, where there are loads of competitive products (which was the point of the comment I was responding to), clients have plenty of other options. They chose and continue to choose Figma because they believe it gives them value over other possibilities.
I'm pretty sure almost nothing involved in building a multi billion dollar business is generalizable to even .01% of other things
Actually, that's a fair point! Thanks for making it :)
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…
Reminds me of the Linear story. You can disrupt a set of established players by focusing on simplicity, opinionated design, and maximum performance via hardcore engineering.
Don't forget how Figma bullied Loveable from being able to use "dev mode" [1].
[1] https://techcrunch.com/2025/04/15/figma-sent-a-cease-and-des...
Don't forget how Loveable used the moment as an acquisition tactic, which was probably the whole point.
That’s how trademark works. You lose it if you have it and don’t protect it.
I think the point the parent comment is making is that companies shouldn't be able to trademark common phrases with their usual spelling. 'Dev mode' is a common short form for 'developer mode' which has extensive use.
I wrote a little about it, because it's more complicated than "a trademark": https://jonatron.github.io/randomstuff/trademark/fig.html
A bit off-topic, but I really wish we had a system where we could make bets to pit public companies that develop closed source software against its FOSS alternatives.
In the example here: people would bet by either buying $100 worth of Figma shares, or they could buy $50 worth of put options and give $50 to the developers of Penpot.
Would something like that be legal or does it violate any type of trading regulations?
Don't we have that system? Post IPO you can absolutely buy puts on FIG while donating to Penpot.
(I do not recommend this)
Doing that as separate actions are of course possible. My idea is to have a system to let people do this and track the results in a single place.
But people can already buy $100 of Figma shares (upon its IPO). Why would people who want to buy Figma share use your hypothetical platform?
My idea is more about a system that can track and mediate support for the pro-FOSS than anything. For the pro-commercial side of the bet, showing ownership of the shares would be enough I guess.
it’s only illegal if you start beating the rich
I would love to be a reverse—VC
This is one of the many things where I have a good chunk of the backend code already written but couldn't find the time or urgency to work on an MVP.
Should I make a mock system, see how many people would be willing to sign up and make a pledge to their favorite projects?
I see this play out a lot in my country’s stock market. Where numbers are fine and all hunky dory. But in reality all increase in share prices — those meteoric rises has already happened behind the curtain which separates it from the public (and for good). And then IPO comes and the public mostly oays for the final exit.
Is this an IPO where participants (public) will make long term money of it’s already at the top and this is the final stage of “finding someone to hold the bag” and in this case eventually — the public i.e the retail trader, mostly?
More and more companies are now holding bitcoin in their treasuries (including Figma according to the filling). It's interesting, but it makes a lot of sense.
Why does it make sense? When the price is so volatile.
If the companies are so confident of their trading ability then they should stop their existing business and become trading companies.
It's pretty weird that a lot of the business leadership in tech is earnestly invested in a recreation of the free banking era actually.
Figma is an incredible product but I don’t like what they’re doing with AI. They should focus on enabling UI/UX designers to do more instead of making a glorified Dreamweaver.
So, this is a cash out before AI or AI-first solutions out do Figma?
Seriously, are people starting to replace Figma with just basic LLM or simpler LLM-based solutions? I'm just trying to understand the timing of the IPO and the market. We used to use Figma, but dropped it as first phases of product design loop ended. Basic LLM does not feel there yet, but it does feel like it could be there very quickly.
Looks like I got access to it riiiiiiiight as they're gonna start gutting themselves to pay for retirement and pension funds. Awesome!
Congrats Figma! It annoys me every time I open their UI, billions of dollars in revenue for a web design tool, yet still no way to export tokens natively as CSS.
https://www.sec.gov/Archives/edgar/data/1579878/000162828025...
I read that as though new companies filing IPO should use files created with Figma.
It's funny its performance is touted as its biggest selling point, I find it to be painfully slow
Compared to what?
Figma has come a long way, from a blocked Adobe acquisition to now filing for an IPO.
Going public is usually terrible news for users.
That said, today it's an incredibly good design tool - worth checking out before shareholders start the enshittification process. Congrats to the devs / founders for making it all the way to an IPO!
When they go IPO, will you guys buy it immediately, expecting it to go up? Curious what people think about the figma's future.
Point of view as a Figma user...
With all the AI tools, the market is in a transition period.
Those transitions are crucial for a product's success or failure. For example, the transition from web to mobile with the iPhone, along with the growing pains of using Photoshop and Illustrator for mockups, opened the door to Sketch. Then, the evolution of web apps, like Google Docs, opened the door to Figma (while other products like InVision had a drastic fall). What they accomplished in a web app is an impressive engineering feat, so they have an excellent engineering team.
The good: Figma is implementing multiple product updates to capitalize on the "AI wave". The Figma Make in beta is very similar to Vercel's v0 (and others). Still, the tight integration with Figma could help them leverage their current subscriptions and attract designers, PMs, and developers. Recently, they released an MCP server in beta that enables AI coding tools to obtain information from designs. While many designers may disagree with me, I believe that at least they are trying to maintain a leading position in a rapidly shifting market.
The bad: They are diversifying their product offering too much, trying to compete on many fronts. Figma Site competes with Framer and Webflow, and Figma Buzz aims at digital marketing, which is usually covered by many tools (including Canva). Figma Slides is ideal for designers who use Figma daily, but it may not be as user-friendly for those transitioning from PowerPoint or Keynote. They switched the focus from the Design->Dev process that made them successful. The dev mode still doesn't resolve many issues, such as versioning, and the variable features seem half-baked; component handling needs more love, and the prototyping options are still limited.
The future... is hard to tell. In terms of UI design tools, they are the leaders. Penpot is far from being stable; Sketch is similar, but their web experience is not as good as Figma. Unless a new player enters the market, their biggest threat is a significant disruption caused by AI tools... but the tools I've seen so far are not different from Figma Make.
[flagged]
Beyond Penpot and Excalidraw, check out Sketch (Mac-only but mature), Lunacy (offline-capable), and Plasmic (code-focused) - all with different trade-offs but less pressure to monetize aggressively.
Figma's enshittification started back when there were talks of Adobe taking over, it's already bloated beyond reason.
Their new "AI" feature is a bolted-on POS.
But Figma itself is excellent at what it does.
I find it kind of ridiculous that I need dev mode to get some values that they expose outside of dev mode but in a less dev friendly way. I know there's more to it, but come on...
Maybe this will finally cause designers to ditch Figma. It's a fantastic tool for designers, but it's complete shit for developers.
What Figma did in this era of anticompetitive buyouts is admirable but my mind will always think figma balls even after they IPO freely.
Anyway, congratulations to everyone at Figma and good luck.
Very predictable outcome: [0] [1]
Now prepare for price increases, lock-ins and many threads of people looking for Figma alternatives.
The ones cheering already have stock ready to dump it on the public markets on retail.
[0] https://news.ycombinator.com/item?id=36533826
[1] https://news.ycombinator.com/item?id=34920968
So now that Figma will be owned by Wall Street, it will only get considerably worse from here. It is now time consider and find and fund open source alternatives.
I know of excalidraw and perhaps penpot are there anymore?
I agree. If they’re so profitable already, why take the company public at all?
Because there are likely many employees and investors who want to cash out.
Going public makes their shares liquid. It's (probably) not reasonable for the company to repurchase that equity or to pay employees pure cash comp.
to be a lot more profitable
And how would that happen? They already have the product, which can be sold in huge numbers without really needing to scale operations. Are you suggesting they need cash to rewrite or improve the product?
At my company we use Miro a ton. It doesn't have the design tools, just the white boarding and diagramming, so its Figma counterpart is FigJam. But the realtime collaboration features are just as good, and sometimes better. They have a decent desktop Electron app that wraps it, too.
And the cycle continues. Who's working on the "Figma but not enshittified" at the moment?
Penpot is the most solid alternative I know of at the moment.
With the biggest differentiator being that in Penpot, everything is a SVG/Open Standards, which for us web folks is a neat addition. Also developed by a local company in Spain, go Spain! And for the nerds, it's open source and built using ClojureScript :)
And can be self hosted which is a massive plus!
Honestly the cycle continuing is a breath of fresh air relative to the AI-ification of our entire industry.
Its S-1 shows $70M held in Bitcoin ETFs, and board approval for another $30M BTC purchase via USDC!
https://x.com/tier10k/status/1940133141546770454
Oh, so that’s why they’re taking it public: they are turning the company into a crypto investment fund which just happens to provide a SaaS design tool.
It’s the other way around, they bought some bitcoin because they are going public for the meme stock value.
Thats pretty weird, you’d think they would offload things like that to not spook investors
> they would offload things like that to not spook investors
Judging by the amount of fairly traditional companies holding Bitcoins, it would seem like holding Bitcoin is no longer spooky. I guess it makes sense when the financial environment is slowly turning into one without any regulations, Bitcoin will thrive in that sort of market.
It says more about Bitcoin than it does Figma.
So much negativity in this thread. I thought we’d be able to celebrate this one. Figma provided an alternative to the evil Adobe empire that was actually better. It’s powered by some amazing tech built originally by one of the founders. It’s still got a generous free plan. I’m happy the employees will get to cash out.
> I thought we’d be able to celebrate this one.
I mean yeah, it's cool and all that the employees and owners get a pay out, but IPOs are generally bad news for users, and I'm sure I'm not the only Figma user here, so makes sense that people are cautious about something that is usually bad news for them.
> Figma provided an alternative to the evil Adobe empire that was actually better
That's the crux, because generally IPOs mean that they'll now slowly turn into whatever it was they were supposed to fix. Maybe Figma will be the 1-in-a-billion products that won't suffer that fate, but it's understandable that people are now starting to casually look for alternatives, given most people's experience with IPOs.
[flagged]
I disagree, many companies are still great even after going public in the last decade:
Shopify, Cloudflare, Zoom, Spotify, Roblox, and Coinbase are all notable examples.
"Great" for the majority of these is a stretch. There's no shortage of complaints about how Spotify treats both artists and customers, and Roblox enjoys yearly controversies from how it provides access to and exploits its customer base of children.
I use Zoom and Spotify and both of those have gone downhill dramatically. Spotify to the extend that I really don't use it anymore.
Of those I only use Spotify and it pesters me at all hours of the day.
Bruh, Spotify has been absolutely shit, and their practices and push towards AI and completely unusuable suggestions algorithm are making it more and more shit.
I take uber every day and haven't found it to be "enshittified" (outside of some ads appearing in the app now).
It's not a big deal but the cars allowed on Uber has worsened. I remember trying to sign up as a driver a few years ago with a 2009 Corolla and being denied because the car was too old and now see cars from then allowed today. Maybe that's the cost of scaling but I find it worse. Also no more Uber pool.
I like Uber but I was surprised at how bad their mapping is - they get the route to get me home wrong and I've gone through the process of telling them about the mistake in their maps and they just seemed to ignore me.
The enshittification is definitely happening on the driver-side with wordened working conditions and pay.
It started off enshittified
I like Figma. My disappointment is that I know it's a transient tool. I grew up learning Photoshop, a tool which I now never use because it is expensive and neutered. And Sony Vegas, which is also expensive and pointless when free alternatives do the same thing. And now I can add Figma to the list of tools I learned but will likely never touch for even a free project. Which makes me sad! I like it.
This business model isn't sustainable for individuals, so they're going to naturally be upset. If the B2B market is more lucrative for Figma then they have every right to optimize for it, but they're going to pay the cost in user goodwill. Many startups go through this process.
[flagged]
If you’re tired of it all, and the inevitable, and you have agency, try penpot.app
Also Sketch [1]. Everyone abandoned it when Figma became the pOpUlAr tool, but I still use it every day, nearly 15 years later and it's continued to improve.
[1] https://sketch.com
I never switched away from Sketch for personal use. Figma’s collab tools are great, but I find it somewhat clunky for usage beyond prototyping (such as creating image assets).
Figma’s cloud-first nature never also sat well with me… I still have the source PSD files for my earliest works from 25 years ago, which can still be viewed and edited perfectly. Will that be true of my Figma documents in 25 years? It’s not even a question with Sketch.
Still the default for most teams at Apple AFAIK
[dead]
[dead]
[dead]
[flagged]
[flagged]
Yes and I thought "eat your own dog food, good idea" even if Figma is a nightmare for me to use at work.