The CSS Behind Figma | Hacker News Reader

The CSS Behind Figma

ishadeed.com

156 pointsWallyFunk33 comments

Disappointed in the tone of the comments so far. Here's what I took from the article.

The author wasn't saying this was _good_, they were saying it was _interesting_. Professional curiosity and learning how a complex app uses CSS Grid (and Flexbox) at scale.

Indeed, their own conclusion was:

> That’s it for this exploration. I enjoyed looking at such unique and fun usage for both Flexbox and Grid. It’s inspiring to see that in a tool we’ll use, and for me, it inspired me to explore even more use cases for the CSS tools we’ve.

"Exploration", "fun usage", "inspiring". By all means come in with your preconceptions of Figma but nonetheless we should encourage this sort of analysis.

I have no particular love for Figma as a product but I'd guess there aren't many other examples of CSS Grid being used at such scale, as a critical path application for people whose job relies on it, with a relatively low adoption of CSS Grid, particularly to the extent they seem to have used it.

There's virtue Boring Tech, but let's encourage the inverse too.

CSS grid is hard for people to comment on, but their perception of Figma is easy. It's the root of why bike shedding is so commonplace.

> CSS Grid (and Flexbox) at scale.

What does "at scale" mean in this case?

Anyway, CSS could be considered a mess, especially for layout, but given its history, it's quite reasonable. I worked on something where every element had absolute positioning in the browser. That gives excellent control over the layout, but leads to all kinds of other issues. Flex and grid are two easily understood, productive solutions to the general problem, just not 'perfect'.

> What does "at scale" mean in this case?

Maybe it means "automatically" (?). It seems like a bad excuse to have a tool automatically output bad CSS. If the CSS is not as good as written by an expert, then there should be a good reason for this like "theoretically impossible to know what the user wants from available specified info in the tool". Otherwise the tool is not doing such a good job.

There have been tools to output CSS forever. The only question is, whether output is appropriate. If it is a mess then it can only be used for fire-and-forget prototypes.

Sorry, by scale in this context I meant "used by a large number of users". Obviously there's no risk in CSS itself scaling - more that there's risk in using CSS Grid to the degree they have in a way I haven't seen in many web apps.

Nice dissection. I never thought to use grid in this way. Whether I will ever do the same remains to be seen, but it is worth investigating.

The grid usage is pretty weird. It’s essentially using grids to implement an 8px base unit, which can be achieved with less complexity by using css variables. Would make a bit more sense if it used flexible units.

I had the same thought but I don’t think css variables are necessarily better for this use case. It’s simple to position and reposition elements in a grid depending on media queries, and is it any less efficient when rendering than css variables?

Given the hard coded amounts used in the CSS presented in this article (eg 11, 13), they must be using some layout framework that translates their language into proper grid positions so that must be why the grid is used in such a way.

Figma is getting too slow. Open browser tab, get a cup of coffee slow. Love what they did for the space and solutions they unseated, but they are mildly losing their edge.

Are you using Mac? I've seen noticeable performance issue in past few months on my 4 year old Mac Book Pro.

However, it seems to just run on my 9 year old 3570 corei5 windows.

Maybe it’s just because I’ve been using an M1 MacBook Pro but figma absolutely flies for me without any hiccups.

It's time for WASM and Rust. DOM tools can render to their own optimized GPU-accelerated canvas and ditch DOM outright.

Figma already uses WASM and Rust.

> DOM tools can render to their own optimized GPU-accelerated canvas and ditch DOM outright.

This is literally exactly what Figma does.

Furthermore it’s the only very popular app I know of to do that

Google Docs also does that [0].

[0]: http://workspaceupdates.googleblog.com/2021/05/Google-Docs-C...

Lichess, Adobe XD, several Google products. Probably more I’m forgetting.

I'm pretty sure lichess doesn't do that. Even the chess board is done in the DOM.

The big worry I have about this sort of approach is canvas accessibility. It's something the company also seems to be worried about - they put out a statement a couple of months ago about their plans to address accessibility issues going forward - https://www.figma.com/blog/a-step-forward-in-our-accessibili...

It's got everything you miss about table layouts

i'm really not a fan of the spacer example, as it reminds me so much of early 00s layout (in this case, adding a bunch of empty spans/divs to represent the spaces). there's a recent proposal for custom functions in css that i believe would allow one to write a simple iterator for this type of use case (use the nth-of-type element count as a multiplier against a set spacer width).

I used to think the same, my layouts are full of spacer elements now. As long as they are semantically invisible it doesn’t really matter, but the combination of flex vertical/horizontal stacks + default spacers makes creating stuff much faster (and closer to how mobile apps are made).

Though in this case I would likely have a multiplier attribute in a single spacer, not multiple elements.

They are semantically visible. But visually invisible

yah, to me, spacers and extra non-semantic elements smell like a hack, so i try to refactor those out. sometimes you can't do that with the current state of css (which thankfully is now changing, albeit still slowly), but most of the time, it's possible to remove those extraneous elements.

That’s my point, I used to think the same. The thing is, there is no difference from the machine’s perspective, and you’d have to consider every mobile app a “hack” by that measure since this approach is how native UIs are built. You can reap the benefits of faster development and more straightforward code without giving up anything on performance, accessibility, etc.

it's not faster or more straightforward though. you still have to grok and hack it, so might as well grok and hack it cleanly rather than adding superfluous elements (especially considering accessibility, which is a whole espteric can of worms).

Empty divs or spans without any text content can be semantically “invisible”, if done correctly - will not be read by screen readers, will be ignored by any kind of outliner or content parser.

I make extensive use of spacers. A generic flex container, a fixed-width spacer, and a take-what-you-can spacer cover most needs with three simple elements.

but flexbox already has that built in, with space-around or space-between. you also have gap for more regular spacing needs, and margin on the flex items as a last resort.

Figma is great, but i feel its getting abused and the non tech people that use it expect it's as easy to recreate their Figma in other media just as easy. And lately a lot of hacky transactions, which for sure are possible but dont translate to the effort of implementing them as easy as it was in Figma .

Also in rant, not all but many designers have no clue about font licensing's that makes me look like the bad guy explaining we wont pay NNN monthly cuz they like the shape of a 'g' or add another entire font library download.

I agree, it would be nice if the way you design things in Figma more closely resembled how it is implemented in CSS.

I guess that usage of grid is essentially a better way to express a coarser position absolute

Awesome investigation and breakdown.

Reply on news.ycombinator.com