7 ms·

Migrating Dillo from GitHub

423 points by todsacerdoti 11mo ago

superkuh 11mo ago
>frontend barely works without JavaScript, ... In the past, it used to gracefully degrade without enforcing JavaScript, but now it doesn't. And the github frontend developers are aware of these accessibility problems (via the forums and bug reports). They just don't care anymore. They just want to make the site appear to work at first glance which is why index pages are actual text in html but nothing else is.
- egorfine 11mo ago
  Fixing accessibility problems won't make shareholders happy while forcing AI down our throats will.
- baiwl 11mo ago
  Having to enable javascript to see a website is not an accessibility problem according to WCAG.
  - marginalia_nu 11mo ago
    It is a very real accessibility problem if you're using Dillo, which does not support javascript.
    - llbbdd 11mo ago
      it's also a real accessibility problem if you're trying to use sticks and rocks to access the internet
      - marginalia_nu 11mo ago
        This is in the context of where that web browser is hosted, so it's quite relevant.
      - venturecruelty 11mo ago
        Why should you need JavaScript to render text and buttons? Were browsers unable to do this prior to the JavaScriptification of everything?
        yeasku 11mo ago
        The same reason you need to use LLMs to code.
        llbbdd 11mo ago
        Do you copy and paste every comment you make on HN or is this just for me?
        yeasku 11mo ago
        Imagine.
        llbbdd 11mo ago
        It has been, this year, 30 years since JS became a normal part of the web. You don't need it to render text and buttons, but we do different things with the internet now.
  - superkuh 11mo ago
    There's 'enabling javascript' and then there's 'requiring a javascript VM with bleeding edge features basically only found 3 browsers'.
- simonw 11mo ago
  I'd love to hear the inside story of GitHub's migration of their core product features to React. It clearly represents a pretty seismic cultural change within the company. GitHub was my go-to example of a sophisticated application that loaded fast and didn't require JavaScript for well over a decade. The new React stuff is sluggish even on a crazy fast computer. My guess is that the "old guard" who made the original technical decisions all left, and since it's been almost impossible to hire a frontend engineer since ~2020 or so that wasn't a JavaScript/React-first developer the weight of industry fashion became too much to resist. But maybe I'm wrong and they made a technical decision to go all-in on heavy JavaScript features that was reasoned out by GitHub veterans and accompanied by rock solid technical justification. GitHub have been very transparent about their internal technical decisions in the past. I'd love to see them write about this transition.
  - simonw 11mo ago
    In answer to my own question about in-depth decision making, I just found this presentation from February 2025 by seven-year GitHub veteran Joel Hawksley: https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-architecture-at-github.html https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-a... Relevant quote: > But beyond accessibility and availability, there is also a growing expectation of GitHub being more app-like. > The first case of this was when we rebuilt GitHub projects. Customers were asking for features well beyond our existing feature set. More broadly, we are seeing other companies in our space innovate with more app-like experiences. > Which has led us to adoption React. While we don’t have plans to rewrite GitHub in React, we are building most new experiences in React, especially when they are app-like. > We made this decision a couple of years ago, and since then we’ve added about 250 React routes that serve about half of the average pages used by a given user in a week. It then goes on to talk about how mobile is the new baseline and GitHub needed to build interfaces that felt more like mobile apps. (Personally I think JavaScript-heavy React code is a disaster on mobile since it's so slow to load on the median (Android) device. I guess GitHub's core audience are more likely to have powerful phones?)
    - blibble 11mo ago
      github is a tool used where code is written: on desktop computers no-one cares about the github mobile experience microsoft making the windows 8 mistake all over again
- bob1029 11mo ago
  https://github.com/orgs/community/discussions/62372#discussioncomment-7264470 https://github.com/orgs/community/discussions/62372#discussi...
  - superkuh 11mo ago
    It's 1 step forward 2 steps back with this "server side rendering" framing of the issue and in practice observing Microsoft Github's behaviors. They'll temporarily enable text on the web pages of the site in response to accessibility issues then a few months later remove it on that type of page and even more others. As that thread and others I've participated in show this is a losing battle. Microsoft Github will be javascript application only in the end. Human people should consider moving their personal projects accordingly. For work, well one often has to do very distasteful and unethical things for money. And github is where the money is.
- venturecruelty 11mo ago
  To be fair, the developers might care, but upper management certainly doesn't, and they're the ones who decide if those developers make their rent this month.
the__alchemist 11mo ago
We are in the disapora phase; there is a steady stream of these announcements, each with a different GitHub alternative. I speculate that within a few months, the communities will have settled on a single dominant one. I'm curious if it will be one of the existing ones, or something new. Perhaps a well-known company or individual will announce one; it will have good marketing, and dominate.
- dewey 11mo ago
  This has been going on for a decade, at the beginning it was projects moving to Gitlab now there's a lot of alternative projects but GitHub is still the only one that counts for discoverability. This is a very small minority of projects that move away from Github and it's way too early to declare GitHub doomed.
  - hk1337 11mo ago
    No different than everyone talking about the next “iPhone Killer” when someone other than Apple releases a phone. Although, I think that rhetoric has largely died down.
  - CuriouslyC 11mo ago
    Github is fine for discoverability but as a development platform I think it's going to die. Public issues/PRs are a cesspool now and going to get worse, and agentic workflows are going to drive companies to want to hide how the sausage is made. People will gradually migrate to alternatives and mirror to Github while it remains relevant.
    - dewey 11mo ago
      I’d guess most revenue comes from enterprise accounts which are not public.
    - arp242 11mo ago
      I always stayed with GitHub because it just worked the best. GitLab was slow and janky. gitea and its various forks lacked features and felt a step backwards. Sourcehut workflow is far too opinionated for my liking. Don't even get me started on GNU Savannah. Some parts of the Free Software/Open Source crowd has always bemoaned the rise of GitHub, "because obviously you should use Free Software, its your ethical duty!" Most people just use what works best, including many Free Software devs. There is a loud minority (even louder in bubbles like HN) but for most people it's just one factor out of many, at best. The reason GitHub became dominant is fairly simply: it just worked the best. Doesn't mean it was perfect (remember how long it took for line numbers to not be copied from code examples?) but the alternatives were even worse. It's interesting to see how badly they're messing it up. You'd think that making a new react-based frontend for a fairly uncomplicated issue tracker wouldn't be too hard, but seems like it is. Some initial bugs after a rewrite are normal, but ... it's been a year? I still regularly just see closed issues in my issue overview. The back button is basically just broken. These are not obscure heisenbugs: these are bugs you find after using it for five minutes. The entire experience is just so janky. I don't think Github is dying at this moment. I do think that the regression of UX quality is a necessary pre-condition for its death. Like many things its death will happen "very gradually, and then suddenly all at once". Sourceforge once seemed omnipresent and that changed very quickly.[1] But who knows where things will end up in five or ten years? [1]: I'd like to pre-empt the inevitable "that's because of the adware" comment that someone always seems to post: that's a false history. The adware happened well after it already lost its position and was the desperate attempt of a declining struggling platform for income.
