We fell out of love with Next.js and back in love with Ruby on Rails
1–10 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#2Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#3So begins the slow roll backwards because ai can’t support the new.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#4I switched from Rails to the node.js ecosystem back in the 3.2 to 4 transition, however looking back I share a similar sentiment as the OP.
I recently initiated the backmigration and my approach thus far however has been to take out the "administrative" part out into Rails to benefit from all the useful conventions there, but keep the "business services" in JS or Python and have the two communicate. Best of both worlds, and the potential of all of rubygems, npm and pypi combined.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#5I’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
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#6Just 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, global state, or a 200 kB hydration bundle—they just need partial HTML swaps.
The real driver is complexity cost. Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. Cutting that payload often makes performance and security better at the same time. Of course, Figma‑ or Gmail‑class apps still benefit from heavy client logic, so the emerging pattern is “HTML by default, JS only where it buys you something.” Think islands, not full SPAs.
So yes, the pendulum is swinging back toward the server, but it’s not nostalgia for 2004 PHP. It’s about right‑sizing JavaScript and letting HTML do the boring 90 % of the job it was always good at.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#7I’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
What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code (have you seen these relatively thin models and controllers?), as well as established dependencies and the lack of tendency to bikeshed in libraries (geocoder or devise for example have been mostly stable over close to a decade, with few popping up to replace it)
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#8I switched from Rails to the node.js ecosystem back in the 3.2 to 4 transition, however looking back I share a similar sentiment as the OP. I recently initiated the backmigration and my approach thus far however has been to take out the "administrative" part out into Rails to benefit from all the useful conventions there, but keep the "business services" in JS or Python and have the two communicate. Best of both worl…
Reminds me of what I did to bring AI into my SpringBoot Java app. I just created a Python-based WebService (microservice), that deploys as part of my docker stack, and now I get the benefit of everything going on in the AI world which is mostly Python, with no lag. Meanwhile other Java Develpers are busy trying to port all that stuff over into Java language. To me that porting is just a waste of time. Let AI stay in Python. It's a win/win, imo. Of course I had to learn Python, but as a Java Dev it came easy. Other Java devs are [mostly] too stubborn to try Python if you ask me. Sorry if this drifted off topic, but it shows how you don't have to be a purist, but you can just do what works and is easiest.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#9I’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
The prevailing sentiment is that once you hit scaling issues with frameworks like Rails or Django you should have enough resources to simply throw money at the problem either in the form of more hardware, cloud computing, or better software engineers that can identify bottlenecks and optimize them.
Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this the right bet to make.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#10> hitting a GraphQL API (Hasura) for getting data, and caching as much as possible using Incremental Static Revalidation. The first load was often a bit slow, but caching helped.
Why do you need GraphQL here?
If your developer workstation can't send a few KB of data over a TCP socket in a reasonable amount of time due to the colossal amount of Zoomer JavaScript abstraction nonsense going on, something has gone terribly wrong.
The whole idea of needing "islands" and aggressive caching and all these other solutions to problems you created -- that you have somehow managed to make retrieving a trivial amount of data off a flash storage device or an in-memory storage system of some kind slow -- is ludicrous.