Framer, at least when I last tried it, was more of a prototyping tool. You could generally only one-way import React components into Framer, and then you could use Framer to assemble new components, but not in a way that allowed round-tripping. It's very possible to import production components into design tools, it's rare when a design tool can output production components again.
Largely because production-ready visual layout tools themselves end up being canvases that are shortcuts only to those who know what controls they want to use and how other layout controls work - they speed up developers, or those technically-minded enough to learn and compose new layouts with the existing controls and markup, but they won't make it easier for someone to design a new production-ready component from scratch when they don't know existing programming patterns, layout controls such as CSS flexbox, etc.
In that regard, Figma, Framer, and even Facebook's Origami are less about creating production code and more about assisting designers and product folks with rapid prototyping. It's not meant to be production-ready. It's not a developer-friendly toolset because the programming is secondary. And that's fine. Less to learn that way, but not instantly ready-for-production either.
There is some overlap though, for tools like Dev Tools, like Utopia, that need to be learned first (or customized into something like a CMS) but can be very visual ways of programming. As pointed out earlier, Xcode Storyboards and SwiftUI are both visual tools which output production code. It's unclear if this will follow the same standards and patterns that production code demands (such as styles, state management/mapping, shared components, and re-use across projects) but this programmer-friendly model is much more the future of visual programming than previous designer-first tools would allow.
Slight correction, though it’s too late to edit: I meant to say at the end, “it’s unclear if Utopia will follow the same standards and patterns that production code demands,”
That's exactly our aim - if making a change via the canvas or inspector doesn't result in production grade code then the tool is failing in our eyes. We're well aware that there are parts where we're not hitting the mark there (effectively we're in an alpha stage here), but we're working hard to improve that.
Largely because production-ready visual layout tools themselves end up being canvases that are shortcuts only to those who know what controls they want to use and how other layout controls work - they speed up developers, or those technically-minded enough to learn and compose new layouts with the existing controls and markup, but they won't make it easier for someone to design a new production-ready component from scratch when they don't know existing programming patterns, layout controls such as CSS flexbox, etc.
In that regard, Figma, Framer, and even Facebook's Origami are less about creating production code and more about assisting designers and product folks with rapid prototyping. It's not meant to be production-ready. It's not a developer-friendly toolset because the programming is secondary. And that's fine. Less to learn that way, but not instantly ready-for-production either.
There is some overlap though, for tools like Dev Tools, like Utopia, that need to be learned first (or customized into something like a CMS) but can be very visual ways of programming. As pointed out earlier, Xcode Storyboards and SwiftUI are both visual tools which output production code. It's unclear if this will follow the same standards and patterns that production code demands (such as styles, state management/mapping, shared components, and re-use across projects) but this programmer-friendly model is much more the future of visual programming than previous designer-first tools would allow.