ksec 11mo ago
>The most annoying problem is that the frontend barely works without JavaScript, Not only did they spend years rewriting the frontend from Pjax to I think React? They also manage to lost customer because of it.
- SoKamil 11mo ago
  GitHub frontend is mostly still their own [1] Web Components based library. They use Turbo to do client side reloading. They have small islands of React based views like Projects view or reworked Pull Request review. The thing is, even if you disable JavaScript, sites still load sloow. Try it yourself. Frontend code doesn’t seem to be the bottleneck. [1] https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...
xrd 11mo ago
I've been messing around with GitLab as a self hosted alternative for a few years. I do like it, but it is resource intensive! For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic. The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary. I have been running GitLab for several years (for my own personal use only!) and it regularly slowly starts to use up the entirety of the RAM on a 16GB VM. I have only been playing with Forgejo for a few days, but I am using only 300MB of the 8 GB of RAM I allocated, and that machine is running both the server and a runner (it is idle but...). I'm really excited about Forgejo and dumping GitLab. The biggest difference I can see if that Forgejo does not have GraphQL support, but the REST API seems, at first glance, to be fine. EDIT: I don't really understand the difference between gitea and forgejo. Can anyone explain? I see lots of directories inside the forgejo volume when I run using podman that clearly indicate they are the same under the hood in many ways. EDIT 2: Looks like forgejo is a soft fork in 2022 when there were some weird things that happened to governance of the gitea project: https://forgejo.org/compare-to-gitea/#why-was-forgejo-created https://forgejo.org/compare-to-gitea/#why-was-forgejo-create...
- homebrewer 11mo ago
  Ease of maintenance is an even bigger difference. We've been using gitea for a bit over five years now, and gitlab for a few years before that, and gitea requires no maintenance in comparison. Upgrades come down to pulling the new version and restarting the daemon, and take just a few seconds. It's definitely the best solution for self-hosters who want to spend as little time as possible on their infrastructure. Backups are handled by zfs snapshots (like every other server). We've also had at least 10× lower downtime compared to github over the same period of time, and whatever downtime we had was planned and always in the middle of the night. Always funny reading claims here that github has much better uptime than anything self-hosted from people who don't know any better. I usually don't even bother responding anymore.
  - c-hendricks 11mo ago
    When I self hosted gitlab I never found the maintenance to be that bad, just change a version in a compose.yml, sometimes having to jump between blessed versions if I've missed a few back to back. Like others, I've switch to Gitea, but whenever I do visit gitlab I can't help but think the design / UX is so much nicer.
throwaway150 11mo ago
> Additionally, GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. This model would also allow me to easily work offline. Unfortunately, I see that the same push model has been copied to alternative forges. Someone kind enough to explain this to me? What's the difference between push model and pull model? What about push model makes it difficult to work offline?
- bayindirh 11mo ago
  AFAIK, the author wants to work like how Source Hut and Linux kernel works: by e-mails. When you're working with e-mails, you sync your relevant IMAP box to local, pulling all the proposed patches with it, hence the pull model. Then you can work through the proposed changes offline, handle on your local copy and push the merged changes back online.
  - throwaway150 11mo ago
    All of this makes sense. Thank you for explaining. I don't think I understand the difference though. Like are they calling the "GitHub pull request" workflow as the push model? What is "push" about it though? I can download all the pull request patches to my local and work offline, can't I?
    - bayindirh 11mo ago
      GitHub pull request pushes you a notification/e-mail to handle the merge, and you have to handle the pull request mostly online. I don't know how you can download the pull request as a set of patches and work offline, but you have to open a branch, merge the PR to that branch, test the things and merge that branch to relevant one. Or you have to download the forked repository, do your tests to see the change is relevant/stable whatnot and if it works, you can then merge the PR. --- edit: Looks like you can get the PR as a patch or diff, and is trivial, but you have to be online again to get it that way. So, getting your mails from your box is not enough, you have to get every PR as a diff, with a tool or manually. Then you have to organize them. e-mails are much more unified and simple way to handle all this. --- In either case, reviewing the changes is not possible when you're offline, plus the pings of the PRs is distracting, if your project is popular.
WD-42 11mo ago
> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. The hacker spirit alive and well.
- tclancy 11mo ago
  For better and for worse.
- rs186 11mo ago
  That is an approach very few people would take. I would never do it, as I am sure it would cause me trouble than any potential benefit.
  - WD-42 11mo ago
    That’s ok. Not everyone can be a chad C developer.
- rafaelgoncalves 11mo ago
  got here to comment on that, hella impressive and looks so simple and clean.
- SuperSandro2000 11mo ago
  No one should write C software in 2025...
icy 11mo ago
We’d love to have the Dillo project on Tangled! ;) https://tangled.org https://tangled.org
- toastal 11mo ago
  I wish Tangled supported alternatives to Git
  - throw-qqqqq 11mo ago
    Just curious, what are you using instead of git, and why? :)
    - toastal 11mo ago
      Darcs & Pijul as the Patch Theory-based approach eliminates an entire class of merge conflicts which make working in a distributed manner more feasible. These DVCS have good (subjectively “better”) foundations & need better tooling like forges—unlike Git that already has a ton of things to choose from.
  - kragen 11mo ago
    Darcs? Fossil? Subversion?
    - lioeters 11mo ago
      On their home page they have links to some repositories (or equivalent term) on a couple of Darcs hosts. https://hub.darcs.net https://hub.darcs.net https://smeder.ee https://smeder.ee Here's a recent discussion about Darcs, it's the first I've heard of it. Darcs, Friendly Version Control - https://news.ycombinator.com/item?id=43022059 https://news.ycombinator.com/item?id=43022059 (9 months ago | 76 comments)
      - toastal 11mo ago
        Darcs is older than Git
beanjuiceII 11mo ago
[flagged]
- bayindirh 11mo ago
  Dillo is a 25 year old project some of us know very well and use. Obscurity is subjective. It might be obscure for you, and that's OK, but Dillo is not obscure for many people.
- anthk 11mo ago
  Obscure? Dillo has been alive more time than tons of HN users.
- Idesmi 11mo ago
  Dillo is very cool and the blog post says more than «I moved away from Github.» It's actually quite interesting, I recommend to read it!
