Why not generate React code from Figma? (a.k.a. why did PageDraw YC18 fail?)

10 points by robertnowell 4 years ago | 15 comments

I've been a little obsessed recently with why PageDraw failed (https://news.ycombinator.com/item?id=16467387). Pagedraw promised to generate react code from sketch or figma designs.

It would make my life much easier if they had succeeded. In that world, when my cofounder and I finish polishing our designs in figma, we click a button and (most of) the React UI code is written for us. All we would have to do is wire up the generated components to data sources, and voila. Take the rest of the day off.

If it had worked well, it could automate a good amount of the boring UI work I need to do on a consistent basis. Why am I still manually writing styled components when the information is all there in figma already?

What do you think, HN?

Curious if anyone knows of great solutions for this problem or thinks that something like this should (or shouldn't / couldn't) exist.

What do folks think of Anima? https://www.animaapp.com/blog/design-to-code/how-to-export-figma-to-react/

Or Overlay? https://www.overlay-tech.com/

Figma's own blog post on this: https://www.figma.com/blog/introducing-figma-to-react/

A reddit discussion: https://www.reddit.com/r/FigmaDesign/comments/ht9krs/best_way_to_convert_designs_from_figma_to_react/

Is anyone else working on this?

Jefro118 4 years ago |

I'm working on this with https://pygma.app. I was too quite surprised that no one has done a better job of this yet. One obvious issue is that Figma works in absolute positions and this is generally a bad way of writing CSS, but this is mostly overcome with some simple heuristics. At the moment my product is more like Overlay, which produces code that is visually consistent but often not semantic or what the designer would have intended. I think this can largely be solved with machine learning, computer vision in particular. Uizard seems like the most impressive product in this regard but their use case is slightly different.

Another problem is that most product teams don't just need to generate code once but also keep it in sync with Figma. As far as I can tell, no one has solved the syncing problem in either direction particularly well. I actually think syncing from React -> Figma is not fundamentally difficult but you need to build a big hairy compiler to deal with any React + styling code which would be a PITA. Going in the other direction is more fundamentally difficult I think, probably needs very good machine learning as well.

Also, always love to hear more details about precisely what's so painful and boring about the way you deal with it now?

robertnowell 4 years ago | |

Cool to hear about this

jokethrowaway 4 years ago |

This is painfully visible in big web agencies with tons of clients.

The flow of designs to be turned into code is relentless, it's almost like a factory.

The reason this doesn't get solved is that you'll always need a developer to smooth the edges, making it responsive, check things work properly everywhere.

There is just too much cruft in the web for full proper automation and there are plenty of frontend developers who barely know how to code but knows how to write React component at a relatively low price.

For individual product companies the effort to create something like this would be too big. Adopting an emergent third party solution instead of throwing frontenders at the problem would be a risky proposition.

Agencies would be the perfect candidate for buying something like this but the cost of developers can easily be passed down to the customer - and if they're big enough to have a lot of clients, they make money because of their brand, not because they're particularly cheap.

I don't think we'll see a solution to this before General Artificial Intelligence; the incentives for building a custom solution for this problem are low and the cost is relatively high.

Maybe if the web as we know were to become simpler / standardised (imagine having native views with native components configured by web services, instead of the wild west of an html page) this could become doable.

robertnowell 4 years ago | |

Interesting, do you have experience with web agency work? I've never thought about the challenges they face, but they must face this challenge all the time

jokethrowaway 4 years ago | | |

Yes, I worked with some of them and I have close friends running them.

They definitely have this problem all the time.

Imagine having n PM from big brands who need to build some websites / landing pages and don't want to commit their own development resources (either they don't have them, or they do).

Agencies generally have internal project managers to match the clients and extract requirements.

A common pattern is to have some developers and designers on the payroll (but the pay is not great, it's hard to get good talent) and a few contractors you worked with on the side for more exotic projects (eg. if a client wants a 3d website).

The designers come up with the designs. Sometimes the client will have their own design.

Often times the design + some notes on the side can replace a standard requirements documents.

After that the designs are sent to the developers who convert it into code and deploy, usually with some sort of CMS (WordPress is still pretty popular, Django as well).

The project gets demoed and adjustments / bugfixing starts.

Etheryte 4 years ago |

There have been attempts at tools like this more or less as long as I can remember. The earliest one I recall seeing was Adobe Photoshop exporting sliced designs, but I'm sure there were similar takes earlier too. There are two main issues that are more or less universal: generating reasonable code, and drawing the rest of the owl. The first part does not need much explanation, teaching a machine to generate reasonable code that's understandably structured is akin to teaching a machine to program in general. Context is hard and the output of such programs is generally a big mess. The second problem is drawing the rest of the owl [0]. Wiring up a frontend to a backend is not a trivial task, and one that I would argue to date does not have solid universal solutions. There are many companies and libraries trying to address this in different ways, but they all come with their own pains. Asking a tool to nail down both of the above issues is a very, very tall order and I don't expect anyone to succeed for the general case anytime soon. I do think great progress can be made in narrower scopes though.

[0] https://knowyourmeme.com/memes/how-to-draw-an-owl

robertnowell 4 years ago | |

I appreciate the thoughtful response.

Wiring up a frontend to a backend isn't a trivial task, but is pretty typical software engineering. If part of the work (the ui) could be done for you, wouldn't that be a clear value-add?

Etheryte 4 years ago | | |

Yes and no. For the literal first prototype you get out of the door, yes, having some baseline UI work done for you would be nice. For the sake of the argument, let's assume that the code generated by said tool is at least somewhat reasonably structured so refactoring the code isn't a nightmare either. You wire the UI up to some data and get it out of the door to get some feedback. The problem comes after that initial step — you show the first prototype to some test users or stake holders and figure out what needs to change. Integrating the now changed output of the updated UI with the code you already have will no longer be trivial. So long as the prototype is lean, this will be manageable for some time, but sooner or later it will not. The problem is that for most projects, the initial prototype stage is a very miniscule part of the whole product lifetime. Getting one prototype for cheap can be good, but there are UI prototyping tools that can do this. Using those tools instead of trying to reapply the updated output to your now-existing code base will most likely be less work.

In general I do think that tools in this niche will mature over time, but in my very subjective opinion, they won't be the holy grail of cutting down development time. Most of the time, the hard part of software development is the long haul, not the initial kickoff.

plasmic 4 years ago |

Yeah, we're working on this at Plasmic:

https://www.plasmic.app/

(Our users include ex-PageDraw/Anima users.)

sdrinf 4 years ago |

What I find particularly funny, looking at the big-picture capability of "designer tool generating extendable code", this was basically available since... visual studio 2005? Yet, no one have found a business model for interfacing figma-react reliably at scale.

OTOH, for the capability itself, you might want to look at https://reactstudio.com/ .

quickthrower2 4 years ago | |

The original ASP.NET of 2002ish had drag and drop interface design like VB6! Although the rails MVC model won out, for simple apps it wasn’t a bad way to develop. It had some pains though, by trying to follow desktop so closely it required a large amount of state data flowing up and down from the page.

hcho 4 years ago |

I suspect, genarating components from designs is a pain point for narrow subsection of companies which use React. I also suspect those which have this problem are not in a place to pay. Startups with limited runways, agencies with shoestring budgets are not the most lucrative.

jtchang 4 years ago |

Because the issue is the interactions between the components and not the components themselves.