> sometimes it’s worth doing things just for the sheer hell of it.
Returning to Rails in 2026
171–180 of 254 posts
Re: Returning to Rails in 2026
#172[flagged]
is this really relevant anymore now that AI has gotten to the level it has? what used to take weeks to setup now take days (react, multiple backend services and infra)
Very relevant, because it typically takes a lot less code to express a feature in Rails/Hotwire than it does in a SPA with a dedicated back end. No need to maintain API contracts or ensure your UI code is properly async/awaited, etc., etc. Whether its a human or AI writing the code, SPA's add considerable complexity that just isn't necessary for most web apps.
Lower LOC to express a feature means better context management which pays dividends for things like code review.
Re: Returning to Rails in 2026
#173Earlier quoted context omitted.
Rust/Loco is unironically the most interesting framework right now. Loco follows up the Rails formula pretty closely, and makes easier to learn Rust by taking care of a load of boilerplate code.
Concur on most interesting! I really hope it works out, but am cautious. It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this…
It's quite a gap really.
I'll say this, coding agents make the lack of a "batteries included" framework like rails or Django somewhat less daunting.
But "convention over code" and having a default structure / shape for projects is extremely helpful and you feel it when it's missing.
For my last small project I looked at Loco but ended up passing on it because I felt like adoption wasn't great yet. I really hope it takes off, though.
Re: Returning to Rails in 2026
#174Thanks for such public confirming there is a lot of more us. I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures. I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Si…
I've just started using RoR for a live greenfield project since New Year. Honestly, breath of fresh air. It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso th…
I have my complaints about the JS/TS ecosystem, but I'm surprised to see a comment that it's verbose and "boilerplatey."
Could you elaborate on that?
Re: Returning to Rails in 2026
#175Thanks for such public confirming there is a lot of more us. I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures. I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Si…
I've just started using RoR for a live greenfield project since New Year. Honestly, breath of fresh air. It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso th…
If you're solving problems rails is best at, it's borderline magical.
The troubles arise when you get to huge codebases or complicated frontend patterns that aren't ideal for SSR / hotwire.
Also, it's impossible to separate Rails from DHH, whose xenophobic politics are unfortunately front and center.
Re: Returning to Rails in 2026
#176I always enjoyed Rails, it isn't perfect but is way better then others. I have node and nextjs projects :) when they blow it, it is a major mystery what is blowing up.
Have so many good memories working with Ruby.
If anyone has old codebase need to be updated and upgraded, refreshed. I am happy to do that.
Re: Returning to Rails in 2026
#177I’m honestly baffled by the praises of Rails in the comments. I started my dev career with php and then nodejs, but recently got a job with rails, and honestly, it’s the worst among the 3. There is no static typing whatsoever, it’s littered with magically generated methods, on a moderate size project the controllers or models directories grow to dozen of files. In general it feels like you need a lot of mental contex…
If you like Ruby but don't like Rails, take a look at Crystal, possibly with the Amber framework.
Re: Returning to Rails in 2026
#178Earlier quoted context omitted.
I've just started using RoR for a live greenfield project since New Year. Honestly, breath of fresh air. It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso th…
TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type al…
But we need contracts that go way further what static typing provides. If they add dependant types + ability to enforce the types at runtime so that you can use it on various inputs, then maybe it will be truly useful.
Re: Returning to Rails in 2026
#179I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project. Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is…
What is it about large untyped codebases that make it a nightmare?
If you make a change to the return types of a function for example you have to manually find all of the different references to that function and fix the code to handle the change. Since there are no compile time errors it's hard to know that you got everything and haven't just caused a bug.
Re: Returning to Rails in 2026
#180Earlier quoted context omitted.
Yes but GP said "In reality it's not that much".
Not much work every few months turns into a lot over years, especially if you skip a few of those "every few months" events.
I'm confused. It's too much work to upgrade dependencies, but not too much time to write from scratch and maintain, in perpetuity, original code?