jmclnx 11mo ago
To me, this sounds like a good change. And FWIW, I an finding I am using dillo more and more these days. I went to gitlab from github due to Microsoft changes, my needs are very simple so far gitlab seems OK. I also mirror just the current source on sdf.org via gopher. If gitlab causes issues this could very well become my main site.
potato-peeler 11mo ago
I hope you will continue maintaining a mirror in GH. Some tools like deepwiki are excellent resources to learn about a codebase when their is not much documentation going around. But these tools only support pulling from GH.
- tayo42 11mo ago
  How is pulling dependent on github? Git pulling isn't unique to github and it works over http or ssh?
  - speakingmoistly 11mo ago
    It's less about pulling and more about tools like DeepWiki making the assumption that its inputs live in GitHub, so repository URLs are expected to be GH URLs as opposed to a URL to a git repository anywhere. That being said, there's no reason for tools like it to have those constraints other than pushing users into an ecosystem they prefer (i.e. GitHub instead of other forges).
  - simonw 11mo ago
    A neat thing about GitHub is that every file on it can be accessed from URLs like https://raw.githubusercontent.com/simonw/llm-prices/refs/heads/main/data/openai.json https://raw.githubusercontent.com/simonw/llm-prices/refs/hea... which are served through a CDN with open CORS headers - which means any JavaScript application running anywhere can access them. Demo: https://tools.simonwillison.net/cors-fetch?url=https%3A%2F%2Fraw.githubusercontent.com%2Fsimonw%2Fllm-prices%2Frefs%2Fheads%2Fmain%2Fdata%2Fopenai.json https://tools.simonwillison.net/cors-fetch?url=https%3A%2F%2...
    - avhon1 11mo ago
      That feature seems common to other git hosts / forges. For example, here's one of Dillo's files, from a few commits ago, from their cgit-based host https://git.dillo-browser.org/dillo/plain/src/ui.cc?id=29a46a2da7e9350a1252e30aea3c8294097f63a4 https://git.dillo-browser.org/dillo/plain/src/ui.cc?id=29a46...
0x696C6961 11mo ago
> On the usability side, the platform has become more and more slow over time The best reason right here.
- mrj 11mo ago
  For real. I've been hearing the interface is slow and requires Javascript for years and never really paid much mind, it worked for me. But lately the page loading has gotten abusively slow. I don't think it can be simply blamed on React because that move was made long before this started. I've taken to loading projects in github.dev for navigating repos so I pay the js tax just once and it's fine for code reading. But navigating PRs and actions is terrible.
- emfrosztovis 11mo ago
  Off-topic, but as a non-native speaker I’m curious if it’s common to say “more and more slow” as opposed to “slower and slower” (maybe to emphasize the adjective?)
  - hahn-kev 11mo ago
    Slower and slower is more natural to my ear. More and more slow sounds weird.
  - bigstrat2003 11mo ago
    For me (native speaker), I would say "more slow" is incorrect grammar no matter how you use it, though people will know what you mean. So you should say "slower and slower".
    - Brian_K_White 11mo ago
      But a writer may use the construct for style reasons. ex: "Vaster than empires, and more slow." I think it's just not actually technically wrong in the first place, merely uncommon because it's a little awkward. What makes it ok is it can be used deliberately to build imagery or to intentionally trigger thought because you have to stop to parse it. What makes it "wrong" is exactly that having to stop to parse it. It's obfuscated meaning to say "increase the decrease". A decrease is a property that may be increased, so it's legal, but you have to stop to puzzle it out rather than know what it means instantly without thought.
jrochkind1 11mo ago
I didn't know about forgejo, it looks pretty nice.
- ramon156 11mo ago
  Forgejo is what codeberg runs on, which imo is an awesome alternative to github
