I'd be interested in hearing a designer's view on this sort of tool? It seems really appealing for me as a developer (and I've thought about building something like this in the past) but I wonder where it fits in the designers workflow?
Won't work. It's a cool proof of concept, but practically, 0% chance of it being really useful.
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.
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?)
No, because components implies inputs (props), and things like conditional rendering, or slots (props.children), or even life cycle hooks. You'd have to make code style decisions like what kind of code style to use (functional vs class in react e.g.).
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.
I swear I don't work for Framer, but I've been using it very intensively for UX testing and users aren't capable of differentiating the prototypes from the actual real thing:
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.
Do you potentially see a middle ground where you could export reliably optimizeable assets like CSS and design tokens, and then instead of trying to export a perfect representation of the design, you could export a high-level scaffold that would at least get the developers started, perhaps by laying out named - but not implemented - components (ideally following a predefined architecture template).
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.
The way design tools are built – Sketch, Figma, XD... – its an added burden. I believe this is the future for collaboration between front-end & UI designers, but I feel it won't have an easy adoption until its tightly integrated in the designer's workflow.
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
I'm a designer who used to be a React developer (2 years out of the game though). I don't have a strong opinion about the engineer's choice for how to implement my designs, but if this makes their lives easier and gives us a little extra time to make improvements, I'm all for it.
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?"
I think a good parallel of this is Webflow, which I find to be an incredibly powerful tool and gives design teams a lot of freedom to build and deploy their designs, however it’s incredibly cumbersome if you’re using it to mock up options and explore iterations. That work still happens in Sketch for our team, and when it’s approved that same team brings it into Webflow and “does it for real.”
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.
It’s not necessarily a feature comparison, but I’ve found it much easier to just “try” things in Rhino. Solidworks is best when you already have a clear idea of what you’re building. In that way, our industrial design team would use Rhino and then hand it off to the mechanical engineers to rebuild it in Solidworks.
Judging by partlysean’s response, “our industrial design team would use Rhino and then hand it off to the mechanical engineers to rebuild it in Solidworks.” I would think Rhino lacks the entire Computer Aided Engineering (CAE) capabilities that Solidworks has.
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.
This'll generate the kind of code you'd expect to get from a $60 themeforrest template. If you don't care to or never need to dig into it or reuse anything out of context of the prefab template you'll be in an 'OK' place, but anything more than that and you'll likely be not much better of than if you just started from clean.
Ah yes, Svelte. What we're witnessing is a mass migration from an established society with great infrastructure, education, governance and stability moving to a barren uninhabitable land of opportunity and unlimited possibilities albeit full of traps, broken pipes, dangerous bugs and vicious wildlife. Troves-full are jumping on these new bandwagons, cramming themselves in, clueless but hopeful from the allure of a far promised land of the wild wild west.
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.
I was mostly mocking how fast JS ecosystem moves. Evidently, HN didn't find it funny. Just about the time we have a matured React framework, we've got another framework to jump to.
I mean, in 5 years Svelte could be the new React, and React could be the new Angular. I mean that there are plenty of people still using Angular for legacy apps, but it's not exactly "in vogue"; trends showed that people were generally more satisfied using react. React isn't going away, but if people are more satisfied with svelte (which the trends seem to indicate, and I understand why after learning a bit about svelte from a React background), I think it could dominate new projects in 5 years.
Why do you confuse a little bit of HN enthusiasm for mass exodus? Does it surprise you that the most vocal people on a forum of craftspeople are the ones in the honeymoon phase of new tools?
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.
If Figma has their eyes open, they'll run with this idea. Design once in Figma, generate UIs for React, Vue, Jetpack and SwiftUI. Designers become way more productive, doing part of the work of front end devs.
And from my experience Figma conversion exports are massive. Did a site last year and it spit out 12mb. Nice in terms of turnaround, but not in terms of performance.
All around. HTML was massive nested div soup, CSS was a mess and every item had it's own styling, JS for these page position trackers and other mess where an entire library is added for only a few lines of js.
That can't happen. When a tool like this gets complicated enough to fully specify a complex problem it becomes unusable by the semi-technical people it was made for. Best Figma knows their strength and stays with it, leaving the extensions to other companies so as to compartmentalize the difficulty.
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.
This is why I use Framer, they have a built-in export to React function that is really powerful for early startups (as the whole tool is built on React)
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.
Our designers are on Figma right now (they seem to switch every 12-18 months) but I kind of wish they’d switch to Framer, I’ve heard great things about the React export. We’ve been using Framer Motion, their animation library, for years and it is just phenomenal.
Framer motion is great, and its integration on the tool makes it deadly simple to use!
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.
Hey do you have some details on how do do this? I'm having some trouble figuring out how to do this from web app. Am I supposed to use the JSX details in the handoff pane along with the Framer react library? It seems like an incredibly useful feature and would really like to take a look.
You need to have a pro account to use the desktop version and make the export, and as we speak they are refactoring this version to include it in the web version.
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
The actual load per page was around 1-5mb, so even when doing remote mobile testing in areas with low speed internet it wasn't an issue (although its definitely one of the main reasons to switch to a real react site when scaling the product)
I disagree. How did 1-5mb become an acceptable size to ship to your users? That's actually quite a lot. In a slow connection, this isn't even going to load anything except a blank screen for such a long time.
Because there's a LOT of people out there who have slow mobile data or poor signal strength. I think assuming that everyone everywhere has extremely fast internet is a bad assumption. Also there's an enormous amount of bloat in package sizes now, I don't think this really should be as bad as it currently is.
I agree 100%, in the use case I mentioned we were looking to either prove or disprove product hypothesis with real users fast so efficient code wasn't a priority, but rather to confirm wether what we were about to develop was valid.
I don’t know what your caching settings are, but my users download the app exactly once, and then only again if I push any update (or their browser cache randomly decides to clear itself, don’t really have any control over that).
Aside from that, they use the app literally their entire workday, so spending 5 seconds loading the thing isn’t going to hurt anyone.
Yeah testing is its intended usage, but on the initial phases of the product we did use it as the finished product clients were paying for.
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.
The idea of these tools is to allow teams to test a wide array of hypothesis to then have data-backed flows that make sense to code efficiently. The size is an unfortunate trade-off for testing speed.
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.
I'm an efficiency freak, so I understand what you're saying.
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.
Yeah, I agree with you for the most part. And this argument comes up a lot. The difference is we're not Amazon yet. We don't have the same levels of user engagement, loyalty and whatever metrics that makes Amazon a success. To the end users, we're not as popular, one slow page load translates to a lost potential customer which when aggregated to even a few 100 potential customers could make or break a startup.
You should check it out, because its actually the other way around. Framer is basically React you can tinker with and use actual React components, it just happens to have a great UI on top that makes designing with no code seamless, and whatever you design is React behind the scenes.
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).
It's normally slightly larger on average. I get you're joking, but the joke doesn't even make sense. A full build of LLVM + Clang is 15-20Gb, and yet, weirdly, IOS apps are not all that size.
Ah apologies, I thought it was just a "hoho isn't node_modules big" comment. Yeah, its output: 150Mb seems hyperbole, but afaics it's not far off an order of magnitude larger than a normal React app.
- 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!
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.
Great idea! I think the biggest objection will probably be that the styles are too 'vanilla'. If folks are using some framework like Tailwind CSS they still have to map the classes. It's still a great start though :)
This seems like a great conversation with both developers and designers. As a developer, I'm not having trouble learning about new tools on the developer side of things. But I'm struggling to learn about Figma and Sketch.
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?
I guess everyone learns differently, but for me, the best way to learn a visual gui tool is to just use it. Click around and try things and sure, sometimes you have to hunt for a feature or a quick search to figure out how to do something specific, but then the next time around, things will go quicker.
Sketch has a lot of very easy to use and understand documentation about their features that helped me learn it. I’ll say this: start learning about symbols early and use them to their fullest. It’s like working with components and they are very powerful. I find them to Ed e the most intuitive part of you’re coming from a UI engineering background.
Overlay too: https://overlay-tech.com/. Their Figma plugin is very good for React/Vue code and SCSS. It manages nested components and extracts design tokens automatically.
I think all design tools should have a component-first UX (eg Storybook but embedded in the tool). We devs obviously know how to think in components and understand how props work.
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.
I mean we've had these tools for two decades now and yet front-end coding seems fine. There are numerous tools for (eg) mapping UML diagrams to code: I assume you don't feel threatened by those?
No, nothing to do with frontend code, as in auto-generation of application code. There are a vast plethora of tools for generating code that have nothing to do with web frontends: why are they somehow less threatening?
If anyone is looking for something like this but uses flexbox positioning (no absolute positioning) and support for other frameworks (Vue, Svelte, plain HTML/CSS, etc) - https://github.com/BuilderIO/figma-html
Kudos to the author for making this, these are not easy to build!
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.
I haven’t tried this product yet but the CSS export functionality in Figma doesn’t seem to be that smart yet - for instance if I’m using an auto layout to space elements evenly, I want the spacing to be defined as margins on direct children from the parent so that my CSS remains DRY and the layout concerns lie on the parent, not each child; but it doesn’t seem to do that kinda thing unfortunately. I’ll play with Framer seeing that people are recommending it here, I wonder if it’s better.
120 comments
[ 0.24 ms ] story [ 209 ms ] thread- 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.
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.
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.
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'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
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?"
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.
Same shit, different day.
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.
https://github.com/Parabeac/Parabeac-Core
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.
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.
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
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.
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.
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).
- 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.)
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.
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.
That would be a killer feature for me
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?
https://www.supernova.io
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.
And for the first example: "(0,_reactNative.requireNativeComponent) is not a function" (after importing the dependencies)
also, where does Storybook fit into tbe picture?
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...