Hacker News Reader

Comment by jjcm | Hacker News Reader

Disclaimer - I work for Figma but had no part in the acquisition. My comments are my own and I don't represent Figma.

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.

View on HN

Penpot's CEO here. You're spot on! SVG is a design principle of sorts for us, as we absolutely bet everything on open standards. You say this "but it will also mean they're tied explicitly to the browser's ability to render the combined html+svgs" and we hope we weren't wrong on building Penpot on top of these massive pieces of software. History will tell us if we made the "impractical" choice but our vision around open standards and design+code seamless integration demands that we go all in for SVG. I hope we'll be able to satisfy your curiosity sooner rather than later, thanks for your comment!

Thanks for making the product! It's been really exciting to watch your growth. 100% agree with the decision you made given the objective for the software, and I really hope it pushes more people towards open standards. Best of luck ya'll and congrats on the funding round!

This is my favorite CEO comment ever.

Thanks for your comment. I've been following Penpot since last year and sometimes joined your livestreams :)

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!

Sorry I am amazed by tens of thousands of layers. I have not used figma but with all the kerfuffle recently, I get it is sort of photoshop with collaboration. But how, how does any user interface design get to have 10,000 layers? Is each layer a square or a comment or an erase? I might not get the scale of the collaboration, or something but the numbers sound ... huge.

Annoying, ganky UI's don't just build themselves, ya know.

It's pretty easy actually! Take a look at this page for just a button component: https://i.imgur.com/TodWS0r.png

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.

So what is a ‘layer’? Just any path at all? I think people thought you mean filter or effect layers, so thought a simple button gradient or something was being built up from like 250k transformations.

Best way to think of a layer is as an html element (or in Penpot's case, it's exactly that).

Calling such a concept a 'layer' is quite confusing, given my experience with Photoshop, OmniGraffle, Pixelmator, and most other drawing tools I've seen. Why not just call it an "element" or "shape" or "item"?

When designers started switching from Photoshop to Sketch, "Layer" kinda changed meaning from "a clear sheet with drawings on it" to "any object on the canvas".

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.

I think layer is quite correct. Both Photoshop and sketch approach it the right way. Think of a sheet of paper as a layer. In Photoshop layers are sheets of paper that each matches the size of the document. On each paper you can draw whatever you want. They then lay on top of each other and the white parts are transparent.

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.

I agree that layer is correct, though I understand where there might be some “intuition clash” with people who are used to the classic paradigm.

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.

Do you know of any resources where one can learn how this all works under the hood? ie If i want to build a baby figma for learning purposes.

How does Figma approach this layering, as I understand you have your in-house built engine to support it, right?

Not a figmate but I would guess they create their own virtual representation (e.g. how the browser maintains the CSSOM & DOM trees) and render that to a canvas, rather than relying on the browser to render the SVG.

You are right. They created their own with webgl.

https://www.figma.com/blog/building-a-professional-design-to...

Holy cow. Wow. This image really opened my eyes to the design world. I’m just personally wondering whatever happened with “an eye for design” and intuition.

Atlassian software shouldn’t be used as an example of anything except what not to do.

Stimulating question! Maybe some useful observations as we do client webl <> server cuda acceleration of vector data (our use case is big visual graph analytics) and have to handle large + real-time contexts:

* 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!

Long time Figma customer. In the last week I've had major performance issues to the point my machine becomes unusable. Force quitting Figma is required to be able to save work in other apps before doing a hard reset.

Along with the Adobe news, it's perfect time for an alternative.

> Most robust design systems I see run around 10-40k layers (with the record I've seen being 250k).

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.

It might be illustrative to actually build a design system for a production application and see how you'd improve the process and tool chain. I have to say most of what you're suggesting strikes me as incorrect.

I work full time on Design Systems for production applications and have for many years.

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.

250k layers to build up an image? I'm thinking Photoshop-style layers, or do you mean something else?

I assume each feature is a layer

Or each simulated UI interaction.. amounts to much more layers (imagine a 10k long feature list).

As a designer not in web development, I cannot even begin to wrap my head around that. Because at what point is just developing the thing directly or merging layers or using a more suitable app the solution?

I'm not the parent commenter, but I work using Figma (and other design tools). So, I may be able to clarify it.

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).

Ah, great explanation. Thanks for clearing this up!

Don't think of it as 250k layers for a single image. Modern design tools represent many artboards at once on the same page, i.e. https://i.imgur.com/wvWSv4F.png from https://www.figma.com/community/file/1154649549752855805

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.

I see what you are saying regarding artboard view.

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?

"Can't the artboard be visualized in a better way?" It absolutely can! Caching and optimizations in a zoomed out view are a core part to many design tools today. These are doable when you control the whole stack of how these elements are rendered. Penpot may have to be more clever here though as they rely on the browser to render native elements.

SVGs broke my heart when I went searching for mathematically-accurate SVG renderers and found none.

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.

IMHO not a minor strength, getting pixel perfect designs when SVGs are involved in Figma is near impossible, they are rendered in a very different way and in some cases the differences are huge.

Reply on news.ycombinator.com