Fnoord 11mo ago
A good reason to move away from GitHub is it is from Microsoft (FAMAG; a company who kissed Trump's ring). Sourcehut is hosted in The Netherlands, and Codeberg in Germany.
- hk1337 11mo ago
  What would be nice is an aggregator site one could submit to and everyone just host it on their own internet connection, and nobody be dependent on a source for hosting their projects. Maybe something like bluesky with the AT protocol but with git repositories.
  - Fnoord 11mo ago
    For just text there's Usenet, Freenet, Mastodon. Though these work for more than merely text. I suppose something like this with git and source code exists on Tor. During the Arab Spring and Hong Kong protests, Bluetooth was used to share messages whilst the internet was cut off.
  - ireadmevs 11mo ago
    There’s Tangled[0], but I don’t have personal experience with it. [0]: https://tangled.org/ https://tangled.org/
    - hk1337 11mo ago
      Actually, they does seem to be almost exactly what I was thinking. Thanks.
  - touggourt 11mo ago
    Have a look to [Fossil](https://fossil-scm.org/ https://fossil-scm.org/) which is very easy to host and offer code repository, bug tracker, wiki, forum, etc. It is not Git however, but there is bridges and one can even mirror a Fossil repo to Github.
deleted 11mo ago
[deleted]
picafrost 11mo ago
Excellent. I hope to see more of it. Another social issue on GitHub: you cannot use the "good first issue" tag on a public repository without being subjected to low quality drive-by PRs or AI slop automatically submitted by someone's bot. I think the issue with centralization is still understated. I know developers who seem to struggle reading code if it's not presented by VS Code or a GitHub page. And then, why not totally capture everyone into developing just with GitHub Codespaces? This is exactly what well-intentioned folk like to see: it's solving everyone's problems! Batteries included, nothing else is needed! Why use your own machine or software that doesn't ping into a telemetry hell-hole of data collection on a regular basis?
ramon156 11mo ago
> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. I love this. I used to be a big fan of linear (because the alternatives were dog water), but this also opened the question "why even have a seperate, disconnected tool?" Most of my personal projects have a TODO.md somewhere with a list of things i need to work on. If people really need a frontend for bugs, it wouldn't be more than just rendering that markdown on the web.
- mystifyingpoi 11mo ago
  > As it is simply plain text Well, if your bugs can be specified clearly in plain text and plain text only, then yeah, I'd also advocate for this approach. Unfortunately, that's not really the case in any bigger software project. I need screenshots, video recordings that are 100 megs, cross-issue linking etc. I hate JIRA (of course) but it gets it right.
  - captn3m0 11mo ago
    Even in the case of Dillo, the migrated bugs from GitHub include ZIP files (that are still hosted on GitHub): https://bug.dillo-browser.org/50/ https://bug.dillo-browser.org/50/
  - jbaber 11mo ago
    We can enter e-mail's h*ll and just have attachments be base64 blobs.
  - ramon156 11mo ago
    Sure, for personal stuff i mostly remember the issue. I can even provide which code snippet it is. For communicating with others that wouldn't fly
iveqy 11mo ago
Seems as a good idea to pitch git-appraise https://github.com/google/git-appraise https://github.com/google/git-appraise I'm not part of the project at all, but this is the only offline code review system I've found.
wkoszek 11mo ago
If anyone wants to add Forgejo to your VM, I made a script that allows you to quickly install server + runner, so you get the full setup: https://wkoszek.github.io/easyforgejo/ https://wkoszek.github.io/easyforgejo/
Kwpolska 11mo ago
> GitHub has been useful to store all repositories of the Dillo project, as well as to run the CI workflows for platforms in which I don't have a machine available (like Windows, Mac OS or some BSDs). The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it? > Furthermore, the web frontend doesn't require JS, so I can use it from Dillo (I modified cgit CSS slightly to work well on Dillo). That sounds like a bad approach to developing a Web browser, surely it would be better to make Dillo correctly work with the default cgit CSS (which is used by countless projects)?
- avhon1 11mo ago
  No doubt this is desirable. However, adding all the CSS features required to support cgit may have been a lot more work than editing cgit's CSS. It's an attempt at avoiding yak shaving; adding recursive sub-projects that balloon a project's scope of work far beyond the original plan. Dillo is actively developed, and the project of "migrate away from github" is complete, so now other work can be started and completed (like adding the CSS features required to support mainline cgit).
- ocdtrekkie 11mo ago
  This was the part that mystified me. Love it or hate it, GitHub Actions is free. Alternative providers like Codeberg have much tighter limits on it, and it sounds unlikely the author's solution includes CI at all.
- rodarima 11mo ago
  > The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it? Yes, we have our own CI service. It is not public for now.
deleted 11mo ago
[deleted]
zzo38computer 11mo ago
There are ways around some of the issues there, such as using the GitHub API (I almost exclusively use the API), and/or using a user script (see below). Furthermore, on GitHub and on some other version control hosting services (such as GitLab), you can change "blob" to "raw" in the URL to access the raw files. However, as they say, it can be mirrored on multiple services (including self-hosting), and this would be a good idea, whether or not you use GitHub, so if you do not like GitHub then you do not have to use it. Note that for some of the web pages on GitHub, the data is included as JSON data within the HTML file, although this schema is undocumented and sometimes changes. User scripts (which you might have to maintain due to these changes) can be used to display the data without any additional downloads from the server, and they can be much shorter and faster than GitHub's proprietary scripts. Using a GPG key to sign the web page and releases is helpful (for the reasons they explain there), although there are some other things that might additionally help (if the conspiracy was not making it difficult to do these things with X.509 certificates in many ways).
throwfaraway135 11mo ago
Although I'm not a fan of GH, I appreciate the ability to see how popular/valid some project is by looking at the number of stars (I know this is far from a perfect signal). I'm much less likely to try projects that have a low number of stars, or projects in different places.
- ocdtrekkie 11mo ago
  One of the things Forgejo has been working on is federation, such that hopefully someday we can replicate the discoverability of GitHub without a central provider.
- 59nadir 11mo ago
  God forbid we'd have to actually look at the code itself to figure out whether something is good.
  - monooso 11mo ago
    GP explicitly stated that they use stars to determine the popularity of a repository, not the code quality.
president_zippy 11mo ago
I freely admit I am out of my depth and have nothing educational to add on the subject. I have but four things to add on this subject: 1. Oh! It's "d.i.l.l.o."! I misread that as something else. 2. After reading many comments in this thread, I must admit I am stupefied at the sheer amount of stuff that can go into merely setting up and maintaining a version control system for a project. 3. I have cited every one of the same problems OP enumerates as my argument for switching new projects over to self-hosted fossil. It also helps a good bit with #2 above when you're a small organization and you're the sole software engineer, sysadmin, and tier >1 support. It's a much simpler VCS that's closer to using perforce in my experience. YMMV, but it's the kind of VCS that doesn't qualify as a skill on a resume. 4. I also find GH deploy keys frustrating because I can't use the same key for multiple repositories. I have 3 separate applications that each run on 4 machines in my cluster, and I have to configure 12 separate deploy keys on GitHub and in my ~/.ssh/config file.
layer8 11mo ago
> GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. I agree with the sentiment, but want to point out that email can be used to turn push into pull, by auto-filtering the respective email notifications into a separate dedicated email folder, which you can choose to only look at when you want.
- paulddraper 11mo ago
  And if that’s unsatisfactory, GitHub has its own notifications part of the UI. This is in search of a problem.
asdfman123 11mo ago
Nice! Finding new places to stick a Dillo into.
einpoklum 11mo ago
So, the first and foremost reason: > the [GitHub] frontend barely works without JavaScript, so we cannot open issues, pull requests, source code or CI logs in Dillo itself, despite them being mostly plain HTML because Dillo is a simple browser without a JS engine. And that is a perfectly valid reason to leave GitHub.
zzzeek 11mo ago
> This is specially problematic when active issues with developer notes begin to be filled with comments from users that have never contributed to the project and usually do more harm than good. This situation ends up causing burnout in developers. This is a huge with github and I would desperately want a github where issues are visible, but the ability to create or modify them is STRICTLY locked down to project members, and non members can only post Discussions for problems. I really prefer that I write the issue(s) based an "intake discussion" so to speak.
jeffjeffbear 11mo ago
I run a math circle in my area, and use forgejo with kids for thier solutions in Latex and python, it works great for me, and is super easy to enforce logins and reset passwords.
zombot 11mo ago
> it is a single point of failure. I don't mean that GitHub is stored in a single machine, but it is controlled by a single entity which can unilateraly ban our repository or account Besides the usability problems with bloated MS Shitware, this is a strategic point that I see considered far too rarely for my taste.
shevy-java 11mo ago
Isn't there one 'd' missing ... As for gitlab versus github: I understand that gitlab may have more features and thus options, but I can't stand its default UI. Every time I use it I am annoyed compared to the github variant. Perhaps gitlab is nicer to have for teams, but from a user's perspective, I feel gitlab is worse than github (UI-wise primarily).
account42 11mo ago
Always nice to see a project moving to self-hosted git repos rather than the other direction.
jbaviat 11mo ago
How about using tor to help with DNS redundancy? https://en.wikipedia.org/wiki/Tor_(network) https://en.wikipedia.org/wiki/Tor_(network)
a96 11mo ago
https://sfconservancy.org/GiveUpGitHub/ https://sfconservancy.org/GiveUpGitHub/
RNCTX 11mo ago
In the same post where the author of this blog article says they "don't like getting notifications about activity in my repo, and instead prefer to 'work offline' and 'only check in when I want' to... the author also details how they lost their domain which was bought by an ad spamming site guy. I mean, are the scripts writing themselves here, boys?
SuperSandro2000 11mo ago
How to contribute? Just not at all?

423 points by todsacerdoti 11mo ago

>frontend barely works without JavaScript, ... In the past, it used to gracefully degrade without enforcing JavaScript, but now it doesn't. And the github frontend developers are aware of these accessibility problems (via the forums and bug reports). They just don't care anymore. They just want to make the site appear to work at first glance which is why index pages are actual text in html but nothing else is.

egorfine 11mo ago
Fixing accessibility problems won't make shareholders happy while forcing AI down our throats will.
baiwl 11mo ago
Having to enable javascript to see a website is not an accessibility problem according to WCAG.
- marginalia_nu 11mo ago
  It is a very real accessibility problem if you're using Dillo, which does not support javascript.
  - llbbdd 11mo ago
    it's also a real accessibility problem if you're trying to use sticks and rocks to access the internet
    - marginalia_nu 11mo ago
      This is in the context of where that web browser is hosted, so it's quite relevant.
    - venturecruelty 11mo ago
      Why should you need JavaScript to render text and buttons? Were browsers unable to do this prior to the JavaScriptification of everything?
      - yeasku 11mo ago
        The same reason you need to use LLMs to code.
        llbbdd 11mo ago
        Do you copy and paste every comment you make on HN or is this just for me?
        yeasku 11mo ago
        Imagine.
      - llbbdd 11mo ago
        It has been, this year, 30 years since JS became a normal part of the web. You don't need it to render text and buttons, but we do different things with the internet now.
- superkuh 11mo ago
  There's 'enabling javascript' and then there's 'requiring a javascript VM with bleeding edge features basically only found 3 browsers'.
simonw 11mo ago
I'd love to hear the inside story of GitHub's migration of their core product features to React. It clearly represents a pretty seismic cultural change within the company. GitHub was my go-to example of a sophisticated application that loaded fast and didn't require JavaScript for well over a decade. The new React stuff is sluggish even on a crazy fast computer. My guess is that the "old guard" who made the original technical decisions all left, and since it's been almost impossible to hire a frontend engineer since ~2020 or so that wasn't a JavaScript/React-first developer the weight of industry fashion became too much to resist. But maybe I'm wrong and they made a technical decision to go all-in on heavy JavaScript features that was reasoned out by GitHub veterans and accompanied by rock solid technical justification. GitHub have been very transparent about their internal technical decisions in the past. I'd love to see them write about this transition.
- simonw 11mo ago
  In answer to my own question about in-depth decision making, I just found this presentation from February 2025 by seven-year GitHub veteran Joel Hawksley: https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-architecture-at-github.html https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-a... Relevant quote: > But beyond accessibility and availability, there is also a growing expectation of GitHub being more app-like. > The first case of this was when we rebuilt GitHub projects. Customers were asking for features well beyond our existing feature set. More broadly, we are seeing other companies in our space innovate with more app-like experiences. > Which has led us to adoption React. While we don’t have plans to rewrite GitHub in React, we are building most new experiences in React, especially when they are app-like. > We made this decision a couple of years ago, and since then we’ve added about 250 React routes that serve about half of the average pages used by a given user in a week. It then goes on to talk about how mobile is the new baseline and GitHub needed to build interfaces that felt more like mobile apps. (Personally I think JavaScript-heavy React code is a disaster on mobile since it's so slow to load on the median (Android) device. I guess GitHub's core audience are more likely to have powerful phones?)
  - blibble 11mo ago
    github is a tool used where code is written: on desktop computers no-one cares about the github mobile experience microsoft making the windows 8 mistake all over again
bob1029 11mo ago
https://github.com/orgs/community/discussions/62372#discussioncomment-7264470 https://github.com/orgs/community/discussions/62372#discussi...
- superkuh 11mo ago
  It's 1 step forward 2 steps back with this "server side rendering" framing of the issue and in practice observing Microsoft Github's behaviors. They'll temporarily enable text on the web pages of the site in response to accessibility issues then a few months later remove it on that type of page and even more others. As that thread and others I've participated in show this is a losing battle. Microsoft Github will be javascript application only in the end. Human people should consider moving their personal projects accordingly. For work, well one often has to do very distasteful and unethical things for money. And github is where the money is.
venturecruelty 11mo ago
To be fair, the developers might care, but upper management certainly doesn't, and they're the ones who decide if those developers make their rent this month.

the__alchemist 11mo ago

We are in the disapora phase; there is a steady stream of these announcements, each with a different GitHub alternative. I speculate that within a few months, the communities will have settled on a single dominant one. I'm curious if it will be one of the existing ones, or something new. Perhaps a well-known company or individual will announce one; it will have good marketing, and dominate.

dewey 11mo ago
This has been going on for a decade, at the beginning it was projects moving to Gitlab now there's a lot of alternative projects but GitHub is still the only one that counts for discoverability. This is a very small minority of projects that move away from Github and it's way too early to declare GitHub doomed.
- hk1337 11mo ago
  No different than everyone talking about the next “iPhone Killer” when someone other than Apple releases a phone. Although, I think that rhetoric has largely died down.
- CuriouslyC 11mo ago
  Github is fine for discoverability but as a development platform I think it's going to die. Public issues/PRs are a cesspool now and going to get worse, and agentic workflows are going to drive companies to want to hide how the sausage is made. People will gradually migrate to alternatives and mirror to Github while it remains relevant.
  - dewey 11mo ago
    I’d guess most revenue comes from enterprise accounts which are not public.
  - arp242 11mo ago
    I always stayed with GitHub because it just worked the best. GitLab was slow and janky. gitea and its various forks lacked features and felt a step backwards. Sourcehut workflow is far too opinionated for my liking. Don't even get me started on GNU Savannah. Some parts of the Free Software/Open Source crowd has always bemoaned the rise of GitHub, "because obviously you should use Free Software, its your ethical duty!" Most people just use what works best, including many Free Software devs. There is a loud minority (even louder in bubbles like HN) but for most people it's just one factor out of many, at best. The reason GitHub became dominant is fairly simply: it just worked the best. Doesn't mean it was perfect (remember how long it took for line numbers to not be copied from code examples?) but the alternatives were even worse. It's interesting to see how badly they're messing it up. You'd think that making a new react-based frontend for a fairly uncomplicated issue tracker wouldn't be too hard, but seems like it is. Some initial bugs after a rewrite are normal, but ... it's been a year? I still regularly just see closed issues in my issue overview. The back button is basically just broken. These are not obscure heisenbugs: these are bugs you find after using it for five minutes. The entire experience is just so janky. I don't think Github is dying at this moment. I do think that the regression of UX quality is a necessary pre-condition for its death. Like many things its death will happen "very gradually, and then suddenly all at once". Sourceforge once seemed omnipresent and that changed very quickly.[1] But who knows where things will end up in five or ten years? [1]: I'd like to pre-empt the inevitable "that's because of the adware" comment that someone always seems to post: that's a false history. The adware happened well after it already lost its position and was the desperate attempt of a declining struggling platform for income.

ksec 11mo ago

>The most annoying problem is that the frontend barely works without JavaScript, Not only did they spend years rewriting the frontend from Pjax to I think React? They also manage to lost customer because of it.

SoKamil 11mo ago
GitHub frontend is mostly still their own [1] Web Components based library. They use Turbo to do client side reloading. They have small islands of React based views like Projects view or reworked Pull Request review. The thing is, even if you disable JavaScript, sites still load sloow. Try it yourself. Frontend code doesn’t seem to be the bottleneck. [1] https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...

xrd 11mo ago

I've been messing around with GitLab as a self hosted alternative for a few years. I do like it, but it is resource intensive! For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic. The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary. I have been running GitLab for several years (for my own personal use only!) and it regularly slowly starts to use up the entirety of the RAM on a 16GB VM. I have only been playing with Forgejo for a few days, but I am using only 300MB of the 8 GB of RAM I allocated, and that machine is running both the server and a runner (it is idle but...). I'm really excited about Forgejo and dumping GitLab. The biggest difference I can see if that Forgejo does not have GraphQL support, but the REST API seems, at first glance, to be fine. EDIT: I don't really understand the difference between gitea and forgejo. Can anyone explain? I see lots of directories inside the forgejo volume when I run using podman that clearly indicate they are the same under the hood in many ways. EDIT 2: Looks like forgejo is a soft fork in 2022 when there were some weird things that happened to governance of the gitea project: https://forgejo.org/compare-to-gitea/#why-was-forgejo-created https://forgejo.org/compare-to-gitea/#why-was-forgejo-create...

homebrewer 11mo ago
Ease of maintenance is an even bigger difference. We've been using gitea for a bit over five years now, and gitlab for a few years before that, and gitea requires no maintenance in comparison. Upgrades come down to pulling the new version and restarting the daemon, and take just a few seconds. It's definitely the best solution for self-hosters who want to spend as little time as possible on their infrastructure. Backups are handled by zfs snapshots (like every other server). We've also had at least 10× lower downtime compared to github over the same period of time, and whatever downtime we had was planned and always in the middle of the night. Always funny reading claims here that github has much better uptime than anything self-hosted from people who don't know any better. I usually don't even bother responding anymore.
- c-hendricks 11mo ago
  When I self hosted gitlab I never found the maintenance to be that bad, just change a version in a compose.yml, sometimes having to jump between blessed versions if I've missed a few back to back. Like others, I've switch to Gitea, but whenever I do visit gitlab I can't help but think the design / UX is so much nicer.

throwaway150 11mo ago

> Additionally, GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. This model would also allow me to easily work offline. Unfortunately, I see that the same push model has been copied to alternative forges. Someone kind enough to explain this to me? What's the difference between push model and pull model? What about push model makes it difficult to work offline?

bayindirh 11mo ago
AFAIK, the author wants to work like how Source Hut and Linux kernel works: by e-mails. When you're working with e-mails, you sync your relevant IMAP box to local, pulling all the proposed patches with it, hence the pull model. Then you can work through the proposed changes offline, handle on your local copy and push the merged changes back online.
- throwaway150 11mo ago
  All of this makes sense. Thank you for explaining. I don't think I understand the difference though. Like are they calling the "GitHub pull request" workflow as the push model? What is "push" about it though? I can download all the pull request patches to my local and work offline, can't I?
  - bayindirh 11mo ago
    GitHub pull request pushes you a notification/e-mail to handle the merge, and you have to handle the pull request mostly online. I don't know how you can download the pull request as a set of patches and work offline, but you have to open a branch, merge the PR to that branch, test the things and merge that branch to relevant one. Or you have to download the forked repository, do your tests to see the change is relevant/stable whatnot and if it works, you can then merge the PR. --- edit: Looks like you can get the PR as a patch or diff, and is trivial, but you have to be online again to get it that way. So, getting your mails from your box is not enough, you have to get every PR as a diff, with a tool or manually. Then you have to organize them. e-mails are much more unified and simple way to handle all this. --- In either case, reviewing the changes is not possible when you're offline, plus the pings of the PRs is distracting, if your project is popular.

WD-42 11mo ago

> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. The hacker spirit alive and well.

tclancy 11mo ago
For better and for worse.
rs186 11mo ago
That is an approach very few people would take. I would never do it, as I am sure it would cause me trouble than any potential benefit.
- WD-42 11mo ago
  That’s ok. Not everyone can be a chad C developer.
rafaelgoncalves 11mo ago
got here to comment on that, hella impressive and looks so simple and clean.
SuperSandro2000 11mo ago
No one should write C software in 2025...

icy 11mo ago

We’d love to have the Dillo project on Tangled! ;) https://tangled.org https://tangled.org

toastal 11mo ago
I wish Tangled supported alternatives to Git
- throw-qqqqq 11mo ago
  Just curious, what are you using instead of git, and why? :)
  - toastal 11mo ago
    Darcs & Pijul as the Patch Theory-based approach eliminates an entire class of merge conflicts which make working in a distributed manner more feasible. These DVCS have good (subjectively “better”) foundations & need better tooling like forges—unlike Git that already has a ton of things to choose from.
- kragen 11mo ago
  Darcs? Fossil? Subversion?
  - lioeters 11mo ago
    On their home page they have links to some repositories (or equivalent term) on a couple of Darcs hosts. https://hub.darcs.net https://hub.darcs.net https://smeder.ee https://smeder.ee Here's a recent discussion about Darcs, it's the first I've heard of it. Darcs, Friendly Version Control - https://news.ycombinator.com/item?id=43022059 https://news.ycombinator.com/item?id=43022059 (9 months ago | 76 comments)
    - toastal 11mo ago
      Darcs is older than Git

beanjuiceII 11mo ago

[flagged]

bayindirh 11mo ago
Dillo is a 25 year old project some of us know very well and use. Obscurity is subjective. It might be obscure for you, and that's OK, but Dillo is not obscure for many people.
anthk 11mo ago
Obscure? Dillo has been alive more time than tons of HN users.
Idesmi 11mo ago
Dillo is very cool and the blog post says more than «I moved away from Github.» It's actually quite interesting, I recommend to read it!

jmclnx 11mo ago

To me, this sounds like a good change. And FWIW, I an finding I am using dillo more and more these days. I went to gitlab from github due to Microsoft changes, my needs are very simple so far gitlab seems OK. I also mirror just the current source on sdf.org via gopher. If gitlab causes issues this could very well become my main site.

