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

31–40 of 533 posts

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

#31

Post by willsmith72 »

lazypenguin wrote: post #19
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…

That’s absurd, that’s like saying we should only use C++ for backend code because my CRUD business app might one day scale to infinity. Better be safe than sorry and sling pointers and CMake just in case I need that extra juice!

Not really. If you use react router, you can have a client side js app and add SSR with a couple of hours work. You have your cake and eat it

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

#32

Post by qudat »

abhisek wrote: post #17

Rail is probably one of the most intuitive framework that I have ever used. No doubt it is highly opinionated but it hides all the complexity for small to medium applications.

It’s funny how some claim it’s intuitive while others complain about its magical nature.

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

#33

Post by hijp »

I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.

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

#35

Post by pjerem »

rustc wrote: post #18

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

Unironically, if you want something as mature as Rails, with batteries included, and static typing, the closest in my mind is aspnet core.

It’s honestly a really underrated framework, smartly designed, with probably the best ORM that exists and a great ecosystem.

Unfortunately, the documentation is painfully bad and the Getting Started guides are really boring compared to Rails or Django.

There may also be Laravel but I can’t say anything about it since I never tried it.

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

#36

Post by freeone3000 »

quantadev wrote: post #15
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,…

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 idea that apps can never be done and can never stop adding new features is the key determiner of web bloat. This is the problem.

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

#37

Post by littlecranky67 »

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 heel when comparing to a pure SsR solution).

I would really be interested in real world performance metrics comparing load times etc. on a stock nextjs app using defaults vs. rails and co.

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

#38

Post by recursivedoubts »

moralestapia wrote: post #30

I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx. Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.

when your app is mostly text-and-images

https://htmx.org/essays/a-real-world-react-to-htmx-port/

https://htmx.org/essays/when-to-use-hypermedia/

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

#39

Post by timewizard »

_mlbt wrote: post #14
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,…

People also forget just how far you can get without using client side JavaScript at all today. HTML and CSS have a lot of features built in that used to require JavaScript.

The best approach is to use both. Which is why I never understood the pure server side or the pure "reactive" approach. Having to manage rendering in server side code is pure pain, and having to return DOM markup from inside a function is likewise just madness. They both break the separation of concerns.

The first framework I ever got to use was GTK with Glade and QT with designer shortly there after. These, I think, show the correct way to arrange your applications anywhere, but also it works great on the web.

Use HTML and CSS to create the basis of your page. Use the and mechanisms to make reusable components or created widgets directly in your HTML. Anything that gets rendered should exist here. There should be very few places where you dynamically create and then add elements to your page.

Use javascript to add event handlers, receive them, and just run native functions on the DOM to manage the page. The dataset on all elements is very powerful and WeakMaps exist for when that's not sufficient. You have everything you need right in the standard environment.

If your application is API driven then you're effectively just doing Model-View-Controller in a modern way. It's exceptionally pleasant when approached like this. I have no idea why people torture themselves with weird opinionated wrappers around this functionality, or in the face of an explosion of choices, decide to regress all the way back to server side rendering.

Post reply on HN