This will yield massive improvements on performance while respecting interoperability.
As Open Source fans and product builders, we have always believed in the idea of standing on the shoulders of giants and being completely transparent about how we’re building Penpot and why.
When we started building our open source design & prototyping tool a few years ago, we made a very smart decision: we offloaded all the visual rendering hard work to the browser. This allowed us to focus on the Penpot internals and innovate on end-user facing features at light speed. There are many examples of this but CSS Flex and Grid layouts immediately come to mind.
Betting on browsers (our giants in the above metaphor) for the visual output of the Penpot canvas gave us a lot in exchange for a very small price to pay: using the browser’s DOM rendering mechanism. In very simple terms, the browser DOM is an API that interprets HTML/CSS and javascript and “draws” for you; it’s how 99% of the web operates and you can do pretty cool things with that.
We then asked ourselves what a “natural” format would look like to represent DOM-friendly vector graphics. SVG, an open standard, came out as a clear winner and so we started implementing a lossless SVG translation from our internal data representation. For a while all was bliss in the Penpot world, but we recently started to see the cracks in that approach.
At Penpot we’re not afraid of changing our minds if there’s new evidence or a new context. It’s vital that we are able to pivot around core tech decisions. In this particular case, not addressing the way we render our vector graphics could pose a risk to our continued success beyond 2025, so we need to act now.
The cracks
You can skip this section and jump right to the conclusion but I’d be happy if you stay with me to read about three distinct problems.
-
Browsers are still using SVG v1.1 spec from 2011 and haven’t really worked on seriously adopting 2.0, even if the first draft is from 2018 and an almost final version was published last year. This is quite disappointing, to be honest.
-
Browser management of the DOM struggles with an SVG-based infinite canvas. The performance is simply not there. The simplicity of the DOM (eventually) becomes its Achilles’s’ heel as the browser blindly tries to render every single element of the SVG regardless of the zoom level or the effective panning crop.
-
With recent Penpot innovations around declarative design and better collaborative features for designers and developers, we were starting to abuse the SVG format a bit too much. Even simpler things like multi-stroke support– which is absent on SVG 1.1 but which we introduced in Penpot 1.13 two years ago– required some nice hacks.
In isolation, none of these are deal-breakers. Combined, however, they start to wear on our capabilities. The Penpot community is trusting us to build the best design and prototyping tool, not just an OK-ish alternative to proprietary software. And our community demands that because, honestly, we always said that was our ambition.
We strongly believe the real issue is the DOM treatment of all major browsers, while the SVG is really just the canary in the mine. That said, once you make the decision to move away from the DOM (at least for the rendering responsibility), why not also ask yourself: what about SVG?
A serendipitous opportunity
Our own vision of what Penpot could achieve for the broader design and code community has evolved over the past couple of years. We are now looking at both declarative and imperative design paradigms, and this requires to have a more agnostic view on how we represent visual artifacts on a canvas. Which one is better? Imperative, like SVG, or declarative, like CSS? Well, it depends.
This “it depends” opens up a wormhole that can lead us to a new and exciting unexplored part of the software universe; an open format that can express interactive UI design directly as code.
I’m aware that this is a bigger topic and I wanted to keep this post short, but this is something that, if done right, could have profound repercussions on how we address the dual (visual and code) nature of UI.
For the moment, it’s fine if we just “move stuff around super fast.” If we won’t be leveraging the browser’s DOM free SVG rendering anymore, we are free to come up with our own ways of drawing pixels.
The conclusion
The work around a new Penpot rendering engine has already started. We will publish all the details as soon as there’s something juicy to discuss, and not any moment later.
Being a refactor-type adjustment, the vast majority of users will never get to learn about all this, because 1) it won’t affect the Penpot’s UI, 2) it’s going to be quite transparent in terms of functionality and 3) you will still be able to export your work as SVG (like now).
Actually, this is the type of technical decision that most of the companies never feel the need to share. But for us it would feel extremely awkward not to be absolutely transparent with every important decision we make as we continue to build the absolute best design and prototyping tool for designers and developers.
PS: If you feel like you could give us some tips around do’s and don’ts, feel free to reply to this thread or reach out to us via pablo.ruiz@penpot.app, where you can produce more structured suggestions. The team will make sure to give credit to all contributors!
We’ll keep the community updated, of course.