potato-peeler 11mo ago

I hope you will continue maintaining a mirror in GH. Some tools like deepwiki are excellent resources to learn about a codebase when their is not much documentation going around. But these tools only support pulling from GH.

tayo42 11mo ago
How is pulling dependent on github? Git pulling isn't unique to github and it works over http or ssh?
- speakingmoistly 11mo ago
  It's less about pulling and more about tools like DeepWiki making the assumption that its inputs live in GitHub, so repository URLs are expected to be GH URLs as opposed to a URL to a git repository anywhere. That being said, there's no reason for tools like it to have those constraints other than pushing users into an ecosystem they prefer (i.e. GitHub instead of other forges).
- simonw 11mo ago
  A neat thing about GitHub is that every file on it can be accessed from URLs like https://raw.githubusercontent.com/simonw/llm-prices/refs/heads/main/data/openai.json https://raw.githubusercontent.com/simonw/llm-prices/refs/hea... which are served through a CDN with open CORS headers - which means any JavaScript application running anywhere can access them. Demo: https://tools.simonwillison.net/cors-fetch?url=https%3A%2F%2Fraw.githubusercontent.com%2Fsimonw%2Fllm-prices%2Frefs%2Fheads%2Fmain%2Fdata%2Fopenai.json https://tools.simonwillison.net/cors-fetch?url=https%3A%2F%2...
  - avhon1 11mo ago
    That feature seems common to other git hosts / forges. For example, here's one of Dillo's files, from a few commits ago, from their cgit-based host https://git.dillo-browser.org/dillo/plain/src/ui.cc?id=29a46a2da7e9350a1252e30aea3c8294097f63a4 https://git.dillo-browser.org/dillo/plain/src/ui.cc?id=29a46...

