100%, Turbo and stimulus will save projects from React/Vue hell for 95% of cases. The other 5% you can make isolated fancy JS stuff without it eating the entire frontend.
I maintain an app that was originally written in 2011 in Rails, and a lot of old code looks very similar to what we have in Rails 2025.
It's very easy to dig into existing code. Feels really good.
Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?
Step 1: Resist the urge to overcomplicate.
Step 2: Don't build multiple applications that need shared components.
Step 3: Profit
I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions.
Having 2 apps that operate slightly differently is okay—even under the same brand.
> Having 2 apps that operate slightly differently is okay—even under the same brand.
Perhaps if you those two apps are in completely different domains, but if you have a suite of apps that are all related, maintaining consistent styling and behaviour provides a much better user experience.
Essentially what you're saying is rails isn't capable of solving that problem, and if you're talking about efficiencies/profit, implementing a component _once_ is a better strategy, and actually less complicated than two similar implementations of the same component.
Rails can certainly handle those issues. I’m commenting on your example which isn’t a problem anyone _needs_ to solve.
I’ll also point out, sure, better UX, but again—not profitable. Look at Microsoft, one of the largest software companies in the world and people still use their awful products despite no consistent UX.
This isn’t a Rails problem, it’s a leadership problem.
Yep. That’s basically Basecamp’s philosophy and it’s worked pretty damn well for them.
Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe, “Don’t grow” is a great philosophy. If you do happen to hit that 0.1%, congratulations you’ve got money to tear everything down and rewrite it in the JavaScript framework du jour.
> Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe
This is like gym beginners worrying they'll get too bulky overnight. You don't want to start with a don't grow philosophy. That's a thing to think when you are big enough.
I’d say it’s the opposite. Choosing Rails is understanding what is important. To follow on your metaphor, beginners worrying about becoming too bulky should be worrying about getting adequate nutrition and rest; the basics. That’s Rails.
You can start with a Don’t Grow mentality. I have, and it’s working out great. My company makes choices based on that principle, and we’re profitable. But we understand that we don’t want to be a huge corporate conglomeration and never will be.
And other than that? Pure HTML.
It’s downright lovely. And it’ll still work fine 20 years from now.