I'm one of the engineers at GitHub who was behind this new UI, let me know if you have any questions. We chose React for this code search/code view because it has a lot of interactivity, and it has worked well so far.
And we do intend to write a blog post with more details in the coming weeks.
I was not expecting to see this comment at the top of this thread but since it is here… this UI really sucks on mobile (at least on iOS).
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”.
Yep, aware of these mobile issues and are actively fixing them, will hopefully improve in the next week or so.
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
Positive feedback feels nice, but negative is way more useful to making a great product.
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.
When viewing code I like the feature, however, when browsing folder structures it is a completely redundant feature. And just adds visual clutter. This feels like a half-step between an editor and a static file listing. I would personally prefer either a very static view of the core, in pure html, or an interactive experience (Ctrl+.) for opening vs-code on the repo.
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
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.
How much, if at all, has anticipated and/or apparent stabilization of React Server Components factored into this [expanded] technology choice? Can you speak to considerations of other component frameworks?
I… guess I offended someone by asking what I thought were totally innocuous, curious questions that they invited. Of all the fucking things to downvote! I mean, by all means tear this’n to shreds. But if anyone has a problem with my questions above could you please be bothered to say why?
GitHub has been investing in React for a while (e.g. see our accessible React design system https://primer.style/react/). Many developers at GitHub have experience with React, which helps. And the tooling is just more mature (IMO)
This is just the first step of using React within GitHub.com, so we still use a lot of traditional Rails/ERB, even on the React pages (e.g. for the header/footer).
GitHub is a great example of mostly server-side generated HTML. Their output HTML is very stable: the structure rarely changes, is semantic, logical, and self-documenting. This has helped hundreds of browser extensions (e.g. Refined GitHub, ZenHub) and userscripts, including dozens of my own.
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.
> If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts.
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...
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:
I don't have any data to back this up, just my opinion, but I prefer backend rendered sites with Javascript augmentation for the parts that need it. Just feels faster.
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.
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.
In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.
Snappy and intuitive while loading static pages of text, sure, but their code browsing and search experience needs massive improvement. I'd love to not have to clone a repo and pull up an IDE just to be able to understand the code.
Trur, when I need to browse code I just use codespaces, which you can access by using github.dev/owner/repo, or pressing dot ( . ) when inside the repo
It’s not impossible to imagine Web IDEs surpassing desktop ones, but it’s not happening anytime soon. Until then desktop IDEs will remain superior, so this experience won’t change anytime soon. For every new feature a web IDE adds, we’ll end up missing desktop features still.
I actually disagree — GitHub has been relatively slow for me when it comes to page transitions. For example, switching between a PR’s various tabs would probably be a lot faster with client rendering.
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.
Agreed. I'm rather surprised at people in this thread saying they prefer GitHub's server rendered setup. I use GitHub a lot in my job and it feels rather slow/clunky.
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.
One thing they did at Github years ago was get closer to the metal by ditching JQuery. You can do the same things - and more - with ES6 and updated browser support pretty much across the board. Nowadays you don't even need a transpiler.
So, this seems to be at least partly related to early introduction of Blocks[1] features. If so, and assuming that several of Blocks features are implemented with React, it makes some sense that they’d broaden adoption of React overall. You can use React for smaller isolated parts of a mostly client-static/server-rendered page, but it’s not typical on a page which is already as highly interactive as GH repos are (even if that interactivity is not immediately obvious).
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.
Not sure how I should feel about this. GitHub always felt snappy to me. It's a joy to use and I always admired their approach sending html over the wire. Let's see how this unfolds in the future.
I'm not a frontend guy, so maybe someone else here knows how to effectively benchmark the current system. I would be very curious to see how the current system performed versus a new React FE. Surely MS will do this themselves, but I don't know if they will publish it (especially if it shows the net result of the change was negative).
There is also a very big difference in dev experience/toolset and dev velocity between RoR templates and React. Large apps that use RoR or Django templates become very messy and unenjoyable to work with over time. Plus being able to reuse parts of the state on the client is a big productivity boost.
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!
Funny to read this because since couple of days I've noticed github is loading noticably slower for me. I thought something may be off with my internet connection (I'm on 400 Mbps in Switzerland, M1 16GB, FF).
This seems like a good move. GitHub worked great using server rendering for a highly interactive app, but it was quite easy to end up in a situation where two UI elements would show different things for the same piece of information, because one was updating live and the other wasn't.
Easy way to make the UI end in an inconsistent state: when somebody asked you to review a PR, you’ll see an “add your review” banner and CTA. If from that same page you add yourself as a reviewer the banner won’t appear unless you reload
(I worked on the backend for this, not the frontend.)
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.
I have to say, the notion you can only build webpages with Rails and not webapps did make me chuckle.
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 you've already mastered a system, then the n+1 case is going to be much more timely and cost-effective. So if you know RoR and you've got a similar team then go for it. But for greenfield projects I'm not sure one should go with Ruby on Rails, and this is coming from someone who used Ruby before Rails.
If I'm not mistaken, even 37 Signals made a new framework for their new Hey app.
I absolutely love Django and used it for many many years for all my new projects. Nowadays I only use it in a very limited set of use cases. Having an instant admin UI is a huge advantage for some business cases, flexible auth is great, very fast prototyping is still amazing, etc. Wouldn’t choose it for any front end heavy app.
Yeah, supporting people who use older software and older computers doesn't make financial sense for Microsoft. Plus now it's a lot harder to index the pages so it's more lock-in. Web apps have so many advantages for for-profit corporations in filtering out the unprofitables.
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 just disabled JS in my browser and most stuff still works, although there's a few things that don't, like loading commit data and dropdown menus. I would guess they're doing server side rendering and progressive enhancement so that at least the core functionality still works okay.
Guillermo (Twitter OP) replied in the thread saying it will be server rendered. Other replies point out it’s not enabled for all users, so this (and presumably the UI changes it brings with it) isn’t final. I do see the changes, but I also opt into most if not all preview features and I wouldn’t mind if I’m part of an A/B test or whatever.
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)
Rendered HTML on backend was faster for me and now seeing that last commit header to load and not just show instantly feels weird and slowish, whole site feels heavier for me now.
"Repositories" and "Activities" on the Dashboard are not loading for me anymore. All I get are two endlessly turning spinners. Never had this issue before and looks like these two components can't load their data.
GraphQL has been downgrading their API product for a long while, now React will also downgrade their front pages product. I saw a html/custom-elements advocate engineer left a year ago, .. my speculation just kicks in.
I wonder if they're just replacing the parts of the site that needs to be dynamic with React, since you can mount a react app on any page. It seems overkill to replace even the relatively static parts as well.
They will probably start with that and progressively replace all parts. Having a mixed front end framework is a very inefficient setup and a bad dev experience. Much easier to just SSR those static-ish pages and cache them until content changes.
We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages
I chose React in 2022 for a new app. I looked at the alternatives, and the only ones that seem mature enough are Vue and Svelte. Vue honestly doesn't really seem that different to me. Svelte is great, but the ecosystem is a fraction of react's and I don't want to waste time looking for libraries. The one alternative that looked amazing was htmx. I would honestly love to use that but my app is too dynamic and making it in htmx would be a fun puzzle, but a puzzle nonetheless.
Does "most" popular thing actually matter? Or is it mostly choosing X because everyone else choose X as well?
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).
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.
Solid. It will be a smooth transition DX-wise. And it's better in every angle. Except of course so called "big community", "lots of library", "easier to hire" .. poor excuse for technology advancement.
It’s lack of proper support for both the DOM and native browser events are both giant holes that immediately come to mind and have the unfortunate side effect of making React integrate with anything that wasn’t specifically designed for React a giant PITA.
Probably something like Lit.dev seems exceptionally well positioned to stay aligned with the platform and give the same developer experience and a much faster user experience.
I can't believe they were still running a rails frontend til now, to be honest. I thought rails had fallen out of favor at least 5 years ago (deservedly in my biased estimation). We'll see what happens with Github. I don't have any use for the new bells and whistles like editing the repo directly from the webpage (scary!), or deeper VS Code integration. I'm not interested in Co-Pilot, though a co-worker told me the other day that it had saved him hours in a particular instance.
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.
"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.
I didn't say I couldn't believe they were using rails. I knew very well that Github was originally written on Rails. I was surprised to learn today that the frontend was still rails. The narrative in my head was that, like Twitter, which started as a rails app and eventually outgrew it, Github had abandoned Rails some years ago.
I'm one of the engineers at GitHub who was behind this new UI, let me know if you have any questions. We chose React for this code search/code view because it has a lot of interactivity, and it has worked well so far.
And we do intend to write a blog post with more details in the coming weeks.
I was not expecting to see this comment at the top of this thread but since it is here… this UI really sucks on mobile (at least on iOS).
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”.
Yep, aware of these mobile issues and are actively fixing them, will hopefully improve in the next week or so.
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
3 replies →
> GitHub ui is getting worse on mobile as time goes
Like Reddit, they’re probably trying to push you to the mobile app.
4 replies →
Can you teach me how you absorb and respond to all this criticism/feedback with such grace? Worst part of my job. Well done.
Positive feedback feels nice, but negative is way more useful to making a great product.
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.
2 replies →
When viewing code I like the feature, however, when browsing folder structures it is a completely redundant feature. And just adds visual clutter. This feels like a half-step between an editor and a static file listing. I would personally prefer either a very static view of the core, in pure html, or an interactive experience (Ctrl+.) for opening vs-code on the repo.
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
Appreciate the feedback.
> 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.
1 reply →
How much, if at all, has anticipated and/or apparent stabilization of React Server Components factored into this [expanded] technology choice? Can you speak to considerations of other component frameworks?
I… guess I offended someone by asking what I thought were totally innocuous, curious questions that they invited. Of all the fucking things to downvote! I mean, by all means tear this’n to shreds. But if anyone has a problem with my questions above could you please be bothered to say why?
1 reply →
Why not Svelte? Why not Stimulus Reflex / Hotwire?
GitHub has been investing in React for a while (e.g. see our accessible React design system https://primer.style/react/). Many developers at GitHub have experience with React, which helps. And the tooling is just more mature (IMO)
Why not Solid/Marko which seem to be tailor-made for these kinds of things (mostly static, with interactivity spliced in)
1 reply →
Are you going to switch to API mode for Rails as part of this process?
This is just the first step of using React within GitHub.com, so we still use a lot of traditional Rails/ERB, even on the React pages (e.g. for the header/footer).
GitHub is a great example of mostly server-side generated HTML. Their output HTML is very stable: the structure rarely changes, is semantic, logical, and self-documenting. This has helped hundreds of browser extensions (e.g. Refined GitHub, ZenHub) and userscripts, including dozens of my own.
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.
> If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts.
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?
> 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://news.ycombinator.com/item?id=33555426
Honestly github always felt snappy and intuitive to me, more so than many "cool" react fronts I've seen.
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.
I don't have any data to back this up, just my opinion, but I prefer backend rendered sites with Javascript augmentation for the parts that need it. Just feels faster.
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.
> These JavaScript UIs feel clunky and slow IMO
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.
In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.
8 replies →
Snappy and intuitive while loading static pages of text, sure, but their code browsing and search experience needs massive improvement. I'd love to not have to clone a repo and pull up an IDE just to be able to understand the code.
Actions is also a broken pile of shit. The UI falls to bits constantly.
2 replies →
Trur, when I need to browse code I just use codespaces, which you can access by using github.dev/owner/repo, or pressing dot ( . ) when inside the repo
It’s not impossible to imagine Web IDEs surpassing desktop ones, but it’s not happening anytime soon. Until then desktop IDEs will remain superior, so this experience won’t change anytime soon. For every new feature a web IDE adds, we’ll end up missing desktop features still.
GH Codesearch is in beta, it seems to improve exactly that
I actually disagree — GitHub has been relatively slow for me when it comes to page transitions. For example, switching between a PR’s various tabs would probably be a lot faster with client rendering.
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.
Agreed. I'm rather surprised at people in this thread saying they prefer GitHub's server rendered setup. I use GitHub a lot in my job and it feels rather slow/clunky.
1 reply →
I'm curious what relatively slow means for you.
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.
One thing they did at Github years ago was get closer to the metal by ditching JQuery. You can do the same things - and more - with ES6 and updated browser support pretty much across the board. Nowadays you don't even need a transpiler.
https://github.blog/2018-09-06-removing-jquery-from-github-f...
Interesting, they use html content templates for code re-usability, which is more difficult to use than React.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...
So, this seems to be at least partly related to early introduction of Blocks[1] features. If so, and assuming that several of Blocks features are implemented with React, it makes some sense that they’d broaden adoption of React overall. You can use React for smaller isolated parts of a mostly client-static/server-rendered page, but it’s not typical on a page which is already as highly interactive as GH repos are (even if that interactivity is not immediately obvious).
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.
1: https://blocks.githubnext.com/
Not sure how I should feel about this. GitHub always felt snappy to me. It's a joy to use and I always admired their approach sending html over the wire. Let's see how this unfolds in the future.
I'm not a frontend guy, so maybe someone else here knows how to effectively benchmark the current system. I would be very curious to see how the current system performed versus a new React FE. Surely MS will do this themselves, but I don't know if they will publish it (especially if it shows the net result of the change was negative).
There is also a very big difference in dev experience/toolset and dev velocity between RoR templates and React. Large apps that use RoR or Django templates become very messy and unenjoyable to work with over time. Plus being able to reuse parts of the state on the client is a big productivity boost.
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!
6 replies →
Funny to read this because since couple of days I've noticed github is loading noticably slower for me. I thought something may be off with my internet connection (I'm on 400 Mbps in Switzerland, M1 16GB, FF).
I second this, this week was noticeably slow.
It is noticeably slower. I do not have the data to back up this claim though.
Had the same experience since Thursday or Friday.
This seems like a good move. GitHub worked great using server rendering for a highly interactive app, but it was quite easy to end up in a situation where two UI elements would show different things for the same piece of information, because one was updating live and the other wasn't.
Easy way to make the UI end in an inconsistent state: when somebody asked you to review a PR, you’ll see an “add your review” banner and CTA. If from that same page you add yourself as a reviewer the banner won’t appear unless you reload
(I worked on the backend for this, not the frontend.)
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.)
And yet, the two things I cared for as a user, are gone: scroll position no longer preserved on mobile devices, swiping back doesn’t work reliably.
GitHub probably is more of a webapp than a webpage at this point, so makes sense.
I have to say, the notion you can only build webpages with Rails and not webapps did make me chuckle.
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 you've already mastered a system, then the n+1 case is going to be much more timely and cost-effective. So if you know RoR and you've got a similar team then go for it. But for greenfield projects I'm not sure one should go with Ruby on Rails, and this is coming from someone who used Ruby before Rails.
If I'm not mistaken, even 37 Signals made a new framework for their new Hey app.
https://hotwired.dev
1 reply →
I absolutely love Django and used it for many many years for all my new projects. Nowadays I only use it in a very limited set of use cases. Having an instant admin UI is a huge advantage for some business cases, flexible auth is great, very fast prototyping is still amazing, etc. Wouldn’t choose it for any front end heavy app.
2 replies →
Yeah, supporting people who use older software and older computers doesn't make financial sense for Microsoft. Plus now it's a lot harder to index the pages so it's more lock-in. Web apps have so many advantages for for-profit corporations in filtering out the unprofitables.
> Plus now it's a lot harder to index the pages
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.
3 replies →
I just disabled JS in my browser and most stuff still works, although there's a few things that don't, like loading commit data and dropdown menus. I would guess they're doing server side rendering and progressive enhancement so that at least the core functionality still works okay.
Guillermo (Twitter OP) replied in the thread saying it will be server rendered. Other replies point out it’s not enabled for all users, so this (and presumably the UI changes it brings with it) isn’t final. I do see the changes, but I also opt into most if not all preview features and I wouldn’t mind if I’m part of an A/B test or whatever.
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)
Rendered HTML on backend was faster for me and now seeing that last commit header to load and not just show instantly feels weird and slowish, whole site feels heavier for me now.
"Repositories" and "Activities" on the Dashboard are not loading for me anymore. All I get are two endlessly turning spinners. Never had this issue before and looks like these two components can't load their data.
GraphQL has been downgrading their API product for a long while, now React will also downgrade their front pages product. I saw a html/custom-elements advocate engineer left a year ago, .. my speculation just kicks in.
GraphQL is a language.
I really hope this does not end up like Reddit. Or that at least they keep an old.github.com that’s usable.
I wonder if they're just replacing the parts of the site that needs to be dynamic with React, since you can mount a react app on any page. It seems overkill to replace even the relatively static parts as well.
They will probably start with that and progressively replace all parts. Having a mixed front end framework is a very inefficient setup and a bad dev experience. Much easier to just SSR those static-ish pages and cache them until content changes.
Is this intended as satire or actually a serious statement? I increasingly cannot seem to make a confident distinction nowadays.
Not involved with this project but FYI (some) React sites can be rendered server side as well. This doesn't have to be some slow SPA load.
We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages
I always wanted my phone and tablet devices to serve as mini heaters/hand warmers. Thanks!
Use Angular, much better!
Use angular
Genuinely confused why someone would reach for React in a 2022 rewrite scenario.
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 chose React in 2022 for a new app. I looked at the alternatives, and the only ones that seem mature enough are Vue and Svelte. Vue honestly doesn't really seem that different to me. Svelte is great, but the ecosystem is a fraction of react's and I don't want to waste time looking for libraries. The one alternative that looked amazing was htmx. I would honestly love to use that but my app is too dynamic and making it in htmx would be a fun puzzle, but a puzzle nonetheless.
React is still a safe bet, there’s an enormous quantity of engineers who know how to use it.
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?
Scaling development efforts is a challenge. Reaching for the most popular thing out there is a solution.
Does "most" popular thing actually matter? Or is it mostly choosing X because everyone else choose X as well?
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.
What would your suggestions be in place of React?
Solid. It will be a smooth transition DX-wise. And it's better in every angle. Except of course so called "big community", "lots of library", "easier to hire" .. poor excuse for technology advancement.
> It is on a bad path in terms of integrating with the web platform
This is some unsubstantiated claim
It’s lack of proper support for both the DOM and native browser events are both giant holes that immediately come to mind and have the unfortunate side effect of making React integrate with anything that wasn’t specifically designed for React a giant PITA.
3 replies →
So what would you recommend instead?
Probably something like Lit.dev seems exceptionally well positioned to stay aligned with the platform and give the same developer experience and a much faster user experience.
3 replies →
This type of useless reddit snark is the reason I wish I could filter out green names. Low effort bait has no place on HN.
Unfortunately these type of posts aren’t limited to new accounts but I agree with you about the Reddit snark.
What do the green names mean? I've seen them before but have had no idea.
4 replies →
Just flag bad comments and bad posts.
I can't believe they were still running a rails frontend til now, to be honest. I thought rails had fallen out of favor at least 5 years ago (deservedly in my biased estimation). We'll see what happens with Github. I don't have any use for the new bells and whistles like editing the repo directly from the webpage (scary!), or deeper VS Code integration. I'm not interested in Co-Pilot, though a co-worker told me the other day that it had saved him hours in a particular instance.
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.
> I thought rails had fallen out of favor at least 5 years ago (deservedly in my biased estimation).
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.
Why can't you believe they were using rails?
I didn't say I couldn't believe they were using rails. I knew very well that Github was originally written on Rails. I was surprised to learn today that the frontend was still rails. The narrative in my head was that, like Twitter, which started as a rails app and eventually outgrew it, Github had abandoned Rails some years ago.