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.
We fell out of love with Next.js and back in love with Ruby on Rails
251–260 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#252Earlier 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…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#253Earlier 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
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#254Earlier 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.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#255Re: We fell out of love with Next.js and back in love with Ruby on Rails
#256We 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)
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“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
#258Just 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…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#259Re: We fell out of love with Next.js and back in love with Ruby on Rails
#260Earlier 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…
I greatly prefer Java with Spring Boot for larger backend projects.