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

▲

simonw 6 hours ago | parent | next [-]

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 6 hours ago | parent | next [-]

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

▲

homebrewer 6 hours ago | parent | next [-]

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.

▲

elktown 5 hours ago | parent | prev | next [-]

I honestly believe that the people involved likely already wanted to move over to React/SPAs for one reason or another, and were mostly just searching for excuses to do so - hence these kind of vague and seemingly disproportional reasons. Mobile over desktop? Whatever app-like means over performance?

Non-technical incentives steering technical decisions is more common than we'd perhaps like to admit.

▲

blibble 6 hours ago | parent | prev | next [-]

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

▲

simonw 5 hours ago | parent [-]

I interact with GitHub on my mobile phone every day.

▲

blibble 5 hours ago | parent [-]

yeah and I bet three people used Windows 8 on tablets too.

	▲	simonw 4 hours ago \| parent [-]
		I think you are wildly underestimating how common it is for people to use GitHub from a phone. It's where I interact with notifications about new issues and PRs for one thing. I doubt I'm alone there.

▲

LtWorf 4 hours ago | parent | prev [-]

Who has ever used github on mobile?

I'd like to see their logs about this.

▲

simonw 4 hours ago | parent [-]

Me, every day.

	▲	LtWorf 2 hours ago \| parent [-]
		And what do you achieve by doing that? Seems a small audience to optimise for.

▲

cess11 an hour ago | parent | prev [-]

If it's fast people don't stick around for as long. Make it sluggish and you get more stonks analytics.

▲

bob1029 6 hours ago | parent | prev | next [-]

https://github.com/orgs/community/discussions/62372#discussi...

	▲	superkuh 4 hours ago \| parent [-]
		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.

▲

baiwl 7 hours ago | parent | prev | next [-]

Having to enable javascript to see a website is not an accessibility problem according to WCAG.

▲

marginalia_nu 6 hours ago | parent | next [-]

It is a very real accessibility problem if you're using Dillo, which does not support javascript.

▲

llbbdd 2 hours ago | parent [-]

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

	▲	marginalia_nu an hour ago \| parent [-]
		This is in the context of where that web browser is hosted, so it's quite relevant.

▲

superkuh 4 hours ago | parent | prev [-]

There's 'enabling javascript' and then there's 'requiring a javascript VM with bleeding edge features basically only found 3 browsers'.

▲

egorfine 7 hours ago | parent | prev [-]

Fixing accessibility problems won't make shareholders happy while forcing AI down our throats will.