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

I'm a designer who used to be a React developer (2 years out of the game though). I don't have a strong opinion about the engineer's choice for how to implement my designs, but if this makes their lives easier and gives us a little extra time to make improvements, I'm all for it.

Call me skeptical, but I wonder how useful it would be for the FE devs on my team. In the past, I've never had a great experience with code generators, I've usually ended up ripping out the results and redoing it myself. Sometimes there's an unexpected limitation ("oh yeah, we use tailwind, this is useless to us!"), or a bug, or sometimes it just doesn't produce something I would stand by.

I'm also a little scared of showing this to other designers, or project managers, because I'd be worried about it setting unrealistic expectations. "Great, there's the front-end problem solved, guess you developers can do about twice as much work in a day now, right?"

This'll generate the kind of code you'd expect to get from a $60 themeforrest template. If you don't care to or never need to dig into it or reuse anything out of context of the prefab template you'll be in an 'OK' place, but anything more than that and you'll likely be not much better of than if you just started from clean.

Those PSD auto export slicers never worked well either.

Same shit, different day.

I think a good parallel of this is Webflow, which I find to be an incredibly powerful tool and gives design teams a lot of freedom to build and deploy their designs, however it’s incredibly cumbersome if you’re using it to mock up options and explore iterations. That work still happens in Sketch for our team, and when it’s approved that same team brings it into Webflow and “does it for real.”

I expect exporting from Sketch/Figma into React components would be cumbersome in this same way.

If I may pose another example from my days of industrial design, Rhino is a great tool for rapidly iterating designs and building CAD for renderings, however when your design is approved you really need to rebuild it in Solidworks for it to be made.

The real solution here is for companies to adopt a Design Ops/Design Systems Manager that can design and code in the front end. This would remove burden from the engineering team so they don’t have to worry about doing tiny design tweaks, etc.

What can you do in Solidworks that does not work in Rhino? Do you have a list of top five points, maybe?

Judging by partlysean’s response, “our industrial design team would use Rhino and then hand it off to the mechanical engineers to rebuild it in Solidworks.” I would think Rhino lacks the entire Computer Aided Engineering (CAE) capabilities that Solidworks has.

The Wikipedia page for Rhino says it’s a CAD tool, but Solidworks says CAD and CAE. So Rhino has a subset of Solidworks’ capabilities.

Engineers use CAE to help with determining how the materials, dimensions, and other engineering choices will be have under loads. So these have some similarities in that Solidworks can also do 3D modeling, which is used as an input to performing CAE.

Different audiences and different use cases.

It’s not necessarily a feature comparison, but I’ve found it much easier to just “try” things in Rhino. Solidworks is best when you already have a clear idea of what you’re building. In that way, our industrial design team would use Rhino and then hand it off to the mechanical engineers to rebuild it in Solidworks.

The way design tools are built – Sketch, Figma, XD... – its an added burden. I believe this is the future for collaboration between front-end & UI designers, but I feel it won't have an easy adoption until its tightly integrated in the designer's workflow.

I've recently made the switch to a similar workflow with Framer just a year ago, the difference here being that devs in my team use & maintain the same components that I use for prototypes/design, so the collaboration aspect is quite seamless: https://github.com/framer/framer-bridge-starter-kit

We had this before: dreamweaver