Penpot 2.0, a major milestone in our journey, is now yours to explore and enjoy!

As it’s often the case with major releases, they feel both like the end of a journey and the beginning of a new one.


Short clip showing all

Let me first cover why Penpot 2.0 is such an impactful release.

Once again, we delivered on our promise to bring developers and designers closer together. Our bold movement to build CSS Grid Layout and enable designers to create responsive interfaces matching coding constructs was unexpected. The design tool space has changed forever.

Component Libraries have been revamped with a new data structure to help designers and large teams build extensive design systems more modularly. The addition of component swapping as well as more flexible categorisation options provide a significant boost in productivity.

We rebuilt the entire Penpot’s UI to be sleeker, faster and more beautiful. This will be obvious to everyone that used Penpot in the past but equally mesmerising to newcomers. Streamlining user experience means allowing for more time spent creating and collaborating at scale, which sits at the core of Penpot’s mission.


Penpot 2.0 showing an interactive prototype

Each of these features, on its own, would have deserved a major release and yet we have another three major updates.

  • You can now use images as a fill property.
  • We added HTML generation on top of CSS and SVG.
  • UI theming is now a reality, starting with Light & Dark.


Dark or Light themes, we love both!

If you want to know all the details of what comes packed with 2.0, including performance improvements and 40+ changes not covered here, head to our Dev Diaries page.

It took the team 9 months to build and ship this amazing release. We didn’t want to cut corners, we wanted to be proud of our work so you could team up and collaborate around design and code projects with no limitations or compromises.

We are building our own path where concepts such as declarative design, future-proof ownership of your work and a no-handoff mindset meet long-standing pragmatic design and coding practices.

Our SaaS service at design.penpot.app was the first to roll-out 2.0 a couple of days ago and self-host images will follow very soon. We will always make sure that, no matter your choice, Penpot delivers the same experience.


Design-as-code is a reality with Penpot

What’s next?

Delivering Penpot 2.0 required the product team to act almost as a sole entity so interdependencies between new features would not create bottlenecks.

Post 2.0 we are shifting to an “initiatives” approach where smaller autonomous teams can ship upgrades independently. “Design tokens”, “Plugin architecture”, “AI” or “E2E testing framework” are some of them.

Do you want to know everything about Penpot 2.0 and what we’re cooking up next? Do you want to learn from amazing designers and developers that are shaping the industry by driving collaboration forward? Do you want to enjoy our very own PenpotFest in Barcelona, 5-7th June? Make sure to get your early bird tickets while they’re still available!

16 Likes

Congrats on the launch! Penpot has surely come a long way. The team has done amazing work! I’m eager to really start using it, but I still feel like there’s one feature that’s preventing me from doing so. Components really need states/variants. I know that you have a story for that in the Components 2.0 epic (Taiga), I just hope that it’s prioritized for implementation sooner than later.

Thank you all for all your hard work.

Well, I take back what I said about component states/variants. It looks like your component system is quite unique in how it deals with variants. After watching this video (https://www.youtube.com/watch?v=dOGu1ke9fM4), I was curious to see if what I was seeing in that tutorial, was really the case so I decided to test something.

After taking a deeper dive into the component system, it seems that variants are possible. It’s a new way of thinking about components states/variants. Main components can be created from instances and then those new main components can actually inherit from the instance’s parent main component. So component inheritance can be multi-tiered, which is pretty interesting and useful as a solution for component variants. Now, in light of this, the only thing that is still needed is some kind of hover solution for prototyping (unless it’s there and I’m missing it?).

2 Likes

Am I missing something or is there no way to set interactions as part of the component master itslef? On more complex systems I almost exclusively use variants for states to get a more flexible system of components. But an important part of state variants is the ability to set interactions on the master, so no repetitive work on instances is needed.

Oh, I take that back. I see it is possible. However one issue I notice is with nested components.

I have a button component, that has default and hover states. Interaction is established on the component master. If I place this button on the board all works well. However If I include this button in another component, like a nav bar, then the hover effect no longer works.

setup

And this is the test case. Buttons that are marked red … work as expected in terms of hover effect, but ones in the top bar do not. On the red ones hover works, but click does not. :frowning:

Hover is achieved with toggle overlay

@thisbit How did you figure out hover to toggle the overlay above the button? Everything I’ve tried toggles the overlay on the board, but not in the same location as the button. I’m sure I’m missing something, but hover is currently so poorly documented in the Penpot documentation.

I do think that variants/states are far too unintuitive as they are now.

@thisbit I ended up finding an answer here: Problem trying to make hover effect - #3 by jdittrich

This is definitely an incredibly awkward user experience, which I hope the team improve upon in the future.

1 Like

I’ve managed to optimize the pattern a little so that you don’t have to have the additional states off board cluttering up the visual context, but it still feels awkward. Anyway, here’s a simple POC.

You simply place the additional states below the default state.

hover-poc.penpot (42.6 KB)

1 Like

I’m honestly having trouble following how the component variants are supposed to work watching that video. And the fact that the term “variants” or “states” isn’t used and the original ticket hasn’t been updated makes this look like a temporary hackey workaround rather than actual fully fleshed out final feature…?

1 Like

Hi,
The file was helpful, but I still can’t get to replicate it in my files. Can you kindly do a quick screen recording on the matter please?
I’d be grateful.

Thanks in advance

@iyadh Did you also take a look at this post, which I also linked to above? That should provide you more context… Problem trying to make hover effect - #3 by jdittrich

I checked the post, but the process is still unclear. Here is how I do it (check the video below please), Am I missing something in the process?

Hi team

First of all thanks for penpot 2.0

I am facing few issues with new penpot 2.0 in self hosted environment

I have exported 1 artboard in svg format from penpot 2.0, not able to edit same svg again . Copy paste not working fine. Exporting all artboard in 1 pdf is also not working .
Let me know if I am missing anything.

Thanks, this is kinda almost doable for tiny projects. But yes, we need component variants with interactions inside component definitions. Like that is imo the biggest blocker for real use.

2 Likes

Yeah, I agree. I revisited this pattern recently to try it out for a project and it really is awkward in practice. I’m currently sticking with XD until a more fleshed out variant solution is available.

Please address performance issues first of all!
This is crucial

We have important news on this, we’ll share all of it very soon!

3 Likes

here you are It's time for Penpot to (almost) move away from the DOM