Hacker Newsnew | past | comments | ask | show | jobs | submit | v3ss0n's commentslogin

What i tested happned 5 months ago. if the issue exist 1 month ago too it is the same problem.

The problem lies with the whole thing is XML and SVG unlike Figma's Canvas/WebASM . The whole thing is unable to scale.


They are actually working on a new canvas-based rendering engine in order to get away from using the DOM so that should help performance quite a bit.

https://community.penpot.app/t/its-time-for-penpot-to-almost...


that gonna be huge effort , looking forward to that.


Unstable, very crash prone with just a few users designing 10 plus pages. And a huge memory hog too.

I run it on Dedicated server with 64GB Ram , it starts to lag as soon as a 5-6 pages and memory 20GB, lagging out the whole team and then crashes.


Figma is a huge memory hog, too...


Figma has become absolutely shocking in the past few years. The performance is so bad these days. It doesn’t help that almost every designer doesn’t care to split things into more than one document. I’ve seen Figma documents with hundreds of screens.


> It doesn’t help that almost every designer doesn’t care to split things into more than one document

That’s how these tools encourage you to use them. If the tool crumbles under its own usage modalities, that’s because it’s poorly designed, not the user’s fault.


You don't need to split into multiple files to make large documents manageable, multiple pages works just fine (pages you're not using aren't loaded). But even still, I have absolutely massive pages with ~100 screens on them that work just fine on this base-tier M2 MBA.

Honestly given the complexity of the screens involved I feel Figma's performance is pretty reasonable. (Now, library publish and update - that's still unreasonably slow IMO)


I'm sure if the original developer bothered to show up again he could fix it in a weekend.


Figma can handle unlimited amount of screens in one huge canvas


> very crash prone

> And a huge memory hog

On the server side or the frontend side?


What we tested is both. It start to choke on Browser and then server side.


Zed sounds desperate, nobody in the world would use Zed as office. Zed is a niche. Nobody wants it's multiplayer features since coding id usually asynchronous until crunch happens and nobody wants crunch All the time. All office have their own communication tools , you can't expect all developers just to use zed l, it is missing features and the whole ecosystem which would take one more decade and non development people won't even touch it. Then the office cannot happen inside Zed for the rest of the world, except Zed team.


Or Fishy?


Bruno is quite good with postman compatibility and it's own syntax


Not better at all, we don't need flashy UI, we need better content focus


Yeah definitely AI


Check Litestart if you want a Fullstack Async Experience for HTMX. https://litestar.dev/


So much drama there too, but it's designed to attract drmas


Drama has killed the technological progress in open source, if you ask me.

Having seen what goes on in the foss world and what goes on in the large faang-size corporate world, no wonder the corporate world is light-years ahead.


It is a fundamental constraint of consensus based organizations. You need hierarchy to move faster but that has other disadvantages.


You don't need hierarchy, but you need some sort of process. "Consensus-based" just means that the loudest and most enduring shouters get their way, and when their way fails spectacularly, they leave in a huff (taking their work with them, badmouthing the project, and likely starting a fork that will pull more people out of the project and confuse potential users who just bail on trying either.)

Those people need to be pushed out early and often. That's what voting is for. You need a supermajority to force an end to discussion, and a majority to make a decision. If you hold up the discussion too long with too slim a minority, the majority can fork your faction out of the group. If the end of debate has been forced, and you can't work with the majority, you should leave yourself.

None of this letting the bullies get their way until everything is a disaster, then splitting up anyway stuff.


Hah. Naive take. I especially love this “Those people need to be pushed out early and often. That's what voting is for. You need a supermajority to force an end to discussion, and a majority to make a decision”. We know what needs to be done, but it’s not being done. There’s no consensus. Consensus take time and effort and has a lot of friction. I am part of a coop and I have seen first hand how this goes. And it’s fine, consensus based systems have other advantages, but they move slower that hierarchies.


I can recall a distinct time period where us ssb devs were passing around the url to "The Tyranny of Structurelessness" via local-first encrypted direct messages. The essay helped us understand what was happening but alas we did not have the tools to stop it happening to us!


Nah, it is not.

The core of the issue is that drama is a way to impose your views of the world.

In foss software you quite literally don’t have to agree. You can fork the software and walk your own path. You can even pull changes from the original codebase, most licenses allow that.

Consensus is only necessary if you care about imposing your views of the world onto others.


And NASA shutdown


Don’t Look Up!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: