from Hacker News

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

by mike1o1 on 5/3/25, 6:26 PM with 519 comments

• by thembones on 5/3/25, 7:34 PM

  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, 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.

• by 3sbi on 5/3/25, 9:10 PM

  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 tracking app really need GraphQL, separate frontend framework and complicated build process or all that could have been solved by sticking to deploying monolithic RoR app with HTML templates on VPS from the very start?

• by twodave on 5/3/25, 10:03 PM

  We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors:

  * difficult auth story. next-auth is limited in a few ways that drove us to use iron-session, such as not being able to use a dynamic identity provider domain (we have some gov clients who require us to use a special domain). This required us to basically own the whole openid flow, which is possible but definitely time we didn’t expect to have to spend in a supposedly mature framework.

  * because the NextJS server wasn’t our primary API gateway we ended up having to proxy all requests through it just to add an access token to avoid exposing it on the client. The docs around this were not very clear, and this adds yet another hop with random gotchas like request timeout/max header size/etc.

  * the framework is very aggressive about getting you on their cloud, and they make decisions accordingly. This was at odds with our goals.

  * the maintainers aren’t particularly helpful. While on its own this would be easy to look past, there are other tools/frameworks we use in spite of their flaws because the maintainers are so accessible and helpful (shout out to Chillicream/HotChocolate!)

• by madethemcry on 5/3/25, 8:59 PM

  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.

  I often see myself going back to Ruby on Rails for my private stuff. It's always a pleasure. On the other side, there are so few rails people available (compared to js) that it's not viable for any professional project. It would be irresponsible to choose that stack over js and often java for the backend.

  Anyone have similar feelings?

• by t-writescode on 5/4/25, 1:21 AM

  Frontend and Backend developers have never really been good at talking, for as long as I've been a developer.

  As a historically backend-developer, I've tended to dislike Html/JS/CSS. It's a meaningfully different paradigm from the Swing/Awt, WinForms, Android UX, etc. That alone was enough to frustrate me and keep me on the backend. To learn how to make frontend, I've had to since learn those 3. They're finally becoming familiar.

  BUT, for front-end developers, they needed to learn "yet another language"; and a lot of these languages have different / obnoxious build systems compared to nvm and friends. And then, like anyone who's ever changed languages knows, they had to learn a whole bunch of new frameworks, paradigms, etc.

  Well, they would have, but instead, some of them realized they could push Javascript to the backend. Yes, it's come with *a lot* of downsides; but, for the "Get Shit Done" crowd - and especially in the world of "just throw more servers at it" and "VC money is free! Burn it on infra!" these downsides weren't anything worth worry about.

  But the front-end devs - now "full stack devs" but really "javascript all the things" devs -, continued to create in a visible way. This is reflective of all the friggin' LinkedIn Job Postings right now that require Next.JS / Node.JS / whatever roles for their "full stack" positions. One language to rule them all, and all that.

  Just some ramblings, but I think it's strongly related to why people would choose Next.JS __ever__, given all its downsides.

• by austin-cheney on 5/3/25, 7:54 PM

  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.

• by petetnt on 5/4/25, 3:13 PM

  Great that it's working for them, but for the end user the feel of the site nearly unusable. There's 1s+ of delay on every interaction - pressing "home" button from explore tab takes 1,85 seconds (on a gigabit connection) before home view comes active, without any other feedback to the end user except for "Home" icon becoming active.

  You cannot just blindly trust the page speed metric but it should be impossible to miss things like this when you are actually using the site. Compare the experience to something like GoodReads that's using plain old SSR and you'll immediately notice the difference.

• by mountainriver on 5/3/25, 7:32 PM

  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

• by ummonk on 5/4/25, 1:19 AM

  I can't speak to the technical aspects here (I'm only familiar with nextjs not rails, so it's unclear to me how much of the article is just a reflection of the author's own comfortability with rails or a reflection of a more technically suitable architecture). But I do find it really weird that a company which apparently has multiple software engineers is worried about infrastructure costs amounting to less than $1k a month... Seems penny-wise pound-foolish to be worried about hosting bills.

• by henning on 5/3/25, 7:38 PM

  > 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.

• by qq99 on 5/3/25, 9:20 PM

  If you're thinking about going back to SSR, I think you owe it to yourself to check out Phoenix LiveView (Elixir) and play with it for an afternoon.

  I've built a few apps in it now, and to me, it starts to feel a bit like server-side React (in a way). All your HTML/components stream across to the user in reaction to their actions, so the pages are often very light.

  Another really big bonus is that a substantial portion of the extras you'd typically run (Sidekiq, etc) can basically just be baked into the same app. It also makes it dead simple to write resilient async code.

  It's not perfect, but I think it's better than RoR

