[HN Gopher] GitHub is replacing Rails front end rendering with R...
___________________________________________________________________
GitHub is replacing Rails front end rendering with React
Author : todsacerdoti
Score : 79 points
Date : 2022-11-12 20:30 UTC (2 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| deergomoo wrote:
| 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.
| mhoad wrote:
| 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.
| xmonkee wrote:
| 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.
| StreamBright wrote:
| Scaling development efforts is a challenge. Reaching for the
| most popular thing out there is a solution.
| azemetre wrote:
| 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.
| nvllsvm wrote:
| So what would you recommend instead?
| mhoad wrote:
| 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.
| randomguy0 wrote:
| What would your suggestions be in place of React?
| [deleted]
| ojkelly wrote:
| 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?
| pacifika wrote:
| GitHub probably is more of a webapp than a webpage at this point,
| so makes sense.
| davzie wrote:
| 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.
| systemicdanna wrote:
| 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.
| scrollaway wrote:
| Have you looked into Django Ninja?
|
| 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.
| threatofrain wrote:
| 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
| mnutt wrote:
| Hotwired is a ruby gem that sits on top of Rails' existing
| Turbo approach: start with a regular server-rendered ERB
| page, layer on Turbo to allow for page updates without page
| refreshes (via XHR-fetched html fragments) and layer on
| Hotwire to sync state with websockets.
| superkuh wrote:
| 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.
| lghh wrote:
| > 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.
| 1123581321 wrote:
| You just said it: if your HTML delivers a react app that
| hasn't taken the extra steps to be SSR, then the crawler
| has to run the JS in order to index the content instead of
| just parsing the HTML response.
| saila wrote:
| 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.
| eyelidlessness wrote:
| 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)
| warpech wrote:
| 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.
| colin353 wrote:
| 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.
| cntainer wrote:
| 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.
| ronnier wrote:
| 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.
| 323 wrote:
| 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.
| coffeefirst wrote:
| That's the theory, but every time I measure it the combined
| data and JSON needed to render it wind up being more than
| plain HTML both in bytes transferred and milliseconds to
| render.
|
| There will be exceptions of course, but I haven't found
| them.
| martinald wrote:
| The problem isn't the amount of data but the number of
| round trips required to get it.
|
| 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.
| lomereiter wrote:
| What you describe is solved with GraphQL, which is a very
| mature technology by now.
| [deleted]
| paxys wrote:
| 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.
| thegginthesky wrote:
| 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
| gw98 wrote:
| Actions is also a broken pile of shit. The UI falls to bits
| constantly.
| diarrhea wrote:
| I work with it on a daily basis and am still confused by
| most pages in Actions.
| williamdclt wrote:
| GH Codesearch is in beta, it seems to improve exactly that
| diarrhea wrote:
| 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.
| papito wrote:
| 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...
| noahtallen wrote:
| 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.
| adamredwoods wrote:
| 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...
| mirekrusin wrote:
| 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).
| StreamBright wrote:
| It is noticeably slower. I do not have the data to back up this
| claim though.
| dombesz wrote:
| I second this, this week was noticeably slow.
| rocketbop wrote:
| Had the same experience since Thursday or Friday.
| weinzierl wrote:
| "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.
| jakub_jo wrote:
| 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.
| z9znz wrote:
| 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).
| systemicdanna wrote:
| 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!
| nells wrote:
| Kiro wrote:
| 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.
| pvg wrote:
| Just flag bad comments and bad posts.
| Naga wrote:
| What do the green names mean? I've seen them before but have
| had no idea.
| threatofrain wrote:
| New accounts.
| revskill wrote:
| I thought green name means some kinds of VIP account.
| eyelidlessness wrote:
| Very Introductory Poster
| Cu3PO42 wrote:
| Green names indicate recently created accounts. I'm unsure
| of the exact cutoff, but it should be around two weeks.
| telman17 wrote:
| Unfortunately these type of posts aren't limited to new
| accounts but I agree with you about the Reddit snark.
| ianbutler wrote:
| 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.
| systemicdanna wrote:
| 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.
| trey-jones wrote:
| 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.
| cientifico wrote:
| Why can't you believe they were using rails?
| CharlesW wrote:
| > _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.
| gedy wrote:
| 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.
| eyelidlessness wrote:
| 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/
___________________________________________________________________
(page generated 2022-11-12 23:00 UTC)