For the doubters replying here, Codeberg really is on average faster than GitHub. It's great. Objective measurements here: https://forgeperf.org/
Codeberg does suffer from the occasional DDOS attack—it doesn't have the resources that GH has to mitigate these sorts of things. Also, if you're across the pond, then latency can be a bit of an issue. That said, the pages are lighter weight, and on stable but low-bandwith connections, Codeberg loads really quickly and all the regular operations are supper zippy.
What I think after looking at these numbers is that we need to take the nuclear option - a native (no web stack at all) code review client. Seconds (times 100 or so for one larger review) are not in any way an acceptable order of magnitude to discuss performance of a front-end for editing tens of kilobytes of text. And the slow, annoying click orgy to fold out more common code, a misfeature needed just to work around loading syntax-highlighted text being insanely slow. Git is very fast, text editing is very fast, bullshit frameworks are slow.
I don't think that it would take great contortions to implement a HTML + JS frontend that's an order of magnitude faster than the current crapola, but in practice it... just doesn't seem to happen.
Fast? I clicked on a random ebuild, then clicked history... the page took over 60 seconds to load a single commit. I could have done that faster locally, or even on github. /shrug
Codeberg was down for several hours over this past weekend. I want an alternative to GitHub as much as the next anti-big tech nerd, but let's not spread false narratives. Codeberg's uptime is probably a single nine right now, at best.
I mean… GitHub's uptime story has been getting worse…
I hear you and you're right that Codeberg has some struggles. If anyone needs to host critical infra, you're better off self-hosting a Forgejo instance. For personal stuff? Codeberg is more than good enough.
it may be a rock and a hard place situation; they need the resources to address these issues but folks aren't gonna move their giant, mission-critical code there if they don't address these issues.
For the doubters replying here, Codeberg really is on average faster than GitHub. It's great. Objective measurements here: https://forgeperf.org/
Codeberg does suffer from the occasional DDOS attack—it doesn't have the resources that GH has to mitigate these sorts of things. Also, if you're across the pond, then latency can be a bit of an issue. That said, the pages are lighter weight, and on stable but low-bandwith connections, Codeberg loads really quickly and all the regular operations are supper zippy.
What I think after looking at these numbers is that we need to take the nuclear option - a native (no web stack at all) code review client. Seconds (times 100 or so for one larger review) are not in any way an acceptable order of magnitude to discuss performance of a front-end for editing tens of kilobytes of text. And the slow, annoying click orgy to fold out more common code, a misfeature needed just to work around loading syntax-highlighted text being insanely slow. Git is very fast, text editing is very fast, bullshit frameworks are slow.
I don't think that it would take great contortions to implement a HTML + JS frontend that's an order of magnitude faster than the current crapola, but in practice it... just doesn't seem to happen.
Fast? I clicked on a random ebuild, then clicked history... the page took over 60 seconds to load a single commit. I could have done that faster locally, or even on github. /shrug
Codeberg was down for several hours over this past weekend. I want an alternative to GitHub as much as the next anti-big tech nerd, but let's not spread false narratives. Codeberg's uptime is probably a single nine right now, at best.
I mean… GitHub's uptime story has been getting worse…
I hear you and you're right that Codeberg has some struggles. If anyone needs to host critical infra, you're better off self-hosting a Forgejo instance. For personal stuff? Codeberg is more than good enough.
it may be a rock and a hard place situation; they need the resources to address these issues but folks aren't gonna move their giant, mission-critical code there if they don't address these issues.