We fell out of love with Next.js and back in love with Ruby on Rails • Hacker News Board

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

#141

Post by x0x0 » Sat, May 03, 2025, 9:31 PM UTC

bckr wrote: post #98

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

Downsides:

Rails is a sharp knife. There is Rails way to do things. You may of course choose to do them differently (this is a contrast with other toolkits that fight this hard), but you are going to have to understand the system well to make that anything but a giant hassle.

With rails, the way it scales is statelessness. You have to map the front end actions to individual endpoints on the server. This works seamlessly for crud stuff (create a thing; edit a thing; delete a thing; list those things). For other use cases it works less seamlessly. NB: it works seamlessly for nested "things" too.

Complex multi-step flows are a pain point. eg you want to build data structures over time where between actions on the server (and remember, you must serialize everything you wish to save between each action), you have incomplete state. Concretely: an onboarding flow which sets up 3 different things in sequence with a decision tree is going to be somewhat unpleasant.

You must keep most state on the server and limit FE state. Hotwire works extremely well but the FE must be structured to make hotwire work well.

I've actually found it to work pretty well with individual pages build in react. My default is to build everything with hotwire and, when the FE gets too complex, to fall back to react.

Rails is nobody's idea of a fast system. You can make it perform more than well enough, but fast it is not.

Upsides, my take: it is the best tool to build websites. The whole thing is built by developers for developers. DX and niceness of tools are valued by the community. Contrast with eg the terrible standard lib that other languages (hi, js) have. Testing is by far the most pleasant I've used, with liberal support for mocking rather than having to do DI. For eg things like [logic, api calls, logic, api calls, logic, db calls] it works incredibly well. It is not the most popular toolkit and it's not react, so that can count against you in hiring.

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

#142

Post by microflash » Sat, May 03, 2025, 9:31 PM UTC

quantadev wrote: post #8

omneity wrote: post #4

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

The right tool for a given problem is usually much more ergonomic and productive. To me purism of language or tooling is a disservice to an engineer’s instinct of solving a problem. Use Python where it is a strong option. Use Spring Boot where it makes sense.

BTW, I’m also on a similar trajectory using a mix of Java, Python and Node.js to solve different problems. It has been very pleasant experience compared to if I had been bullish on just one of these languages and platforms.

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

#143

Post by quantadev » Sat, May 03, 2025, 9:31 PM UTC

omneity wrote: post #13

quantadev wrote: post #8

Earlier quoted context omitted.

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…

I think that's very smart, thanks for sharing! With the prevalence of coding agents currently the cost of context/language switching is much lower and these best-of-breed multilang setups are likely to become more prevalent in the future.

Right, and when I "learned" Python it was basically by asking an AI agent to generate whatever I wanted to do, and then looked at what it generated. For example, I'd just say stuff like "How does Python do hashmaps?" or "How can I loop over this array", etc. AI wrote most of my AI Python code!

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

#144

Post by qq99 » Sat, May 03, 2025, 9:32 PM UTC

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

Can't speak to ORMs, but I'd have a look at SolidStart. If you need an API, add in tRPC. End result is highly typed, can do SSR, and once you get used to it, it's a much better experience than using React.

I still haven't found an ORM with JS that really speaks to me.

> there are so few rails people available (compared to js) that it's not viable for any professional project

I don't think this is true; Shopify is a Rails shop (but perhaps it's more accurate to say it's a Ruby shop now). It feels easy to make a mess in Rails though, imo that's the part that you could argue is irresponsible

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

#145

Post by ivan_gammel » Sat, May 03, 2025, 9:32 PM UTC

stavros wrote: post #52

qudat wrote: post #20

Earlier quoted context omitted.

Having a server provide an island or rendering framework for your site can be more complex than an SPA with static assets and nginx. You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE. And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features. So ho…

I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

Client-server model is known for decades, state management between them isn’t hard.

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

#146

Post by dmix » Sat, May 03, 2025, 9:32 PM UTC

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…

> Especially if you're working on something that requires interaction with the page that you will be repeating over and over again.

That’s honestly not that many things IRL. If you look at all the things you build only a minority actual demand high interactivity, or highly custom JS. Otherwise existing UI libraries cover the bulk of what people actually need to do on the internet (ie, not just whatever overly fancy original idea the designers think is needed for your special product idea).

It’s mostly just dropdowns and text and tables etc.

Once you try moving away from all of that and questioning if you need it at every step you’ll realize you really don’t.

It should be server driven web by default with a splattering of high functionality islands of JS. That’s what rails figured out after changing the frontend back and forth.

> Even with auto reload in PHP, .NET, etc you will be wasting so much time

Rails has a library that will refresh the page when files change without a full reload, using Turbo/Hotwire. Not quite HMR but it’s not massively different if your page isn’t a giant pile of JS, and loads quickly already.

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

#147

Post by quantadev » Sat, May 03, 2025, 9:35 PM UTC

CooCooCaCha wrote: post #77

quantadev wrote: post #15

Earlier quoted context omitted.

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow. I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. S…

I’ve been saying this for a long time. It takes very little effort to spin up a react app so there’s little point in starting a project without it or whatever front-end framework you prefer. As I’ve become more senior I’ve realized that software devs have a tendency to fall for software “best practices” that sound good on paper but they don’t seem to question their practical validity. Separation of concerns, microser…

I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.

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

#148

Post by stevebmark » Sat, May 03, 2025, 9:35 PM UTC

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.

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

#149

Post by AlchemistCamp » Sat, May 03, 2025, 9:35 PM UTC

pier25 wrote: post #113

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

I don't know. Many interactions are simply better delivered from the client. Heck some can only be exclusively delivered from the client (eg: image uploading, drag and drop, etc). With HTMX, LiveViews, etc there will be challenges integrating server and client code... plus the mess of having multiple strategies handling different parts of the UI.

Hours so? I’ve found that Phoenix LiveView has made integrating the server and client code much simpler. It’s dramatically reduced the need to write JavaScript in general, including for things like image uploads. Or are you speaking of one of its many clones?

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

#150

Post by qq99 » Sat, May 03, 2025, 9:36 PM UTC

bckr wrote: post #98

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

The biggest downfall in my experience has been it can be a massive pain to find out where a method is defined in a huge codebase, especially with all the crazy ways in which one can declare methods. You can spend a non-trivial amount of time just trying to find the definition for a method.