0x696C6961 11mo ago

> On the usability side, the platform has become more and more slow over time The best reason right here.

mrj 11mo ago
For real. I've been hearing the interface is slow and requires Javascript for years and never really paid much mind, it worked for me. But lately the page loading has gotten abusively slow. I don't think it can be simply blamed on React because that move was made long before this started. I've taken to loading projects in github.dev for navigating repos so I pay the js tax just once and it's fine for code reading. But navigating PRs and actions is terrible.
emfrosztovis 11mo ago
Off-topic, but as a non-native speaker I’m curious if it’s common to say “more and more slow” as opposed to “slower and slower” (maybe to emphasize the adjective?)
- hahn-kev 11mo ago
  Slower and slower is more natural to my ear. More and more slow sounds weird.
- bigstrat2003 11mo ago
  For me (native speaker), I would say "more slow" is incorrect grammar no matter how you use it, though people will know what you mean. So you should say "slower and slower".
  - Brian_K_White 11mo ago
    But a writer may use the construct for style reasons. ex: "Vaster than empires, and more slow." I think it's just not actually technically wrong in the first place, merely uncommon because it's a little awkward. What makes it ok is it can be used deliberately to build imagery or to intentionally trigger thought because you have to stop to parse it. What makes it "wrong" is exactly that having to stop to parse it. It's obfuscated meaning to say "increase the decrease". A decrease is a property that may be increased, so it's legal, but you have to stop to puzzle it out rather than know what it means instantly without thought.

jrochkind1 11mo ago

I didn't know about forgejo, it looks pretty nice.

ramon156 11mo ago
Forgejo is what codeberg runs on, which imo is an awesome alternative to github

Fnoord 11mo ago

