Live data from Hacker News

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

hardcover.app

251–260 of 533 posts

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

#251
post #171

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.

I don’t understand your integration of performance and cloud costs here. “Deployment economy” is also new. Rails has a very strong track record of matching internet scale. Cloud is highly optimized for traditional server applications. From my experience with Next.js - this is the opposite. A lot of deployment components that don’t naturally fit in, and engineering required to optimize costs.

Quite simply: at certain threshold counts of users you will be forced to add many more cloud instances/pods running Rails than you would need running node.js (or Java or go or many others). But it doesn't stop at instances because this will also require more persistent disk / object storage, more logs, more alerts, more notifications from the cloud provider that instance xyz needs to be restarted (due to a firmware upgrade or whatever), etc. etc. All of these have human management overhead costs and most of them increase monthly financial costs.

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

#252

Earlier quoted context omitted.

What is the specific pain? Are you just referring to dynamic content on the client in general or different issues?

The oldest web apps - web email clients being probably the canonical and most familiar example - didn't do dynamic refresh at all, because there was no way to fetch data from the server, so you couldn't do it even with JS. Any user action that required any part of the page to be updated involved a (very visible) whole page refresh. You could limit the scope of refresh with frames to some extent, but it was still very…

Oh, I'm familiar with the history. I was thinking maybe you had similar concerns (lack of dynamic content) with something modern like HTMX which is a modern take on Server Side Rendering -- but it does in fact include mechanisms for AJAX-like calls.

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

#253

Earlier quoted context omitted.

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

You haven’t had to deal directly with JS on front end since Dart released over 10 years ago

Does anyone use Dart without Flutter? I've never seen it used separately.

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

#254
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 think the DX is significantly better as well with fast reload… As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.

This exactly. It seems like the last 10 years of JavaScript framework progress has been driven by DX, not UX. Like at some point everyone forgot this crap just needs to work at the end of the day, no user benefits from 3 rewrites over 5 years because the developer community decided functions are better than classes.

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

#256
post #216

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

What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)

Not OP; but when I was thinking about using Next.JS, and doing a deep investigation, I came to the decision that, for server-side rendering, I'm quite happy to use Kotlin and Ktor (my backend is also Kotlin - I have a lot of client-types, which is why they're separate), and I've been quite happy with Ktor's html dsl + htmx for speed.

And Kotlin + Ktor feels very good to write in on serverside. Fast, easy and fluent to write in, like Ruby; but with Java's ecosystem, speed and types.

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

#257
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

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

#258
post #20

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

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…

You can accomplish the "don't have to reload the page to see my changes" with htmx and it's still "server-side rendering" (or mostly server-side rendering). Legendarily, the fastest website on the internet uses partial page caching to achieve its speed

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

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

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

#260

Earlier quoted context omitted.

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…

If you already know another backend language and framework, all you need to do is tell LLM or some code generator to convert your models between languages. There is very little overhead that way.

I greatly prefer Java with Spring Boot for larger backend projects.

Post reply on HN