Live data from Hacker News

Migrating Dillo from GitHub

dillo-browser.org

161–170 of 219 posts

Re: Migrating Dillo from GitHub

#161
post #6

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.

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.

Gitlab did seem like a hope. But they very quickly became an even more massive and slow SPA javascript app than even github was.

Re: Migrating Dillo from GitHub

#162
post #142
post #140

Earlier quoted context omitted.

I file issues, comment on issues, review PRs and increasingly ship code entirely from my phone (thanks to LLM assistance). All of six of these commits today were created and shipped from my phone while I was out and about on a nice dog walk: https://github.com/simonw/tools/commits/47b07010e3459adb23e1... - now deployed to https://tools.simonwillison.net

[flagged]

Yeah, it's really sad to be able to walk the dog for an hour a day, check out the local pelicans and simultaneously hack on fun projects on my phone.

Re: Migrating Dillo from GitHub

#163
post #19

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

What exactly is the advantage of running something like GitLab vs what I do which is just a server with SSH and a file system? To create a new repo I do: ssh example.com ‘mkdir repos/my-proj.git && cd repos/my-proj.git && git init —bare .’ Then I just set my remote origin URL to example.com:repos/my-proj.git The filesystem on example.com is backed up daily. Since I do not need to send myself pull requests for persona…

We at $DAYJOB had an internal git server that was literally what the parent of this comment mentioned (`git init --bare`). It became a little cumbersome, so when I stumbled across forgejo, I was happy to see that importing the existing git repos was a breeze, just had to point the config to look at the existing git storage root and assign groups and permissions via the GUI.

Re: Migrating Dillo from GitHub

#164
post #145
post #30

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

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.

That’s ok. Not everyone can be a chad C developer.

Re: Migrating Dillo from GitHub

#165

Earlier quoted context omitted.

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

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

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.

Re: Migrating Dillo from GitHub

#166
post #162
post #142

Earlier quoted context omitted.

[flagged]

Yeah, it's really sad to be able to walk the dog for an hour a day, check out the local pelicans and simultaneously hack on fun projects on my phone.

Saying your life is about filling PRs on you phone while walking your dog is not the flex you think it is.

Re: Migrating Dillo from GitHub

#167
post #120

Earlier quoted context omitted.

it's also a real accessibility problem if you're trying to use sticks and rocks to access the internet

Why should you need JavaScript to render text and buttons? Were browsers unable to do this prior to the JavaScriptification of everything?

The same reason you need to use LLMs to code.

Re: Migrating Dillo from GitHub

#168
post #6

Earlier quoted context omitted.

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.

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.

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.

Re: Migrating Dillo from GitHub

#169
post #18
post #13

Earlier 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…

What's nuts about that presentation is that the github frontend has gone from ~.2 to >2 Million lines of code in the last 5-6 years. 10x the code... to get slower?

Re: Migrating Dillo from GitHub

#170
post #166
post #162

Earlier quoted context omitted.

Yeah, it's really sad to be able to walk the dog for an hour a day, check out the local pelicans and simultaneously hack on fun projects on my phone.

Saying your life is about filling PRs on you phone while walking your dog is not the flex you think it is.

These are PRs against my own personal projects. I enjoy hobbies.

Criticizing other people's hobbies isn't the flex you think it is.

Post reply on HN