A good reason to move away from GitHub is it is from Microsoft (FAMAG; a company who kissed Trump's ring). Sourcehut is hosted in The Netherlands, and Codeberg in Germany.

hk1337 11mo ago
What would be nice is an aggregator site one could submit to and everyone just host it on their own internet connection, and nobody be dependent on a source for hosting their projects. Maybe something like bluesky with the AT protocol but with git repositories.
- Fnoord 11mo ago
  For just text there's Usenet, Freenet, Mastodon. Though these work for more than merely text. I suppose something like this with git and source code exists on Tor. During the Arab Spring and Hong Kong protests, Bluetooth was used to share messages whilst the internet was cut off.
- ireadmevs 11mo ago
  There’s Tangled[0], but I don’t have personal experience with it. [0]: https://tangled.org/ https://tangled.org/
  - hk1337 11mo ago
    Actually, they does seem to be almost exactly what I was thinking. Thanks.
- touggourt 11mo ago
  Have a look to [Fossil](https://fossil-scm.org/ https://fossil-scm.org/) which is very easy to host and offer code repository, bug tracker, wiki, forum, etc. It is not Git however, but there is bridges and one can even mirror a Fossil repo to Github.

deleted 11mo ago

[deleted]

picafrost 11mo ago

Excellent. I hope to see more of it. Another social issue on GitHub: you cannot use the "good first issue" tag on a public repository without being subjected to low quality drive-by PRs or AI slop automatically submitted by someone's bot. I think the issue with centralization is still understated. I know developers who seem to struggle reading code if it's not presented by VS Code or a GitHub page. And then, why not totally capture everyone into developing just with GitHub Codespaces? This is exactly what well-intentioned folk like to see: it's solving everyone's problems! Batteries included, nothing else is needed! Why use your own machine or software that doesn't ping into a telemetry hell-hole of data collection on a regular basis?

ramon156 11mo ago

> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. I love this. I used to be a big fan of linear (because the alternatives were dog water), but this also opened the question "why even have a seperate, disconnected tool?" Most of my personal projects have a TODO.md somewhere with a list of things i need to work on. If people really need a frontend for bugs, it wouldn't be more than just rendering that markdown on the web.

mystifyingpoi 11mo ago
> As it is simply plain text Well, if your bugs can be specified clearly in plain text and plain text only, then yeah, I'd also advocate for this approach. Unfortunately, that's not really the case in any bigger software project. I need screenshots, video recordings that are 100 megs, cross-issue linking etc. I hate JIRA (of course) but it gets it right.
- captn3m0 11mo ago
  Even in the case of Dillo, the migrated bugs from GitHub include ZIP files (that are still hosted on GitHub): https://bug.dillo-browser.org/50/ https://bug.dillo-browser.org/50/
- jbaber 11mo ago
  We can enter e-mail's h*ll and just have attachments be base64 blobs.
- ramon156 11mo ago
  Sure, for personal stuff i mostly remember the issue. I can even provide which code snippet it is. For communicating with others that wouldn't fly

iveqy 11mo ago

Seems as a good idea to pitch git-appraise https://github.com/google/git-appraise https://github.com/google/git-appraise I'm not part of the project at all, but this is the only offline code review system I've found.

wkoszek 11mo ago

If anyone wants to add Forgejo to your VM, I made a script that allows you to quickly install server + runner, so you get the full setup: https://wkoszek.github.io/easyforgejo/ https://wkoszek.github.io/easyforgejo/

Kwpolska 11mo ago

> GitHub has been useful to store all repositories of the Dillo project, as well as to run the CI workflows for platforms in which I don't have a machine available (like Windows, Mac OS or some BSDs). The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it? > Furthermore, the web frontend doesn't require JS, so I can use it from Dillo (I modified cgit CSS slightly to work well on Dillo). That sounds like a bad approach to developing a Web browser, surely it would be better to make Dillo correctly work with the default cgit CSS (which is used by countless projects)?

avhon1 11mo ago
No doubt this is desirable. However, adding all the CSS features required to support cgit may have been a lot more work than editing cgit's CSS. It's an attempt at avoiding yak shaving; adding recursive sub-projects that balloon a project's scope of work far beyond the original plan. Dillo is actively developed, and the project of "migrate away from github" is complete, so now other work can be started and completed (like adding the CSS features required to support mainline cgit).
ocdtrekkie 11mo ago
This was the part that mystified me. Love it or hate it, GitHub Actions is free. Alternative providers like Codeberg have much tighter limits on it, and it sounds unlikely the author's solution includes CI at all.
rodarima 11mo ago
> The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it? Yes, we have our own CI service. It is not public for now.

deleted 11mo ago

[deleted]

zzo38computer 11mo ago

There are ways around some of the issues there, such as using the GitHub API (I almost exclusively use the API), and/or using a user script (see below). Furthermore, on GitHub and on some other version control hosting services (such as GitLab), you can change "blob" to "raw" in the URL to access the raw files. However, as they say, it can be mirrored on multiple services (including self-hosting), and this would be a good idea, whether or not you use GitHub, so if you do not like GitHub then you do not have to use it. Note that for some of the web pages on GitHub, the data is included as JSON data within the HTML file, although this schema is undocumented and sometimes changes. User scripts (which you might have to maintain due to these changes) can be used to display the data without any additional downloads from the server, and they can be much shorter and faster than GitHub's proprietary scripts. Using a GPG key to sign the web page and releases is helpful (for the reasons they explain there), although there are some other things that might additionally help (if the conspiracy was not making it difficult to do these things with X.509 certificates in many ways).

throwfaraway135 11mo ago

Although I'm not a fan of GH, I appreciate the ability to see how popular/valid some project is by looking at the number of stars (I know this is far from a perfect signal). I'm much less likely to try projects that have a low number of stars, or projects in different places.

ocdtrekkie 11mo ago
One of the things Forgejo has been working on is federation, such that hopefully someday we can replicate the discoverability of GitHub without a central provider.
59nadir 11mo ago
God forbid we'd have to actually look at the code itself to figure out whether something is good.
- monooso 11mo ago
  GP explicitly stated that they use stars to determine the popularity of a repository, not the code quality.

president_zippy 11mo ago

I freely admit I am out of my depth and have nothing educational to add on the subject. I have but four things to add on this subject: 1. Oh! It's "d.i.l.l.o."! I misread that as something else. 2. After reading many comments in this thread, I must admit I am stupefied at the sheer amount of stuff that can go into merely setting up and maintaining a version control system for a project. 3. I have cited every one of the same problems OP enumerates as my argument for switching new projects over to self-hosted fossil. It also helps a good bit with #2 above when you're a small organization and you're the sole software engineer, sysadmin, and tier >1 support. It's a much simpler VCS that's closer to using perforce in my experience. YMMV, but it's the kind of VCS that doesn't qualify as a skill on a resume. 4. I also find GH deploy keys frustrating because I can't use the same key for multiple repositories. I have 3 separate applications that each run on 4 machines in my cluster, and I have to configure 12 separate deploy keys on GitHub and in my ~/.ssh/config file.

layer8 11mo ago

> GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. I agree with the sentiment, but want to point out that email can be used to turn push into pull, by auto-filtering the respective email notifications into a separate dedicated email folder, which you can choose to only look at when you want.

paulddraper 11mo ago
And if that’s unsatisfactory, GitHub has its own notifications part of the UI. This is in search of a problem.

asdfman123 11mo ago

Nice! Finding new places to stick a Dillo into.

einpoklum 11mo ago

So, the first and foremost reason: > the [GitHub] frontend barely works without JavaScript, so we cannot open issues, pull requests, source code or CI logs in Dillo itself, despite them being mostly plain HTML because Dillo is a simple browser without a JS engine. And that is a perfectly valid reason to leave GitHub.

zzzeek 11mo ago

> This is specially problematic when active issues with developer notes begin to be filled with comments from users that have never contributed to the project and usually do more harm than good. This situation ends up causing burnout in developers. This is a huge with github and I would desperately want a github where issues are visible, but the ability to create or modify them is STRICTLY locked down to project members, and non members can only post Discussions for problems. I really prefer that I write the issue(s) based an "intake discussion" so to speak.

jeffjeffbear 11mo ago

I run a math circle in my area, and use forgejo with kids for thier solutions in Latex and python, it works great for me, and is super easy to enforce logins and reset passwords.

zombot 11mo ago

> it is a single point of failure. I don't mean that GitHub is stored in a single machine, but it is controlled by a single entity which can unilateraly ban our repository or account Besides the usability problems with bloated MS Shitware, this is a strategic point that I see considered far too rarely for my taste.

shevy-java 11mo ago

Isn't there one 'd' missing ... As for gitlab versus github: I understand that gitlab may have more features and thus options, but I can't stand its default UI. Every time I use it I am annoyed compared to the github variant. Perhaps gitlab is nicer to have for teams, but from a user's perspective, I feel gitlab is worse than github (UI-wise primarily).

account42 11mo ago

Always nice to see a project moving to self-hosted git repos rather than the other direction.

jbaviat 11mo ago

How about using tor to help with DNS redundancy? https://en.wikipedia.org/wiki/Tor_(network) https://en.wikipedia.org/wiki/Tor_(network)

a96 11mo ago

https://sfconservancy.org/GiveUpGitHub/ https://sfconservancy.org/GiveUpGitHub/

RNCTX 11mo ago

In the same post where the author of this blog article says they "don't like getting notifications about activity in my repo, and instead prefer to 'work offline' and 'only check in when I want' to... the author also details how they lost their domain which was bought by an ad spamming site guy. I mean, are the scripts writing themselves here, boys?

SuperSandro2000 11mo ago

How to contribute? Just not at all?