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

471–480 of 533 posts

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

#471

Post by procaryote »

ysavir wrote: post #412
Capricorn2481 wrote: post #393

Earlier quoted context omitted.

That's still state on the frontend, which the commenter claimed sites don't need.

True, I shouldn't have said in memory. As the GP mentioned, you can store the counter value in a URL param. There are ways to achieve dynamic behavior without having to load or store values into JS memory.

That is more work both for the developers and the servers though. You need to re-render the whole page every change, rather than make a local change (or a tiny request if it needs to persist)

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

#472

Post by touristtam »

jakubmazanec wrote: post #395
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.…

> I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. Just use Gel [1] and you won't have to deal with ORMs (plus you get other great features). [1] https://www.geldata.com/

That's the type of comment I am looking for when I visit a BB such as this one. Looks interesting to say the least.

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

#473

Post by littlecranky67 »

WuxiFingerHold wrote: post #298
littlecranky67 wrote: post #37

I wonder why there is a debate Next.js vs. SSR. Nextjs is a hybrid and performs quite well. Contrasting with other SPA frameworks, Nextjs produces prerendered html output for fast first loads, efficient js chunks, config switches to eagerly-load those chunks (ie. when hovering over a link or preloading all n+1 links after page render) and efficient image (pre-)loading depending on breakpoint (usually the achilles hee…

NextJS has a lot of significant drawbacks, that's why there's an ongoing debate (which is healthy): - Cost - Complexity - Learning curve - Scalability - Frequent changes - And surprisingly bad performance compared with the direct competitors Nowadays, NextJS is rarely the best tool for the job. Next and React are sitting in the "never got fired for buying IBM" spot. It is a well earned position, as both had a huge in…

I challenge the "Bad performance" part.

NextJS generates by default all assets and js-chunks with a sha256 hash in the filename - essentially making them immutable. As outlined in the NextJS, I serve my assets folder with `Cache-Control: public, max-age=604800, immutable`. In a webapp where your users use your app on a semi-daily basis that means all assets and resources will be cache forever, or until you re-deploy a new version of the app. The data comes via REST (in whatever backend-language you want to use) so I don't see how any SSR can outperform nextjs here.

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

#474

Post by touristtam »

Zanfa wrote: post #343
_mlbt wrote: post #9

Earlier quoted context omitted.

The prevailing sentiment is that once you hit scaling issues with frameworks like Rails or Django you should have enough resources to simply throw money at the problem either in the form of more hardware, cloud computing, or better software engineers that can identify bottlenecks and optimize them. Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this…

If Shopify or Github can handle scale with Rails, maybe it’s not a framework problem.

Github can be horribly slow sometimes (tested from different machines and through different ISPs) and difficult to tell if that is down to the framework used to render the pages or any other parts of the system.

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

#475

Post by touristtam »

rc_mob wrote: post #34
rustc wrote: post #18

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

php8.4 with Laravel

Honest question: Why Laravel vs Symfony? I have no experience with the former and some with the later (albeit dated now)

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

#476

Post by victorbjorklund »

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.

Phoenix Liveview works pretty good without client side state. Sure if you just have a toggle mobile menu you might sprinkle some JS for it but other state lives in the server and the delta is sent to the client via websockets

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

#477

Post by ysavir »

procaryote wrote: post #471
ysavir wrote: post #412

Earlier quoted context omitted.

True, I shouldn't have said in memory. As the GP mentioned, you can store the counter value in a URL param. There are ways to achieve dynamic behavior without having to load or store values into JS memory.

That is more work both for the developers and the servers though. You need to re-render the whole page every change, rather than make a local change (or a tiny request if it needs to persist)

You misunderstood what I was saying. I was saying that you could write some plain old JS to catch an event on incrementing and updated the URL and the UI, and some JS to get the data from the URL on page load to set the UI. No new server render, and that's maybe 5 minutes of writing JavaScript code (compared to, say, setting up react project and instantiating that whole beast from the page root until reaching the specific UI element that needs to be dynamic).

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

#478

Post by ai-christianson »

hombre_fatal wrote: post #397
zozbot234 wrote: post #73

Earlier quoted context omitted.

> As a user, the typical SPA offers a worse experience. Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.) The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least…

> Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition SSR also has excess round trips by nature. Without Javascript, posting a form or clicking a like button refreshes the whole page even though a single changed from a "12 likes" to "13 likes".

I think most of the thread is talking about SSR with partial HTML replacement.

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

#479

Post by DanielVZ »

touristtam wrote: post #474
Zanfa wrote: post #343

Earlier quoted context omitted.

If Shopify or Github can handle scale with Rails, maybe it’s not a framework problem.

Github can be horribly slow sometimes (tested from different machines and through different ISPs) and difficult to tell if that is down to the framework used to render the pages or any other parts of the system.

A few years ago it started a transition to react. It has been less snappy ever since to me.

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

#480

Post by syndeo »

creakingstairs wrote: post #282
int_19h wrote: post #274

Earlier quoted context omitted.

Thing is, the browser back button is still there, though. So now you have two identical buttons that do different things. And that's really bad UX.

I’m split on this. I used to agree with you but when I talked to internal users and customers, they really liked having a back button in the app. I would tell them the browser back button is there and we haven’t broken history so it should work to which they just often shrug and say they “just” prefer it. My hypothesis is that they’ve had to deal with so many random web apps breaking the back button so that behaviour…

I think you're right on the money—those bad web apps that told people emphatically "do NOT use your browser's back button!" did the rest of us a lot of damage, as I really do agree that it trained many people to never press it unless they actually want to leave the app they're using.

I myself am guilty of (about 14 years ago now) giving an SPA a "reload" button, which had it go and fetch clean copies of the current view from the server. It was a social app; new comments and likes would automatically load in for the posts already visible, but NEW posts would NOT be loaded in, as they would cause too much content shift if they were to load in automatically.

Admittedly this is not a great solution, and looking back on it now, I can think of like 10 different better ways to solve that issue… but perhaps some users of that site are seeing my comment here, so yeah, guilt admitted haha.

/)

Post reply on HN