Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fell out of love with Next.js and back in love with Ruby on Rails

hardcover.app

Post reply on HN
Print view View original

221–230 of 533 posts

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#221

Post by threetonesun »

dingnuts wrote: post #203
brandensilva wrote: post #165

Earlier quoted context omitted.

We have been moving to localized cache stores and there aren't any client side loaders anymore outside of the initial cache generation. Think like Linear, Figma, etc It just depends on what you are after. You can completely drop the backend, apis, and have a real time web socketed sync layer that goes direct to the database. There is a row based permissions layer still here for security but you get the idea. The clie…

>and have a real time web socketed sync layer that goes direct to the database you might be able to drop a web router but pretending this is "completely drop[ping] the backend" is silly. Something is going to have to manage connections to the DB and you're not -- I seriously hope -- literally going to expose your DB socket to the wider Internet. Presumably you will have load balancing, DB replicas, and that sort of t…

I assumed they meant a client side DB and then a wrapper that syncs it to some other storage, which wouldn't be terribly different than say a native application the relies on a cloud backed storage system.

Which is fine and cool for an app, but if you do something like this for say, a form for a doctor's office, I wish bad things upon you.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#222

Post by skydhash »

lmm wrote: post #154
thembones wrote: post #6

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…

> Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. IME this is backwards. All that stuff is a one-off fixed cost, it's the same whether you have 10 lines of JS or 10,000. And sooner or later you're going to need those 10 lines of JS, and then you'll be better off if you'd written the whole thing in JS to start with rather than whatever other pieces of technology you're usi…

10 lines of JS fits into a screen and can be reasoned about quite easily. Now do the same for 10000.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#223

Post by Thaxll »

austin-cheney wrote: post #27

When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.

I mean LLM is also putting text on screen...

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#224

Post by Thaxll »

drx wrote: post #12
mountainriver wrote: post #5

I’ve written a bit of rails and still don’t really get what the raving is about. It was perfectly fine, I didn’t find anything extra special about it. Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you

Rails has ActiveRecord, which has an extremely elegant REPL. It's a delight to use.

ActiveRecord or how to badly couple your storage with your objetcs.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#225

Post by realusername »

lmm wrote: post #157
3sbi wrote: post #112

I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next to React+Inertia.js because of growing bills from Vercel even though deploying the same app on your own VPS instead of relying on cloud provider would probably solve the issue. Nonetheless, I still don't understand their yearn for complexity - does book trackin…

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want yo…

Maybe I'm biased but I don't see any scenario where GraphQL ever makes sense, the complexity is never worth it.

You throw away all the debuggability and simplicity of rest for close to zero advantages

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#226

Post by christophilus »

pjerem wrote: post #35
rustc wrote: post #18

What's the closest thing to Rails in a language with a sound static type system?

Unironically, if you want something as mature as Rails, with batteries included, and static typing, the closest in my mind is aspnet core. It’s honestly a really underrated framework, smartly designed, with probably the best ORM that exists and a great ecosystem. Unfortunately, the documentation is painfully bad and the Getting Started guides are really boring compared to Rails or Django. There may also be Laravel bu…

LINQ is the thing I miss most in every other stack I’ve used. It’s a thing of beauty even if you don’t use EF.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#227

Post by ToucanLoucan »

pier25 wrote: post #124
dmix wrote: post #104

Earlier quoted context omitted.

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things. Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.

> The obsession with DX tooling is exactly why JS is such an awful developer experience. I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads. Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeatin…

> I used to agree but these days with Vite things are a lot smoother.

Didn't everybody say the exact same thing about Node, React, jQuery...? There is always a new and shiny frontend JS solution that will make the web dev of old obsolete and everyone loves it because it's new and shiny, and then a fresh crop of devs graduates school, the new shiny solution is now old and boring, and like a developer with untreated ADHD, they set out to fix the situation with a new frontend framework, still written in JavaScript, that will solve it once and for all.

I still build websites now the same as I did when I graduated in 2013. PHP, SQL, and native, boring JavaScript where required. My web apps are snappy and responsive, no loading bars or never-ending-spinning emblems in sight. shrug

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#228

Post by torben-friis »

thembones wrote: post #6

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…

This is not my field, but my mental model was that server side mostly died when mobile apps started being mainstream, and treating the web app as another frontend for your common api was considered the best way to handle client diversity.

Was this not the case? And if so, what has fundamentally changed?

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#229

Post by [deleted] »

madethemcry wrote: post #103

I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.…

[deleted]

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#230

Post by lmm »

Diggsey wrote: post #212
lmm wrote: post #157

Earlier quoted context omitted.

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want yo…

> Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Not remotely true. There are plenty of web apps that work just fine with a standard fixed set of API endpoints with minimal if any customization of responses. Not to mention the web apps that don't have any client-side logic at all... GraphQL solves a problem that do…

> With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility

But also no problem with it. There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares?

> Just have the backend provide the APIs that the front-end actually needs. If those needs change, also change the backend.

Sure, but how are you actually going to do that? You're always going to need some way for the frontend to make requests to the backend that pull in related data, so that you avoid making N+1 backend calls. You're always going to have a bunch of distinct but similar queries that need the same kind of related data, so either you write a generic way to pull in that data or you write the same thing by hand over and over. You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.

Post reply on HN