Ask HN: Why don't you like Figma to code? | Hacker News Reader

Ask HN: Why don't you like Figma to code?

3 pointsizakfr7 comments

It's a common sentiment that Figma to code tools don't work well. What exactly is bad about the code that these tools generate? Is it that the code doesn't look consistent with how'd you write it?

Plugins either seem to either provide too little detail (Figma Dev mode) or feel too bloated (Anima).

Has this been your experience as well? Do you have any alternatives that you've liked?

View on HN

One problem is that the code tool is usually a one-time code export. After the export, you'll probably want to change the code--add some business logic, event handers, etc. After a while, when the Figma design is changed, there's no way to update the presentational code only without redoing the changes.

Plasmic is working on solving this problem! The designs you make in Plasmic are architected for continuous iteration. Disclaimer: I work at Plasmic!

The two-way sync does seem to be another problem with these export tools. Thanks for sharing, I'll take a look!

Note there were expensive and proprietary CASE tools

https://en.wikipedia.org/wiki/Computer-aided_software_engine...

in the 1990s which could often make the same edits a professional programmer would make when you edited a visual representation of the code because these were based on a Concrete Syntax Tree

https://eli.thegreenplace.net/2009/02/16/abstract-vs-concret...

where comments, whitespace, item ordering and all the choices of how to write something are represented. I don't think you could bolt this on to Figma because Figma doesn't have the right representation to keep track of it all.

Graphical editors run into so many little problems like the width of something gets computed to be 13.3333333333px maybe there ought to be a hierarchical "snap to grid" that makes sure is is 13px or 13.3px or 13.33px in the output source code, stuff like that.

Also what exactly is the target? MUI is mentioned in another friend and that's salient to me because I am looking right now at the accessibility of an MUI app: a tool for building applications and theming one single widget set seems like a feasible goal, particularly if it can all be codesigned.

We discussed this ad nauseum at my work a few years back (2019?). We concluded that for the enterprise's designs to truly flow directly from Figma, it would need to be able to export a Material-UI theme (or some similar theme file), so the devs never need to do anything other than just import that theme into their projects.

But it couldn't do that. We talked to folks at Figma who were interested in the concept, but we never pursued it beyond early talks. I haven't kept up to see if they have gotten closer to that goal or not in recent years.

Did you ever investigate if true componentization (like React Server Components, maybe coupled with Storybook etc.) could fill that niche instead?

A MUI theme isn't by itself sufficient, since it really only modifies variables like shared design tokens would.

But it's rare that bespoke components would be 1:1 equivalent with the existing functionality/behaviors of a UI lib (unless that was a design constraint from the get-go, i.e. designers were only allowed to use existing functionality in that lib).

At our work, all components started out with MUI, but would often be extended with custom code based on the designers' needs. I could see no real way to sync that part of it with Figma (which would often just have basic wireframes and prototypes, maybe linked together in screens, hover states, etc., but not really implemented as interactive code).

It's kinda missing a storybook-like layer that can actually use and display different states, inputs, outputs, etc.

We bailed on the effort before we would have gone there. We never even got to test whether the theme would be enough because we could not even get that much of an export in place. We also were an immature organization - large, with lots of funding and devs, but comprised of a collection of acquisitions the VCs had merged together into one company and brand. Which meant we all came to the table with years of history and custom code, and were just trying to find an easy way to apply a common look and feel before delving into whether we could evolve to share a full-blown design system. We did all use MUI so it seemed like a good idea at the time. But it ended being a fairly short effort, with a conclusion of: "No."

Ah, thanks for the details! We were in a similar situation, with teams and codebases cobbled together from acquisitions.

I actually advocated AGAINST a shared component system, predicting (accurately in hindsight) that the immature integration frameworks would not outlive the natural turnover of our teams and products, and would probably become tech debt before it even saw production use. Not a few months later, our entire department was dissolved, many product lines abandoned, etc. Luckily the teams that are still there were able to just keep going instead of wasting time on the doomed standardization effort...

Reply on news.ycombinator.com