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

111–120 of 533 posts

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

#111

Post by cpursley »

drx wrote: post #12
mountainriver wrote: post #5

I’ve written a bit of rails and still don’t really get what the raving is about. It was perfectly fine, I didn’t find anything extra special about it. Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you

Rails has ActiveRecord, which has an extremely elegant REPL. It's a delight to use.

AR is the worst thing about Rails - it's anti-pattern central. The Ruby REPL is amazing, however.

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

#112

Post by 3sbi »

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 tracking app really need GraphQL, separate frontend framework and complicated build process or all that could have been solved by sticking to deploying monolithic RoR app with HTML templates on VPS from the very start?

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

#113

Post by pier25 »

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 don't know.

Many interactions are simply better delivered from the client. Heck some can only be exclusively delivered from the client (eg: image uploading, drag and drop, etc).

With HTMX, LiveViews, etc there will be challenges integrating server and client code... plus the mess of having multiple strategies handling different parts of the UI.

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

#116

Post by whatnow37373 »

qudat wrote: post #20
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,…

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…

> dramatically reduce complexity

If you ever worked seriously on anything non-SPA you would never, ever claim SPAs “dramatically reduce complexity”. The mountain of shit you have pull in to do anything is astronomical even by PHPs standards and I hate PHP. Those days were clean compared to what I have to endure with React and friends.

The API argument never sat well with me either. Having an API is orthogonal: you can have one or do not have one, you can have one and have a SSR app. In the AI age an API is the easy part anyway.

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

#117

Post by austin-cheney »

littlecranky67 wrote: post #48
austin-cheney wrote: post #27

When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.

But you are not just putting text on screen. That is a drastic simplification. To put text on screen, we had TV teletext/videotext. You can also just put a .txt file as your index.txt and serve that as your website. Or create a PDF from your word document. You won't need any developers at all for that.

Please don’t confuse method for intent. People tend to make that mistake as an equivocation error to qualify a mode of action. They do what they know and then extrapolate why they do it from what they have done.

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

#119

Post by catlover76 »

princevegeta89 wrote: post #60
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,…

As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the…

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

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

#120

Post by SJC_Hacker »

freeone3000 wrote: post #29
qudat wrote: post #20

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

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
Post reply on HN