Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Won't work. It's a cool proof of concept, but practically, 0% chance of it being really useful.

Converting figma layouts to code is fairly trivial. Converting it to code that's usable is a whole other story. There's the actual design related concerns such as nested layouts and dynamic behavior, as well as code base management concerns.

At best this is a possibility for some tools like webflow, or framer. With figma, there's no chance given how they would have to re-implement to get actual feature-parity with actual target platforms.

Disclaimer: I am in this space and basically building what we're talking about. All these people saying that this is the future of figma are out of their goddamned minds. Figma already has css exports, and maybe they'll get design tokens. More than that? It would be a completely different product and kind of insane to try. The focus and clarity that figma has is underrated. People think that just because it's all about web dev, these are all the same tools, but they're not.



Do you potentially see a middle ground where you could export reliably optimizeable assets like CSS and design tokens, and then instead of trying to export a perfect representation of the design, you could export a high-level scaffold that would at least get the developers started, perhaps by laying out named - but not implemented - components (ideally following a predefined architecture template).

Code frameworks have long found success with this scaffolding approach, where you can provide structural hints/direction to the average intermediate/junior developer who can handle the component-by-component implementation but might need a hand with broader architecture decisions.

Most large enterprises I've seen are full of exactly these kinds of devs who are primarily tasked with component/page-level implementation, but if you leave them to make decisions about how to separate and lay out components, you get a lot of inconsistency across your teams, even when the designs are consistent.

This would be a valuable problem to solve that I haven't seen talked about much.


Interesting

I hear what you're saying about nested layouts and dynamic behaviour but do you think this would be good for individual components (even if these are large components such as page layouts?)


No, because components implies inputs (props), and things like conditional rendering, or slots (props.children), or even life cycle hooks. You'd have to make code style decisions like what kind of code style to use (functional vs class in react e.g.).

Even if somebody did do all of this, merging the file from the app into a real project would be difficult. There'd have to be rules about merging, and diffing, and command line tools, etc. Maintaining and documenting all of this would be an absolute nightmare. And that's not even getting into engineering or marketing difficulties because you'll have people confused about the product identity, or say that it's too complex, or that it's buggy because it has so many more features now. And all this for pretty much nothing.

Because figma already has css exports (even if it's iffy, they're working on it). You export the styles, the padding, the colors, and that's what people really want to get from their figma files. So you get most of the way there for a much, much smaller fraction of effort.


Agreed with this, the tooling for pumping out presentational only components is already there.


Is the output suitable enough for a decent UX testing prototype?


I swear I don't work for Framer, but I've been using it very intensively for UX testing and users aren't capable of differentiating the prototypes from the actual real thing:

https://www.framer.com/user-testing/

The prototypes can be heavy on the browser, but once you go past that the immersion level is deep. You can even add custom google analytics events for quant analysis.


Thanks for this, I'll keep this in mind.


Another concern is accessibility. How accessible would the generated components be with a screen reader




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: