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