I’m a UI/UX designer and web developer, and I have to say that PenPot’s Dev Mode is one of the best on the market. It provides non-responsive code that matches the design with over 96% accuracy in most cases — which is truly impressive.
I often work with Tailwind CSS, Bootstrap, and React. I’m wondering if there’s any method or tool to automatically convert PenPot’s non-responsive generated code into fully responsive code (in Tailwind CSS or React) without affecting the visual design.
Any advice or recommendations would be greatly appreciated, as I currently spend a lot of time manually adapting the layouts.
I have no idea myself if it’s possible and would be interested for sure to read what others have to say about this.
To me it seems complicated to automate this process of generating responsive code directly, as it requires defining breakpoints and making human decision for how the layouts have to behave with media queries. Although the new container queries could also be used, but still it becomes quite technical and maybe beyond the scope of the design work ?
@Adam_Alderson what do you need to make the code responsive? Are you using flex and grid layouts? Or are you looking for breakpoints being supported in terms in the code? (Or something else entirely?!)
Hi Laura,
The code generated by Penpot is useful, but it isn’t responsive. When moving to integration and making it responsive in Tailwind CSS, Bootstrap, or others, it takes me quite a lot of time. If you know a practical and proven method, I’d be very grateful.
I’m currently developing a tool that converts designs into responsive code — it works well with simple layouts only, and I plan to train it over the coming months to handle more complex ones, hoping to achieve better results.
Hi Louis,
Modern or irregular layouts are always challenging. I’ve built a tool (still in development) that converts designs into Tailwind CSS with about 90% accuracy on simple layouts and 60% on complex ones. The output is fully responsive, but it still struggles to match the design precisely when layouts are modern or intricate. If someone manages a true Penpot-to-Tailwind/React conversion, it would save teams an incredible amount of integration time.
I like the idea where AI can output responsive code based on non responsive design, but for it to truly work it needs to work 100% of time which non of the AIs are good at. If it works 90% of times it’s unreliable and you can’t be sure in it without testing the code.
I would rather first make a manual UI solution for designers where they can create design in different brake points, and that it’s represented properly in the code. I think that Framer has done this really nicely for the designers part (I don’t know about the code part). In Framer you design whole pages, and each brake point is represented on a canvas as seperate frame. When you design something on the desktop brake point the design cascades to smaller ones, if you make a change to a tablet brake point it would cascade to mobile but wont affect the desktop. In our case AI could be used to predict how to change design for smaller brake points, and user can make manual changes after.
As a designer this is the easiest way to deal with brake points, in my opinion. Other page bulders like Webflow have this as well but you don’t have canvas with all brake points visible, instead you need to use a switch/dropdown or manually change page widgth for one page only.
So my idea for PenPot would be that you could define brake points on a file level, then on the frame level you can decide if you want to get copies of that frame for all the brake points. You can do this for only top level frames. Frames with brake point option turned on need to be visually connect as a unit and they need to look differently from regular frames since they act differently.
There are more details to this idea, but I hope you got the main point.
As the web world moves towards container queries and more flexible units like clamp, I think we might start moving away from breakpoint-based design in favour of thinking more modular/componentised systems. (My thinking on this has long been influenced by my designer-developer pals Heydon Pickering and Andy Bell.)
In some ways, we lean on breakpoints because they gave us control for responsive design. We weren’t just designing one fixed-width view anymore, but there was comfort because we could design a different fixed-width view for mobile, tablet, and desktop, and breakpoints were the magic that would make that work in web browsers.
Ultimately, we as designers could move towards more system-based responsive design in Penpot utilising components and design tokens, without having to introduce new features to the UI (and making it harder for other design use cases.) Design tokens have huge potential because they could be used to support more web-specific (and other niche) use cases. For example:
Imagine you wanted your font sizes to use clamp values for a fluid typography system like Utopia.fyi. You could then enter a clamp calculation as a design token value that is applied as a font size. As long as Penpot could accurately render clamp, you don’t need any new input options in the Penpot UI, and the code (via design tokens) would perfectly reflect the design.
For designing responsively more broadly, I’d love Penpot to support the use case where we can change the sizes of our boards and see how our design elements and components adapt to those sizes, and truly see the benefit of flex and grid layouts. This would encourage us to think about designing more flexibly from the outset.
I’m not sure the best way to implement this… right now Penpot does some clever stuff with adjusting your layout and item properties when you change your board size, which is surely useful for many people, but can break the responsiveness of a layout (as it changes the values you previously set). Perhaps this is an option inside Inspect mode, or its own type of preview.
I’d love to know if anyone else thinks this way! (Or if it’s just my weird brain haha, I’ve had a lot of coffee this Monday morning!)
This seems like a good idea! Actually I used variables and modes in Figma to achieve exactly the same thing as you did in your demo. The reason I didn’t mention it here is because it feels like it’s not enough. I do agree that using tokens, and having ability to use clamp needs to part of the solution, but using just that, in my opinion makes thinks hard to perceive as a designer. Main issue for me is that I need to change modes (themes) in order to see different brake points, meaning I can’t see all of them at the same time, meaning it’s hard to design and we are inheriting UX issues of all web page builders today (except for Framer in my knowledge). Or we could make a component out of our page, then make instances of it as many times as we have breakpoints, and manually change mode (theme) for each of them. Maybe you can make a simple plugin to do this for you. But now you have extra components in your library that you actually don’t need, now you have to deal with that… It’s not ideal and fees hacky.
That’s way I think we need some integrated UI solution, and I only saw Framer doing a decent job so far. For sure there can be some other solution, something that can be used for all the modes (themes). That would allow us to cover even wider scope of designers needs, like seeing all your color themes. I do agree that this feature should be optional and not in-your-face so that you don’t feel forced to use it.
I do agree that we as designers should lean more towards intrinsic design, and not just have fixed braking points. That means designers need to deal with calculation and new exotic measurement units, which will probably be hard for most of the people. Probably it will be used by senior designers and ones that know how to code, but this is the minority. I’m all for idea that designers need to learn to code, but I think there’s a long way to go. Not just for designers but also for developers, most of the design systems I worked with do not support this, and developers I worked with expect brake points. But at the end, the solution for responsive design should cover intrinsic design principle and standard breakpoints.
