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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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
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.
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.
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.
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?"
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.
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.
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.
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.
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 think all these approaches for code-generation have been around for a while and are interesting for web-agencies but as soon as you need to have more finer grained control they lose their initial benefits.
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.
Plasmic (https://www.plasmic.app) enables this workflow—you can visually edit the design while editing behavioral code side-by-side—but with a different approach than what you described, since we want to include non-developers. (I work on this.)
This is organizational content ownership - we'll reword this to be more clear. This is to ensure that files can be managed by the organization even as users belonging to the organization are deprovisioned.
Yeah a little help popup might make it more clear. Like defining what happens when it is owned vs not owned. Without any description it sounds like your organization owns anything created by the tool except for enterprise customers.
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.
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.
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.
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.
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 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.
Call me old-head, but I design with code first. In my practice this is effective. I usually start with low-fidelity prototype with some tool and move directly in html/css to create design system containers. My final step is to work on visual parts, fonts, illustration, ui elements, animation.
But how do you make the entire developer community conform to your idiosyncratic preferences if you don’t create a poorly designed DSL mixing multiple abstractions in a soup of future technical debt?
I don't remember having a single problem with developers with my idiosyncratic preference. Actually my process is driven by the lack of good prototyping tools and optimisation in implementation time. Mixing multiple abstractions? DSL?
No. Last I checked - HTML and CSS are not soup of technical debt. Actually I am quite shocked to find out the lack of knowledge of CSS in developer community.
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 :)
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?
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.
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.