Most design tools like Figma come with some sort of dev handoff tool that produces pixel-perfect HTML/CSS (though you might need some tweaks for responsiveness). Have you tried feeding that to the LLM as a starting point?
I also work on Plasmic (https://plasmic.app) a no-code editor that aims to fix this problem by eliminating the dev handoff, though it does take some organizational buy-in to work.
One problem is that the code tool is usually a one-time code export. After the export, you'll probably want to change the code--add some business logic, event handers, etc. After a while, when the Figma design is changed, there's no way to update the presentational code only without redoing the changes.
Plasmic is working on solving this problem! The designs you make in Plasmic are architected for continuous iteration. Disclaimer: I work at Plasmic!
in the 1990s which could often make the same edits a professional programmer would make when you edited a visual representation of the code because these were based on a Concrete Syntax Tree
where comments, whitespace, item ordering and all the choices of how to write something are represented. I don't think you could bolt this on to Figma because Figma doesn't have the right representation to keep track of it all.
Graphical editors run into so many little problems like the width of something gets computed to be 13.3333333333px maybe there ought to be a hierarchical "snap to grid" that makes sure is is 13px or 13.3px or 13.33px in the output source code, stuff like that.
Also what exactly is the target? MUI is mentioned in another friend and that's salient to me because I am looking right now at the accessibility of an MUI app: a tool for building applications and theming one single widget set seems like a feasible goal, particularly if it can all be codesigned.
I think, with most WYSIWYG editors in the past, a developer runs into some limitation, forcing them out of the system into uncharted/hacky territory. But for Plasmic, developers are a first-class citizen.
For example, one huge advantage with Plasmic is that Plasmic components run within your React tree. This means you can naturally embed Plasmic components in your React components, and even the other way around!
MUI's Toolpad looks pretty cool! I'm going to try it out today.
One big difference is that Plasmic is a platform and can be used by non-developers to make changes that go straight to production. Think marketers, content managers, and other non-devs that are on your team who want to ship new designs and content without bugging the dev.
+1 to Chung's reply. There's also a loader API where you'll generally never need to see the code that is output. Check out the differences between loader API and codegen here: https://docs.plasmic.app/learn/loader-vs-codegen/
In case you still want to see the code from codegen, here's an example. We generate 3 files per page/component:
While 1 and 2 will be overwritten as you update your project in Plasmic (and therefore you should never modify it), the wrapper (3) is yours to customize as needed, like setting props or binding event handlers. In the above example, we computed how much free trial time a customer has. You can read more about the generated code here: https://docs.plasmic.app/learn/codegen-components/
For component composition and layout, Plasmic makes it easy to build responsive pages. Our primitives like stacks are all based on flexbox, though you can use absolute positioning if needed.
I also work on Plasmic (https://plasmic.app) a no-code editor that aims to fix this problem by eliminating the dev handoff, though it does take some organizational buy-in to work.