Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hardcover.app

Post reply on HN
Print view View original

151–160 of 533 posts

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

#151

Post by karmakaze »

benblue wrote: post #134
karmakaze wrote: post #92

Earlier quoted context omitted.

ActiveRecord may be both the best and worst part of Rails. Currently the largest scaling problem that I'm facing is with all the before_* and after_* callbacks which run per model record rather than a batch of changed records. This is an N+1 query landmine field for which ActiveRecord offers no solutions.

I agree that ActiveRecord isn't particularly opinionated about how to deal with updates to batches of records, but there are multiple ways of approaching this and AR won't get in your way. upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks. activerecord-import[2] is also very nice gem that provides a great api for working with batches of records. It can be a…

By upsert_all not invoking model callbacks, it's admitting that the ActiveRecord approach doesn't scale.

"It can be as simple as extracting your callback..." Isn't this the kind of repetitive thing a framework should be doing on your behalf?

To be fair, ActiveRecord isn't a fault Rails invented. Apparently it's from one of Martin Fowler's many writings where each model instance manages its own storage. Even Fowler seems to say that the DataMapper approach is better to separate concerns in complex scenarios.

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

#152

Post by quantadev »

room271 wrote: post #57
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…

The problem is that people are frequently using SPA JS frameworks for things that are clearly not gmail of figma -- i.e. news websites and other sites with minimal interactivity or dynamic behaviour. If you are genuinely building an 'app'-like thing, then of course you need some kind of JS SPA framework, but too often people are reaching for these tools for non-app use cases.

I say if you have any reactivity whatsoever you need a framework. If you don't your code will be crap, and there's really no getting around that. Once you start doing DOM calls to update GUI you've got a mess on your hands instantly, and it will only get worse over time.

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

#153

Post by miragecraft »

wordofx wrote: post #47
copperx wrote: post #40

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.

What’s DHH done?

He’s politically naive. I agree with him on much, such as don’t make workplace political, and cancel culture and DEI have in many cases gone mad, but his tolerance, even gentle celebration of Trump in the name of free speech is a classic example of the paradox of tolerance.

https://en.m.wikipedia.org/wiki/Paradox_of_tolerance

However he is right in many cases, and I don’t expect anyone to be right all the time, myself included. It’s strange to look for political leadership from a programmer anyhow.

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

#154

Post by lmm »

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

> Every line of client JS brings build tooling, npm audit noise, and another supply chain risk.

IME this is backwards. All that stuff is a one-off fixed cost, it's the same whether you have 10 lines of JS or 10,000. And sooner or later you're going to need those 10 lines of JS, and then you'll be better off if you'd written the whole thing in JS to start with rather than whatever other pieces of technology you're using in addition.

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

#155

Post by chipsrafferty »

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

This is ChatGPT

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

#156

Post by ezekiel68 »

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.

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

#157

Post by lmm »

3sbi wrote: post #112

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

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL.

Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place.

Do you need a complicated build process? No. You want your build process to be just "run npm". And that's what something like Next gets you.

"Monolithic RoR app with HTML templates on VPS" would introduce more problems than it solves. If Next-style frameworks had come first, you would be posting about how RoR is a solution in search of a problem that solves nothing and just overcomplicates everything. And you'd be right.

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

#158

Post by jonnycat »

omneity wrote: post #123
thunky wrote: post #106

Earlier quoted context omitted.

> 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 Convention over configuration and less code is fine, but unfortunately Rails is not a great example of it IMO. The "rails" are not strong enough; it's just too loosey goosey and it doesn't give you much confidence that you're doing it "the right way". The docs don't help…

Do you have a recommendation for a better incarnation of the principle?

Phoenix with Elixir is for sure "a better Rails".

Although that's really selling it short - it's so much more than that! But in the context of this conversation, it's a good place to look.

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

#159

Post by tmnvix »

qq99 wrote: post #129

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

I've been curious for a while now. One thing that gives me pause though is how Phoenix LiveView apps perform when you're dealing with high latency. I'm aware that many apps will be serving primarily the US market and so might not recognise this as much of an issue. I'm also aware that I could deploy 'at the edge' with something like fly.io. Still, when I run a ping test to 100 different locations around the world from NZ, the majority of results are 300ms+. That seems like it would have a pretty noticeable impact on a user's experience.

TLDR; Are most Phoenix deployments focused on a local market or deployed 'at the edge' or are people ignoring the potentially janky experience for far-flung users?

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

#160

Post by Aeolos »

princevegeta89 wrote: post #135
catlover76 wrote: post #119

Earlier quoted context omitted.

What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?

The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic. So it can be a straightforward replacement for a traditional REST API that you would have to manually build. For the disadvantages, I cannot think of any. It is a bit slower than hand rol…

GraphQL APIs can easily DOS your backend if you don't configure extra protections (which are neither bulletproof nor enabled by default), they suffer from N+1 inefficiencies by default unless you write a ton of extra code, and they require extra careful programming to apply security rules on every field which can get very complex very fast.

On the plus side, it does have offer communication advantages if you have entirely independent BE and FE teams, and it can help minimize network traffic for network-constrained scenarios such as mobile apps.

Personally, I have regretted using GraphQL every time.

Post reply on HN