Live data from Hacker News

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

hardcover.app

101–110 of 533 posts

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

#101

Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).

Languages with stronger types like typescript (unfortunately) perform much better than dynamic languages like Ruby, Elixir or even plain JS in an AI editor world. Because the editors are type smart and you can quickly pop the type error into the AI chat and it will attempt to correct it. The feedback cycle is just insane. I really hate to say it, but Typescript has won.

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

#102
post #98

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

I tried rails when it was pre version 1 and the early stages. I always felt like rails is very powerful and lots of things feel like magic until you come to a point where you want something that isnt implemented in that way.

You can prototype stuff very fast with rails and its a mighty tool in the right hands.

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

#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 often see myself going back to Ruby on Rails for my private stuff. It's always a pleasure. On the other side, there are so few rails people available (compared to js) that it's not viable for any professional project. It would be irresponsible to choose that stack over js and often java for the backend.

Anyone have similar feelings?

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

#104
post #20

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…

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things.

Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.

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

#105

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

"Right-sizing" is probably the most diplomatic take on all tech churn. It's the right way to look at it. It's not that we're done with it once and for all, it's just it's not the end all be all that conferences/blogs/influencers make things out to be. It's more of an indictment of the zealotry behind tech evangelism.

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

#106
post #7

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

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 (have you seen these relatively thin models and controllers?), as well as established dependencies and the lack of tendency to bikeshed in libraries (geocoder or devise for example have been mostly stable over close to a decade, with few popping up to replace it)

> 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 much either, partly because of the history of breaking changes over releases. And the Ruby language also doesn't help because of the prolific globals/overrides and implicitness which makes for "magic".

So you're encouraged/forced to write exhausting tests for the same (normally dumb CRUD) code patterns over and over and over again. Effectively testing the framework moreso than your own "business logic", because most of the time there barely is any extra logic to test.

So I'm also surprised it gained the reputation is has.

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

#109
post #78

Earlier quoted context omitted.

You had to manage state on the frontend even before spa though, if you wanted anything but the most basic experience.

Not between page loads.

You absolutely did. It was common practice to stuff things in cookies or query strings to retain state between trips to the server so that some JS could do its job.

Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.

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

#110
post #67

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.

If you reduce things so much that all detail is lost, you can't really reason about the original thing any more. The obvious counterpoint here is, you try turning amazon.com into a plain TXT file and see how much sales increase.

I would use a craigslist skinned amazon.
Post reply on HN