We’d love to have the Dillo project on Tangled! ;) https://tangled.org
Migrating Dillo from GitHub
31–40 of 219 posts
Re: Migrating Dillo from GitHub
#32Earlier quoted context omitted.
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…
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-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 w…
For contrast, gitea/forgejo use as little JavaScript as possible, and have been busy removing frontend libraries over the past year or so. For example, jquery was removed in favor of native ES6+.
Let them choke on their "app-like experience", and if you can afford it, switch over to either one. I cannot recommend it enough after using it "in production" daily for more than five years.
Re: Migrating Dillo from GitHub
#33[flagged]
Re: Migrating Dillo from GitHub
#34We 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.
Different devs have different preferred ways to work and collaborate. I doubt the FOSS community will converge on a single solution. I think we’re at a point of re-decentralization, where devs will move their projects to the forge that satisfies their personal/group requirements for control, hosting jurisdiction, corporate vs community ownership, workflow, and uptime.
This is due to increasing competition in the source forge space. It’s good that different niches can be served by their preferred choice, even if it will be less convenient for devs who want to contribute a patch on a more obscure platform.
Re: Migrating Dillo from GitHub
#35Earlier quoted context omitted.
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?
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 relev…
Seems like you found it, but for others: one of the easiest ways to get a PR's diff/patch is to just put .diff or .patch at the end of its URL. I use this all the time!
Random PR example, https://github.com/microsoft/vscode/pull/280106 has a diff at https://github.com/microsoft/vscode/pull/280106.diff
Another thing that surprises some is that GitHub's forks are actually just "magic" branches. I.e the commits on a fork exist in the original repo: https://github.com/microsoft/vscode/commit/8fc3d909ad0f90561...
Re: Migrating Dillo from GitHub
#36>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.
Re: Migrating Dillo from GitHub
#37>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.
Having to enable javascript to see a website is not an accessibility problem according to WCAG.
It is a very real accessibility problem if you're using Dillo, which does not support javascript.
Re: Migrating Dillo from GitHub
#38[flagged]
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.
Re: Migrating Dillo from GitHub
#39We 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.
Isn't that pretty much GitLab? But then most people still prefer GitHub anyway.
GitLab is too heavyweight for many projects. It’s great for corporations or big organizations like GNOME, but it’s slow and difficult to administer. It has an important place in the ecosystem, but I doubt many small projects will choose it over simpler alternatives like Codeberg.
Re: Migrating Dillo from GitHub
#40> 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. Someon…
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.
I would love to see more projects use git-bug, which works very well for offline collaboration. All bug tracker info is stored in the repo itself. https://github.com/git-bug/git-bug
It still needs work to match the capabilities of most source forges, but for small closed teams it already works very well.