[JusticeJuice]

Super interesting.

1. How are you going to get over the layout logic hump? Converting from elements on an x/y canvas to actually good frontend code (Properly nested dom elements, responsive etc) is really hard. I'm pretty sure it's why no 'design to code' tools are actually used in production.

2. Would you consider making this as a figma plugin, as opposed to a seperate tool?

[dabbott]

These are great questions:

1. The way I've been thinking about it now is similar to how I use autolayout in Figma. Simple x/y is convenient for a very first rough draft. Then I'll refine my design by making components and adding autolayout as needed once the project grows or I want to collab with somebody. Similarly, Noya will support putting components in "stacks" and other layouts (some of the built-in components do this already) that translate cleanly to e.g. flexbox. The hump is definitely there, but I think we can make it relatively pain-free. Since code export is configurable on a per-design-system basis, a company can also adjust the code/config export to match what they do in production.

2. We'd definitely be open to it, but it might be difficult/impossible to make it a good UX. We render actual React components from a company's component library in the browser DOM, whereas Figma renders shapes on a webgl canvas. It might be possible to mix and match with Figma widgets in some way, but would probably be janky. Could still be worth trying though!

[JusticeJuice]

Autolayout is definetly a good approach. Webflow is a good commercial example, their builder isn't a canvas experience, it's a nested block experience, so you're forced to think about the layout from the start - and it works. I know of website design agencies who's staff are just designers who can't code - but they build everything they deliver to a clients in webflow.

What webflow doesn't have to deal with compared to a tool for webapps, is that most websites are just static. Web apps have all this extra code mixed into the frontend for functionality - providers, routers, state management methods, api calls ets, all this extra stuff in your components that isn't just "view". Taking some generated static react and adding functionality is easy. But then coming back to a page 5 months later, and refactoring the design in Noya, and merging that new code with what's actually been built? Kinda tough.

It really depends if code export is a core goal, or more a side effect. There's a lot of value imo in a tool for designers, devs, business owners, whoever at a company to mock up an idea really quickly, with something that looks like their companies actual design system. Like the napkin sketch on steriods - but then still implementing it traditionally.

[dabbott]

Definitely agree on there being a lot of value in the napkin sketch on steroids approach, and that's where we're starting.

Creating real designs and shipping to production within a constrained environment (e.g. https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...) can be super high leverage, so that's ultimately where we want to go. Right now every company that wants to do this has to build it themselves. We didn't use an off-the-shelf solution like Webflow at Airbnb (afaik) because there was no realistic way to integrate it into our stack. I'm not sure if Noya's code export will be what people end up using for this - maybe some kind of JSON-config or something else will be the more useful artifact.

As an analogy, Retool makes it easy to create internal tools, and is usable by more than just eng. But somebody on the eng team needs to first configure it a bit (e.g. plug in the company's data sources) before making real tools becomes possible/efficient. Noya will require a similar level of configuration to become usable in these more advanced scenarios, but we think the value it delivers will be worth the effort.