Ask HN: Why don't you like Figma to code? 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? |
Plasmic is working on solving this problem! The designs you make in Plasmic are architected for continuous iteration. Disclaimer: I work at Plasmic!
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.
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.
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.
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...