• by hijp on 5/3/25, 8:01 PM

  I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.

• by swyx on 5/3/25, 8:46 PM

  > Our hosting bill grew from $30 in April to $142 by June, $354 in August. Hardcover was growing, but 10x cost increase in a few months was too much.

  without ANY irony or sarcasm, i just want appreciate that its funny how that happens completely without explicit desire or intention to have this effect from the developers of Next (i'm serious, don't hate me guys, we are friends, i do believe that this ofc is not intended)

  i'm sure there's a good and meaningful explanation (that I'm interested in reading) but lots of little microdecisions compound when the developer of the framework does not also experience it as a paying customer (or, more subtly, the developer of the framework wants to serve the 10000x larger enterprise customer and needs to make choices to balance that vs the needs of the small)

• by abhisek on 5/3/25, 7:46 PM

  Rail is probably one of the most intuitive framework that I have ever used. No doubt it is highly opinionated but it hides all the complexity for small to medium applications.

• by morsecodist on 5/4/25, 12:15 AM

  I feel like the elephant in the room here is that their back end was in RoR before Next.js and remained that way the entire time. They then switched from next.js to a framework designed, in part, with RoR in mind. It seems unsurprising that they had a much better experience using a thing that was tailored to their use case.

  I love Next.js. I have used other frameworks including RoR and there is nothing like it (except Svelte or Nuxt but I view them as different flavors of the same core idea). But I only use it to make monoliths. I can see getting frustrated with it if I was using it alongside a different back end.

• by littlecranky67 on 5/3/25, 8:04 PM

  I wonder why there is a debate Next.js vs. SSR. Nextjs is a hybrid and performs quite well. Contrasting with other SPA frameworks, Nextjs produces prerendered html output for fast first loads, efficient js chunks, config switches to eagerly-load those chunks (ie. when hovering over a link or preloading all n+1 links after page render) and efficient image (pre-)loading depending on breakpoint (usually the achilles heel when comparing to a pure SsR solution).

  I would really be interested in real world performance metrics comparing load times etc. on a stock nextjs app using defaults vs. rails and co.

• by ronbenton on 5/3/25, 8:31 PM

  The whole isomorphic framework trend has always scared the poo out of me. I feel like it's just asking for security issues.

  For people who commonly use these frameworks -- is it common to have issues where data or code intended only for server execution makes its way onto the client? Or are there good safeguards for this?

• by arvinsim on 5/4/25, 1:22 PM

  I fell in love with React because of its SPA approach, as opposed to SSR.

  You must imagine my chagrin when React started moving towards rendering on the server(SSR, Server Components, etc). I was happy to move to a full client implementation. Sadly, SEO cannot be ignored.

• by omneity on 5/3/25, 7:32 PM

  I 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.

• by joshstrange on 5/3/25, 7:49 PM

  I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe that can work offline?

  I looked at InertiaJS and it feels like too much "magic" for me personally. I've never used it so I could be wrong but it feels like too many things you have to get working perfectly and the instability in the JS ecosystem makes me worry about adding too many layers.

• by outlore on 5/4/25, 1:07 AM

  IMO the problem with Next is that it can’t decide whether it wants to be a framework for client side apps that require interactivity or server side rendered mostly static content sites. To support both it has codeveloped some baffling features in React like RSC which have made it far less fun to work with.

  “use client”, server actions that aren’t scrutable in a network tab, laggy page transitions, and, until recently, inscrutable hydration errors: these are some of the recent paper cuts I experienced with Next.

  I’d still use it for new projects, but I am keen to use TanStack Start when it’s ready

  i’m personally really interested in the next wave of frameworks that make local first development intuitive, like One or something that bakes in Zero

• by exabrial on 5/4/25, 1:00 AM

  Server Side Rendering is awesome and FAR simpler and productive and immensely less buggy. Hoping we continue to see people leave the js framework madness behind.

• by rustc on 5/3/25, 7:46 PM

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

• by bananatron on 5/3/25, 7:28 PM

  Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).

• by ezekiel68 on 5/3/25, 9:53 PM

  Even a cursory glance at the runtime performance difference between these two frameworks reveals that either this project won't scale to the point that cloud costs are relevant or they have a dubious prioritization of DX over deployment economy. We are talking orders of magnitude fewer RPS for Rails.

