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

171–180 of 533 posts

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

#171

Post by ramoz »

ezekiel68 wrote: post #156

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.

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

#172

Post by ezekiel68 »

bckr wrote: post #98

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

If you "screw up and succeed" by gaining many users/customers, any Ruby or Python framework provides orders of magnitude fewer requests-per-second on the same VM or hardware than a comparable solution deployed with node.js, go, Java, C# (Including DotNet Core on Linux), or rust. And this will quickly ballon your cloud compute costs to keep up.

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

#173

Post by tmpz22 »

dan_can_code wrote: post #72
ronbenton wrote: post #66

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?

Next.js has introduced some keywords such as 'use server' and 'use client' that you enter in the file at the top. Much like 'use strict'. If you attempt to use server code in a client file for example, it will get caught by the ts compiler / Linter. But for sure the lack of clear lines for where the server ends and the client begins has always been a pain of these kinds of framework offerings.

Not just accidental inclusion but intentional insecure inclusion. FE developer gets a BE ticket (because why not that's the whole point right?) and forces something through all proper-channels leading to trusted (server) code running on the client.

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

#174

Post by int_19h »

moralestapia wrote: post #69
grey-area wrote: post #45

Earlier quoted context omitted.

Websites. Most websites are significantly simpler to build and maintain with SSR and traditional tools. An entire generation has forgotten this it seems and still thinks in terms of JS frameworks even when trying SSR. As one example take this website, which serves the page your wrote your comment on using an obscure lisp dialect and SSR.

>Websites. Wait, is SSR a thing outside the context of websites?

There was a time when SSR was the only option. All early web apps were SSR.

It gets rather painful though, which is why we don't do that anymore.

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

#175

Post by freetonik »

nine_k wrote: post #75
stavros wrote: post #52

Earlier quoted context omitted.

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.

Unless you can guarantee RTT under 100ms, you have to manage some state on client side, else your UI will feel sluggish.

I’d rather have sluggish UI with proper feedback than potentially inconsistent states which I often experience with modern SPAs. At least that represents reality. Just today I was posting an ad on the local classifieds page, and the visual (client) state convinced me that everything was fast and my photos are uploaded. Turned out all state was lost and never reached the server, and I had to redo everything again.

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

#176

Post by ezekiel68 »

henning wrote: post #10

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

Yeap. Once I squinted hard enough at GraphQL, I realized it was a tantrum against coordinating front end calls with back-end API signatures efficiently, masquerading as a solution. A classic end-around.

What's funny is that people struggling after deploying it now think that they have invented the N+1 problem.

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

#177

Post by mattgreenrocks »

twodave wrote: post #22
rustc wrote: post #18

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

Probably something like ASP.NET MVC with C#

Yep. It’s ASP.NET. Arguably ASP.NET’s ORM is better than ActiveRecord even. With Blazor SSR you can use components on the server. IMO Blazor SSR needs a bit more time to bake and not reload is a huge mess currently. But the stack is great and will probably be undervalued simply due to the fact it is in C#.

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

#178

Post by twodave »

revskill wrote: post #115

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

That’s funny, after using it on a couple projects I felt that it was under-engineered/lacked some basic things I was used to having in other frameworks.
Post reply on HN