5 ms·

I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other th

I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other than that? Pure HTML. It’s downright lovely. And it’ll still work fine 20 years from now.

bibstha 2y ago
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.
dmix 2y ago
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.
- pier25 2y ago
  Or maybe HTMX
  - nop_slide 2y ago
    Hotwire is basically a higher level HTMX
squidsoup 2y ago
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?
- anonzzzies 2y ago
  Never had those issues. It is just frontend job protection blah. No one should listen to it really.
- adamtaylor_13 2y ago
  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.
  - squidsoup 2y ago
    > 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.
    - adamtaylor_13 2y ago
      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.
  - owebmaster 2y ago
    your 3 steps can be summarized in just one? Step 1 - don't grow
    - adamtaylor_13 2y ago
      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.
owebmaster 2y ago
> And it’ll still work fine 20 years from now. bold claim. A Rails project of 20 years would not work fine today without a lot of work.
- adamtaylor_13 2y ago
  Well not if you didn’t do occasion, very light maintenance lol. It’s like a car. If you’re going to run it, you’ll need to do periodic maintenance. I didn’t claim you could run it for 20 years without touching it.

bibstha 2y ago

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.

dmix 2y ago

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.

pier25 2y ago
Or maybe HTMX
- nop_slide 2y ago
  Hotwire is basically a higher level HTMX

squidsoup 2y ago

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?

anonzzzies 2y ago
Never had those issues. It is just frontend job protection blah. No one should listen to it really.
adamtaylor_13 2y ago
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.
- squidsoup 2y ago
  > 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.
  - adamtaylor_13 2y ago
    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.
- owebmaster 2y ago
  your 3 steps can be summarized in just one? Step 1 - don't grow
  - adamtaylor_13 2y ago
    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.

owebmaster 2y ago

> And it’ll still work fine 20 years from now. bold claim. A Rails project of 20 years would not work fine today without a lot of work.

adamtaylor_13 2y ago
Well not if you didn’t do occasion, very light maintenance lol. It’s like a car. If you’re going to run it, you’ll need to do periodic maintenance. I didn’t claim you could run it for 20 years without touching it.