I really love that Penpot is sticking with standards and I think piggybacking on SVG might bring lots of cool features for free. I always thought that it would be very nice to embed custom stuff using the foreignobject tag that could enhance a live prototype (ie: videos, 3d content, real html+js, etc).
Use real scripting + SVG is a dream of mine to build a design system. You know many of us are hybrid devs and designers and sometimes pushing pixels here and there is too much work when a simple script can automate stuff :)
I hope you have a good plan on how to optimize the canvas since I found it my major blocker to use it together with the lack of autolayout (I know you are working on this last one :)
On the other hand, I'm a fan of Kaleidos and your business model and I'm very happy that you got the funding to speed up Penpot. Hopefully one day we could cross paths and have a chat!
It has 1.3k layers, and this is for one component. Most design systems have around 50 components, many more complex than just a button. This is from the Ant Design System: https://www.figma.com/community/file/831698976089873405
Another way to think of it that may help put it into perspective for devs, think of the number of html elements in your average storybook page. Atlassian's page for their button has around 2k html elements to display all the variants and documentation: https://atlassian.design/components/button/examples. A Figma file represents all of the components in the same file, which quickly leads to an explosion of layering. Performance becomes a concern VERY quick.
In Photoshop a layer could have many shapes on it, if you drew one shape/mark on top of another within one layer, they would be inseparable. If you drew any two things in Sketch, they would always be separate, I suspect this is why they stuck with the term "Layer" even though something like "Object" may have been more accurate.
In sketch, instead of sheets of paper that match the size of the document, you have a perfectly cutout shape for each stroke you draw. You can then move that cutout around within the document.
Both of those have the same principle except one is cutout one is not.
When each layer is a transparent sheet it has an absolute Z order that translates 1-1 with the physical thing it’s virtualizing (transparencies, probably from traditional animation).
However if you cut out tiny shapes and arrange them with some on top of others to make a larger composition, there is no longer an absolute Z order to any element because there are a bunch of smaller stacks of various heights.
The virtualization no longer translates to the physical world, and from my experience that disconnect can sour people against a new way of doing things, regardless of whether it’s better.
https://www.figma.com/blog/building-a-professional-design-to...
* SVG at those levels sounds quite amenable to serverside offloading for bulk rendering: not "easy", but many options for HPC types. The browser can handle pan/zoom. My main computational question is hitmaps & hover effects, but wouldn't bet against ingenuity here as the use case is fairly static. Arguably, even Figma should move off in-browser and to offloading, if it hasn't yet.
* Browser acceleration of SVG has been improving over the last decade. Maybe more B round+, having 1-2 people work with Chrome will help knock out whatever is left in the browser. Working to optimize one site on both sides is WAY easier than optimizing for everyone, this is an open secret of Nvidia etc games & top websites for ~decades.
Real-time SVG is less practical in our case b/c our users will run clustering & filters and expect real-time vector transforms of 2M nodes + edges (imagine Google Maps... but live), but for something like a site design.. a lot more room for perceptual tricks!
Along with the Adobe news, it's perfect time for an alternative.
All of that is insane, IMO, and points to the fact that most designers see Design Systems as a giant “skin” and not a set of ideas. This causes massive friction.
IMO this is where Figma fails, it treats Design Systems as a picture. A canvas. This is a relic of graphic design traditions (contact sheets.) Figma’s successor (whatever it ends up being) will embrace the fact that Design is Ideas not Pictures and Ideas are best represented in Code.
Maybe Penpot is onto something here. Although SVG is not the material of the web. HTML is, or maybe the frameworks that target the DOM.
UI Design in 2022 is like pre-modern architecture. Like architects whose designs don’t prescribe anything about the materials of construction.
Check out https://interplayapp.com/ for a different take on how design systems should be created for use in Figma.
I think it’s telling that Figma can’t really do any of this natively and there’s a whole ecosystem of companies surrounding Figma trying to help it actually Do The Job. Zeroheight and Storybook/Chromatic being the other obvious examples.
You're often representing every page on a site, or every component in a design system in the same file. A way to think about it is "If you counted every div on every page of Reddit, how many would there be?". Most modern sites will have around the same order of magnitude of html elements.
But is it necessary? Can't the artboard be visualized in a better way? If such high-level view is desired, won't rasterized details be sufficient till one zooms in?
Figma is a vector drawing tool like Illustrator, which means that the comparison with Photoshop layers is misleading. What the parent post refers to as "Layers" is the name that Figma uses for objects like rectangles or text. So if you have a design file with many elements the number of layers grows quickly. The same happens in Illustrator or Sketch.
The closest equivalent to merging a layer is combining different shapes in one or rasterizing vectors into pixels. The usual tricks to handle big files are to work with different pages (so the app doesn't have to render everything at once) or to rasterize the parts that you'll like to keep as a reference (and move the vectors to another file).
It's not a problem of Figma, but a feature of vector design tools where you like to preserve the editing (and details) of everything. You'll have the same performance challenges in Sketch, XD, Illustrator, Affinity Designer, etc. The case of Penpot using SVG is interesting because big files will push the Browser SVG to its limits. (BTW I took a look at the Penpont code, it's interesting that they use ClojureScript for everything... it gave me the motivation to learn about CloujreScript).
Not only that, but there are spec issues that make SVG precision impossible.
If anyone can prove me wrong I’ll be happily wrong. The easiest example: make 3 circles of radius `r`, and place them in a straight line where the centres are `r` distance apart. The outer circles should touch and not ever overlap. Not even past 999,999% zoom.
Technically I'm very curious to see how Penpot evolves with this investment, especially in regards to their choice to base everything on SVGs. IMO this will be their greatest superpower and also greatest weakness. Keeping things tied explicitly to code means exporting the final product is going to be near-perfect translation wise, but it will also mean they're tied explicitly to the browser's ability to render the combined html+svgs.
Currently Penpot's performance starts dropping rapidly once you approach around 1000 layers. Most robust design systems I see run around 10-40k layers (with the record I've seen being 250k). I'm very curious if they'll be able to optimize their approach to support those sizes of libraries.