• by ww520 on 5/3/25, 8:55 PM

  For my most recent project, it was Spring Boot with Java at the backend and Solid.js at the frontend, with REST api in the middle. It has work very well. Solid has a very solid signal based React-style stack. Spring Boot is mature and stable that covers pretty much everything you need at the backend. The only wrinkle is we need to connect to a number of different database systems and the default DataSource can’t do the job. We ended up writing our own multi tenant datasource. We code gen most of the backend code for the hundreds of db tables. The path from DB to the frontend is automated. The whole project took 4.5 months with 1.5 junior developers and .5 architect and senior dev. One advantage is the business side has been nailed solid, with firm spec and feature sets.

• by insane_dreamer on 5/3/25, 10:13 PM

  Many SPA websites don't need to be SPAs, and the overhead in terms of complexity vs "old-fashioned" server-side ajax calls (even using something as "ancient" as jQuery) is not worth it, and do not improve the user experience.

• by dagorenouf on 5/4/25, 9:24 AM

  I followed the same journey but was unimpressed by Rails attempt at modernization with Hotwire. Decided to give Elixir + Phoenix a try and immediately fell in love. Just like I had with rails years ago. I highly recommend people to check it out, liveview is a game changer for building modern web apps without the complexity of JS, and without the baggage of using Rails to do it. And performance is mind blowing.

• by stevebmark on 5/3/25, 9:35 PM

  Is this article comparing apples and oranges? For example

  > loading the entire homepage only takes one query [if you're logged out]

  You can do this with Next.js SSR - there's nothing stopping you from reading from a cache in a server action?

  They also talk about Vercel hosting costs, but then self host Rails? Couldn't they have self hosted Next.js as well? Rails notoriously takes 3-4x the resources of other web frameworks because of speed and resources.

• by chagel on 5/4/25, 7:43 PM

  Exploring web programming from the frontend view (e.g., Island Architecture) is always intriguing. I'd love to see how JS/SPAs surpass the SSR/HTTP paradigm with LLM/AI. Until then, focus on mastering infrastructure, protocols, databases, and APIs — engineering over designing.

• by bckr on 5/3/25, 8:56 PM

  I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?

• by revskill on 5/3/25, 9:11 PM

  The problem with Next.js, is they over-engineered the whole things for no purpose. But i also think it's related to limitation of technical teams.

  "Simplicity is achieved when there's nothing left to remove".

• by moralestapia on 5/3/25, 7:59 PM

  I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx.

  Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.

• by dzonga on 5/3/25, 8:56 PM

  inertia is so nice. rescues you from the hotwire mess. you choose your own frontend framework could be react, vue, svelte while at the same time not spinning an api or dealing with client state etc.

• by chrisweekly on 5/3/25, 10:13 PM

  > "Sometimes it’s tricky to understand if a problem is in Rails, Inertia-Rails, Inertia.js, React.js or Vite."

  You mentioned giving up on Remix after poking at it for a day. IMHO that was a mistake.

• by reassess_blind on 5/4/25, 10:10 PM

  Express JS with Handlebars templating has always been my favourite. Simple, lightweight SSR rendered pages.

• by DuzAwe on 5/3/25, 7:31 PM

  So begins the slow roll backwards because ai can’t support the new.

• by kookamamie on 5/4/25, 11:07 AM

  I find it funny how the generation of content is now called ”server-side rendering” to make it sound cooler than what it actually is.

• by tonyhart7 on 5/3/25, 9:10 PM

  give it a few months the title would be: "why we go back to (another)JS framework"

• by lofaszvanitt on 5/3/25, 8:41 PM

  From one catastrophe to another. Good.

• by copperx on 5/3/25, 8:06 PM

  Rails is still wonderful. But someone should fork Rails so it ceases to be associated with DHH. CEOs who reveal who they really are become really toxic to the brand. We've seen that happen with Tesla.

• by welder on 5/3/25, 9:16 PM

  Just eww... you were an expert at Rails 10+ years, failed to become an equivalent expert at Next.js so you went back to what you're used to. You just didn't dive in deep enough.

  I was the same expert level with Python, now I'm using trpc, nextjs, drizzle, wakaq-ts, hosted on DO App Platform and you couldn't pay me enough to go back to Python, let alone the shitstorm mess that's every Rails app I've ever worked on.

  I've also not seen the 1s Next.js pageloads you had, but I'm confident of figuring a fix if that becomes a problem.