Figma to React
figma-to-react.vercel.app
figma-to-react.vercel.app
My team has been using our Framer export (with a few tweaks) as the actual final UI for our early product. Designing is as easy as in Figma, with the advantage that you have actual React components out of the box (working chart libraries, video components... any package you want to use). Whatever you design is responsive, can be connected via API to any database, and all of this is done collaboratively in the same document.
It has been a mind-blowing experience in terms of product shipping speed, and as a designer, it really makes you connect in a deeper way with the complexity of the final code.
- There's nothing stopping you from using it in production, but it isn't designed for this. What you create does not even use real layout, does not use normal HTML elements, etc.: see https://www.framer.com/support/using-framer/creating-real-ap....
- Inevitably in any real-world project, various parts of the UI need to be changed/overridden from code. But you cannot iterate on the design once ejected, which is a significant limitation for any product that requires iteration.
For building prototypes, it works great, and it makes user-testing a "happy path" nice and breezy.
That said, would love to see/hear more about the projects you've shipped to production!
(Disclaimer: I work on https://www.plasmic.app.)
We are in a very fortunate position financially (multiple years of runway), and I am YZ. :) We also have companies big and small relying on Plasmic in production. Lastly, you fully own the code that you generate, and can always eject with clean React.
I'll be glad to share the project over DM, feel free to shoot me an email :)
Also, Plasmic looks really interesting, I'm looking forward to try it out.
If you're so keen on not writing code, you're better off using a page builder.
Design tools are specialized to do one thing really well. You should always use the right tool for the job.
Page builders in my experience aren't efficient to design, this on the other hand makes designing easier (as I have access to interactive components, real client data, etc).
I think the export might not be so suited for bigger teams though. For reference, a simple 4-page navigation can lead to a +200mb file export, and its basically HTML within an iframe.
For the team as a whole, I think its more about having the designers speak the same language as devs on a shared interface. It empowers us as it makes exporting prototypes for user testing that can be easily hosted as if they were coded for real, and forces us to focus on interactivity & flows rather than the design per se.
On the – non Beta – Desktop version, it works as a single folder file (pretty sizeable, +150mb) that you can host anywhere, and renders the prototype within an iframe.
The team at Farfetch did a custom component to do something similar to what you mention (if I understood you well): https://youtu.be/LEMGL2NH0r8?t=2760
It can be slightly hacked around to add user authentication & analytics, so if you are handling a small amount of users its a really efficient way to iterate fast.
Of course the initial users will experience a slow product, but the idea is to discover faster what a useful product looks like without investing development resources.
But let us be realistic. I just loaded www.amazon.com - 17.8 MB transferred when it finally stopped. Arguably one of the most successful websites in the world.
A 5MB asset size for most sites is perfectly acceptable.
I think someone else said there are other optimizations that happen when you shop production code.
Aside from that, they use the app literally their entire workday, so spending 5 seconds loading the thing isn’t going to hurt anyone.
- variablized colors and fonts, that can become CSS variables and classes
- Components and component hierarchies, that can turn into React components
- Auto-layout that is based on Flexbox
- Component propertes (Variants in Figma, but with enough effort it can turn into attributes for React components).
With a bit of annotation inside Figma, I can easily see pretty good results for this conversion.
Developers aren't just people who know a programming language, they're people who can examine a problem in detail. If a designer was capable of this they'd be a dev who designed and they probably wouldn't use a GUI web design tool.
Do any developers in this conversation have advice or tutorials that were effective in teaching them how to use Figma or Sketch, or perhaps just be effective in integrating artifacts from those tools that others on the team are using?
Converting figma layouts to code is fairly trivial. Converting it to code that's usable is a whole other story. There's the actual design related concerns such as nested layouts and dynamic behavior, as well as code base management concerns.
At best this is a possibility for some tools like webflow, or framer. With figma, there's no chance given how they would have to re-implement to get actual feature-parity with actual target platforms.
Disclaimer: I am in this space and basically building what we're talking about. All these people saying that this is the future of figma are out of their goddamned minds. Figma already has css exports, and maybe they'll get design tokens. More than that? It would be a completely different product and kind of insane to try. The focus and clarity that figma has is underrated. People think that just because it's all about web dev, these are all the same tools, but they're not.
Code frameworks have long found success with this scaffolding approach, where you can provide structural hints/direction to the average intermediate/junior developer who can handle the component-by-component implementation but might need a hand with broader architecture decisions.
Most large enterprises I've seen are full of exactly these kinds of devs who are primarily tasked with component/page-level implementation, but if you leave them to make decisions about how to separate and lay out components, you get a lot of inconsistency across your teams, even when the designs are consistent.
This would be a valuable problem to solve that I haven't seen talked about much.
I hear what you're saying about nested layouts and dynamic behaviour but do you think this would be good for individual components (even if these are large components such as page layouts?)
Even if somebody did do all of this, merging the file from the app into a real project would be difficult. There'd have to be rules about merging, and diffing, and command line tools, etc. Maintaining and documenting all of this would be an absolute nightmare. And that's not even getting into engineering or marketing difficulties because you'll have people confused about the product identity, or say that it's too complex, or that it's buggy because it has so many more features now. And all this for pretty much nothing.
Because figma already has css exports (even if it's iffy, they're working on it). You export the styles, the padding, the colors, and that's what people really want to get from their figma files. So you get most of the way there for a much, much smaller fraction of effort.
https://www.framer.com/user-testing/
The prototypes can be heavy on the browser, but once you go past that the immersion level is deep. You can even add custom google analytics events for quant analysis.
Call me skeptical, but I wonder how useful it would be for the FE devs on my team. In the past, I've never had a great experience with code generators, I've usually ended up ripping out the results and redoing it myself. Sometimes there's an unexpected limitation ("oh yeah, we use tailwind, this is useless to us!"), or a bug, or sometimes it just doesn't produce something I would stand by.
I'm also a little scared of showing this to other designers, or project managers, because I'd be worried about it setting unrealistic expectations. "Great, there's the front-end problem solved, guess you developers can do about twice as much work in a day now, right?"
Same shit, different day.
I expect exporting from Sketch/Figma into React components would be cumbersome in this same way.
If I may pose another example from my days of industrial design, Rhino is a great tool for rapidly iterating designs and building CAD for renderings, however when your design is approved you really need to rebuild it in Solidworks for it to be made.
The real solution here is for companies to adopt a Design Ops/Design Systems Manager that can design and code in the front end. This would remove burden from the engineering team so they don’t have to worry about doing tiny design tweaks, etc.
The Wikipedia page for Rhino says it’s a CAD tool, but Solidworks says CAD and CAE. So Rhino has a subset of Solidworks’ capabilities.
Engineers use CAE to help with determining how the materials, dimensions, and other engineering choices will be have under loads. So these have some similarities in that Solidworks can also do 3D modeling, which is used as an input to performing CAE.
Different audiences and different use cases.
I've recently made the switch to a similar workflow with Framer just a year ago, the difference here being that devs in my team use & maintain the same components that I use for prototypes/design, so the collaboration aspect is quite seamless: https://github.com/framer/framer-bridge-starter-kit
SwiftUI has really shined in this regard where instead of offering a visual canvas and code-generation behind the scenes it does both things [1]. It has code and preview side-by-side so you can write code and see the preview but also change the preview and do a tiny bit of code generation for you. Making the whole coding experience much more interactive and fun. In this "in-between" world the code on the left becomes like an actual UI widget in Figma - instead of modifying and learning the ways the auto-layout widget works, you can just modify the code on the left. With proper TypeScript definitions I can imagine the widget automatically generating based on the props (or something fun like that).
To me this is what's missing in webdev, someting in between like SwiftUI. DevTools cannot do this - for instance dragging DOM elements around cannot be persisted because, well, JS kicks in can change everything when you page reload. But we have stuff like React that shifts the paradigm to make it more like SwiftUI hence for React-like frameworks this world should be possible.
I explain some of my dreams in this thread: https://twitter.com/lmatteis/status/1375557621789384705 and also here https://twitter.com/lmatteis/status/1375551822740488198
1. https://twitter.com/lmatteis/status/1376146147975303171/phot...
Figma to Svelte would be the dream team and probably trivial to make thanks to .svelte files supporting vanilla html, css, and js.
1) React also didn't have any of that when it started.
2) The "ecosystem" is a fallacy. It's merely used as propaganda, to win popularity arguments and to dismiss new technologies. 99% of the packages on the so-called ecosystem are badly written, unmaintained shit, and most projects don't really need third-party packages other than React/Redux anyway. Especially projects that have a dedicated designer using Figma.
If you've been around for more than a few years, you've had plenty of opportunity to see how inaccurate this extrapolation is, like how HN enthusiasm for Elixir doesn't mean that more than a tiny fraction of us are using Elixir.
It's just kind of boring to hear someone complain/jest about "haha developers = lemmings seeking shiny amirite? XD" over and over again, thinking there's some novel witty snark to be had by repeating it for the millionth time. It's also confidently wrong. Most people aren't migrating to new tools just because some people are excited.
I noticed this doesn't yet support a number of things in Figma: autolayout, SVG shapes, masking, blend modes, transforms, filter effects, etc.
There are also numerous other Figma-to-React tools out there, but of varying quality. You need heuristics to address the impedance mismatch between the different representations and to yield something usable.
I work on https://www.plasmic.app, a design tool for building production (React) frontends and not just drawings or prototypes. We built our own Figma-to-React converter [1] - I haven't yet found another tool that yields higher-fidelity translations. I'm hoping to put together a comparison of the tools one day, if this is of interest.
[1] https://www.figma.com/community/plugin/845367649027913572/Fi...
also, where does Storybook fit into tbe picture?
And for the first example: "(0,_reactNative.requireNativeComponent) is not a function" (after importing the dependencies)
That would be a killer feature for me
Designers who can't/won't learn to code have a tendency to either never implement a design component system, or they never stick to one.