Ask HN: Do you want what I'm making?
I can get carried away with the joy of programming, so I'm forcing myself to take a pause, record a WIP demo video, and ask, does anyone actually want this?
Demo: https://www.youtube.com/watch?v=s2a8r4FIX28
I can get carried away with the joy of programming, so I'm forcing myself to take a pause, record a WIP demo video, and ask, does anyone actually want this?
Demo: https://www.youtube.com/watch?v=s2a8r4FIX28
I've paid designers considerable amounts of money to get them to convert figma designs to webflow sites. I think the need to converting to react is similar. I'll note that the designer that I ended up going back to was the one who converted it in a way that was pixel perfect, and who made sure that some of the things missing from the figma (e.g. the hover state of certain buttons) looked good. What I'm trying to say is that if it can do it 80% well that's nice, and then it's a tool for designers to save time, if it can do it 100% well, then it's a tool for the end buyer and they wouldn't need to hire the person to convert it to react.
See also: https://www.figma.com/community/plugin/862039267149408972/Fi..., https://www.figma.com/blog/introducing-figma-to-react/, https://www.animaapp.com/blog/design-to-code/how-to-export-f... - and note that competition is a good sign, if there was no other approaches to it it probably would mean that it's not something users care about.
Pixel perfect is definitely necessary, and something I can achieve reliably since I'm building the tool from the ground up, not as a plugin on an existing software.
My tool is for designing for "real apps". Designs are exported as components. They can be used in your own codebase as you see fit. For example, a designer for a flight booking website creates a new ticket design. The component is imported and the booking state data is passed to it: <DesignedTicket name={bookingName} departure={departureCode} arrival="LAX" />
[0] https://www.framer.com/learn/how-to-work-with-real-dynamic-d...