Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).
We fell out of love with Next.js and back in love with Ruby on Rails
101–110 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#102I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
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
#103I 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
#104Just 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…
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
#105Just 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,…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#106I’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)
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
#107What's the closest thing to Rails in a language with a sound static type system?
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#108I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#109Earlier 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.
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
#110When 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.