GitHub is replacing Rails front end rendering with React
twitter.com
twitter.com
And we do intend to write a blog post with more details in the coming weeks.
A couple of immediate problems:
1) I am no longer able to visually distinguish folders from files, where did the folder icon disappear?
2) Swiping back is weird, sometimes it does work, sometimes it doesn’t. When it doesn’t, it either leaves me with a blank screen, or loads back what I just swiped away.
3) This really aggravates me, swipe back doesn’t preserve scroll position on long file listings, it renders the contents and scrolls to the top. This is really bad.
4) Where’s the footer?!
5) The whole thing just feels slow.
GitHub ui is getting worse on mobile as time goes. For example, why can’t I fork a repo from the mobile page?
I don’t know how you measure how your UI is used but I don’t think me browsing the code while sitting on the throne, or looking up a piece of code while laying in bed is so unusual. Maybe some of you should try that before such half baked stuff is released with much fanfare. Because the way I read it is “we’re excited to announce that we have broken your GitHub experience”.
And thanks for the feedback. We're in Beta right now exactly so we can get feedback so please don't hesitate to reach out (in-app, via Discussions https://github.com/orgs/community/discussions/categories/cod..., or any other way you can reach us), even if it's something minor
By the way, feel free to opt out if you hate the new UI - it's super easy to opt out from the code view page, or from the feature preview menu.
Like Reddit, they’re probably trying to push you to the mobile app.
The editor was clearly trying to load the whole thing!
Secondly, the code search feature is nice, but is there a reason why it has to be a column to the right, couldn't it be part of the editor, like we're used to in most editors nowadays.
A gripe I've had recently with github, is just that it all seems so slow. It feels like trudging through mud, it may be, because I don't live in the US. But this is getting out of hand, and makes me want to consider leaving it for something else.
Sorry for the rant, I like progress, I just don't like unneeded complexity, especially for a tool I love =D
> static view of the core
Not sure what you mean by that, can you elaborate?
FWIW we are working to more tightly integrate code search into the code view.
And absolutely, performance matters a lot to us. Sorry for the slow experience, you're not the only one, particularly outside the US. Only thing I can say is we're working on it.
Anyways best of luck to you. It hasn't been an easy year for github with the downtime earlier in the year, and what I would expect to be a nasty migration from a monolith =D
We're changing an website that millions of people use every day. Hopefully we mostly have a positive impact. But if we're making it worse, even in a small way, that matters a lot to be aware of.
Masters of subjects don’t learn overnight. They learn over years, decades, a lifetime. In that time they make countless mistakes. But they persevere and don’t let it affect them emotionally and they grow into those masters.
I make mistakes daily. I’ve thrown away hundreds of thousands of lines of code in my career because it didn’t work as expected. But each time I grew a little and learned something to make the next iteration better.
Of course, treating HTML as API/data exchange format is fragile and might be seen as hindering progress by some of the GitHub staff. However, it has been like that for many years and was beneficial for the community. Perhaps not that beneficial for GitHub, who would prefer integrations over the official API.
If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts. And another reason for power users to flock to other platforms.
Edit: React does not necessarily mean div-soup, but I have seen too many React-powered div-soups to expect GitHub's HTML to stay the same.
But that feels more like a failure of user script developers (myself included). Why don't we have great tooling for modifying React apps (or do we but I don't know about it?)? The amount of them is already high and only going to increase.
For modifying the Tidal UI I had to use MutationObservers, tied to how the components will render. It's bad, I'd rather modify the React app more directly, but hey, it does work reliably (albeit only because the app doesn't change much): https://gist.github.com/solarkraft/edd9d49bcf0f548b1aa285da7...
Can we do better?
I hope yes! Some people are interested in this field. I think, we would need more mor flexible, adaptive scrapers based on content not the HTML structure. This week alone, I had interactions about "AI assisted web scraping" with two people:
- https://twitter.com/geoffreylitt/status/1589677131873021953
It would be great if they wrote an article about this switch to understand some of the challenges they were facing.
I would also be curious if they considered other approaches and stacks.
These JavaScript UIs feel clunky and slow IMO. Maybe it's the (sometimes) dozens of calls the UI make back to the server to get data whereas if it was all rendered in the backend the round trip time would be a lot faster since the server is closer to the data, but my browser needs to make a call across the internet to the server and then to the database or whatever.
Also for tools websites at companies I work at, as a backend dev, building those tools in react is huge overhead. Webpack and react and redux etc. It's a lot to deal with for some simple tool. I'm wondering how much internal tool websites built in react slow down the development process at corps.
Imagine you need to do the following calls to get the page rendered with the various information different parts of the page has:
1. Get user information
2. Get projects for user
3. Get the selected project
Now, if this was all server side rendered, it might take 1ms to go to the database and get the various bits of info, or 3ms for 3 sequential requests.
With a react app and say 250ms of latency to the database, you're looking at 750ms of overhead - 200x slower.
Of course you can architect all your APIs to always return everything the user needs so they don't have to do multiple requests, but that has its own drawbacks and honestly is very difficult to do and plan ahead for, especially at scale with multiple consumers of various APIs.
There will be exceptions of course, but I haven’t found them.
They don't feel slow, they are slow, even more so on mobile, but developers have stopped caring about mobile web performance a long time ago. So much for "flash is killing my battery", now it's Javascript.
https://github.blog/2018-09-06-removing-jquery-from-github-f...
Of course, performance will come down to how well the team builds the site and optimizes it. It is very easy to make a site slow in so many different ways. You always have to be looking at and optimizing it for improvements, both on the client and server. React isn’t immune to this, just as various server frameworks aren’t immune to it either.
As an example I just made a quick test from my Firefox mobile browser in desktop mode and the switch between PR tabs is not instant but close enough to not be bothered by it.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...
I personally wouldn’t pick React for, well, anything under my personal control. But it’s a sensible choice for the features they describe at their scale, and a sensible choice for their repo experience generally. I’ve seen some comments about bugginess in navigation etc, but none that don’t sound familiar from their Rails implementation. Hopefully with some bugs ironed out this will be bug compatible or better.
For me personally API+front end is a much cleaner and productive paradigm than having to pass massive dictionaries from a controller to a template. This separation of concerns allows to focus on and optimize data sources/retrieval and UI/rendering independently. Really nice!
Deploying API and FE separately can also be more efficient, as these services likely require a different tech stack, a different scaling/load balancing setup, and have a different release cycle.
That's a complete opinion as well.
When was the last time you read about a UI heavy web app migrating from a JS framework to Django templates?
Don't you pass already massive JSON payloads from your API endpoints down to your client to update the views?
How's this any different than your hypothetical or even real world scenario?
> Don't you pass already massive JSON payloads from your API endpoints down to your client to update the views?
Not really. You send many parallel API requests from the client, each response is a smaller JSON. And when you navigate to the next page, most of its data is already in your state, so you have to request just the missing part (e.g. a different post). When you are constructing context for a page on the backend you have to provide all its context every time. The template doesn't make requests based on some logic.
Yes, the new code search and navigation experience is powered by React for the frontend. We decided to use that because we wanted to build a stateful, rich navigation experience.
If you want to try it, please sign up for our beta https://github.com/features/code-search (we have been clearing the waitlist daily.)
Why does using react mean it is harder to index pages? You can certainly write something that's difficult to index in React, but using React does not mean it is inherently more difficult to index. This is especially true if you're using SSR + modern react features with a meta-framework like Next.js
> supporting people who use older software and older computers doesn't make financial sense for Microsoft
Pretty much the same point here. Fundamental misunderstanding of React.
I wouldn’t be so paranoid to think this is some nefarious plot, it’s probably just incomplete. Whatever their “lock in” strategy, it’s more about building and extending a feature moat that users don’t want to leave than restrictive dark patterns. Harming searchability is more damaging to GitHub (which thrives on being highly ranked in Google/etc searches) than it could possibly be to would-be defectors who are almost certainly capable of using their API either directly or by using any number of tools to do that for them. If anything, shipping this widely as-is would probably drive users away not lock them in.
Judging by the timing of adoption of React/Next for their Blocks landing page (also mentioned in the Twitter replies), I wouldn’t be surprised if this is intended to be rolled out alongside further stabilization of React Server Components, or otherwise integrated with existing internal SSR implementation. (Leaning towards the former given it’s a Vercel person speaking confidently about GH’s plans for server rendering)
If Rails can take a company such as GitHub this far then it, along with other traditional server side rendered frameworks like Django and Laravel, should more seriously be considered when starting new projects and apps.
If I'm not mistaken, even 37 Signals made a new framework for their new Hey app.
I use FastAPI exactly because of the reasons you point out... but damn do I miss the Django ORM and admin. Django-Ninja is an acknowledgement of the realities of that.
It is on a bad path in terms of integrating with the web platform and doesn’t seem to have any clear signs to resolving that technical debt.
I mean we aren't talking about a rewrite in Mithril.js here. It's not hard to find people that want to work in vue, svelte, or solid. These three also seem to beat react at every benchmark (also nearly everything is better than react performance wise it seems).
https://krausest.github.io/js-framework-benchmark/current.ht...
I honestly wonder how much bloat and loss of performance we're wasting on hundreds of millions of clients because companies and teams and orgs are no longer opting for better experiences thru experimentation or choosing better tools but simply chasing after wrong KPIs set by people that don't care about tech.
Meanwhile, "the aligned with platform" lit.dev is busy reinventing React, but poorly:
- uses non-standard syntax like `<div ?hidden=xxx .value=yyy .@click=zzz`
- special functions of the form "this particular function call even though it looks like a regular function call will actually throw an exception if used outside a very specific place inside a string". See "built-in directives"
- as a part of the mess that is Web Components in general is now busy reinventing React Context
and so on and so forth.
But yeah, sure, "more aligned something something"
I’m making the argument that would be a bad choice to make in 2022 but totally understand why it made sense a decade ago.
Ah yes. Go directly for ad hominem attacks without ever telling what exactly you mean. That will definitely help you win an argument.
> I mean using options that don’t have to reimplement entire core parts of the web platform that already exist
Again: what the hell are you talking about.
The performance you can achieve is respectable, especially as your application grows.
> It is on a bad path in terms of integrating with the web platform
What do you mean?
This is some unsubstantiated claim
What
Funny how you keep not saying what you mean across two threads. While accusing others of being ignorant, partisan, or never using something, it looks like you're just describing yourself.
I just hope they don't kill the parts that I think are useful, and the things that made GH so valuable in the first place. It's a worrying trend that software seems to get worse for users in the name of making more money.
For the folks downvoting, GitHub said basically this in 2018: https://www.theregister.com/2018/08/16/github_rails_microsof...
"GitHub is about a third of the way through an architectural change that began last year. The company is moving away from Ruby on Rails toward a more heterogeneous, composable infrastructure."
This doesn't mean that they're rewriting Rails infrastructure for the sake of it, so legacy Ruby/Rails software will presumably power big chunks of GitHub for many years to come.