Hacker News Reader

Comment by pacifika | Hacker News Reader

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

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.

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.

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.

Having heard of Django-Ninja before. Looks really good! If I understand correctly it would allow me to keep the best parts of Django (ORM, Admin UI) and build a FastAPI-inspired API? That’s an awesome combo! Curious to see benchmarks how it compares to ExpressJS.

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.

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.

Modern component libraries make it harder to write the site in a non-indexable way than to just make it easy to index.

Only as a user of Next and similar renderers. The default in the larger web application world is to ship an empty target element and a JS bundle.

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)

Reply on news.ycombinator.com