> 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?)
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.
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.
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?
That also means a much larger team and great possibilities for good perf reviews, so basically an excellent outcome in a corporate env. People follow incentives.
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?)