In this episode of The Rails Changelog, DHH and I got to discuss a lot. Among what we covered are:
Kamal,
Rails 8,
Authentication in Rails,
The Rails Foundation & Rails World,
On Writing Software Well,
Delegated Types,
Exiting the Cloud,
SSDs and a lot more!
I've never had problems with upgrades, in fact the latest version of Rails make upgrading a breeze. What Rails app version are you trying to upgrade? Happy to help. Rails also has an upgrade guide that's quite good: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html
And you can use https://railsdiff.org/ to check what you're missing in upgrade apps. Anything other thing that breaks would most like come from another gem, which doesn't make it Rails' fault or Ruby itself, in the case of Ruby, you can track everything to the source to fix it. Ruby keeps a change log diligently. Everything is trackable, at least in my experience.
I've upgraded our moderately sized app from 3 to 4 to 5 to 6. Haven't gotten to 7 yet. This is widely accepted to be one of the most painful parts of rails, so I'm surprised you haven't had a problem. Maybe you've only upgraded small apps, or maybe only upgrade very recent versions (they are getting better). There are whole consultancies dedicated just to this task. Github and Shopify post about dedicating whole teams and tools just to the task.
Even with very high test coverage on a large app it is a huge and high risk effort to upgrade - there are so many deprecations and unnecessary behavior changes. The `belongs_to` now validates presence was especially egregious and arbitrary. Of course you can turn it off with a variable - but now we have a rails app that is a mix if defaults from 4 different versions of rails.
Rails has matured through the years, I'm convinced it's the right framework for any project if you already know it, you can get by with Hotwire for the FE and not run after React and the rest. Happy to be a Rails dev to be honest.
Rails is extremely easy to get started with but after a few years the lack of types on Ruby cripples every single Rails app I've ever worked on. You can have as many unit tests and browser automation tests as possible, but updating any gem is a dice roll despite doing as much due diligence possible. And it's always something extremely trivial like a method changing its parameters without announcing it in the change log for some reason. Something almost any other language would warn you about.
I've been doing Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks. The only advantage Rails still holds is the out of the box batteries included package. But once a TS framework gets this, Rails will be in decline.
> Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks
I think you're comparing a language/runtime with a framework here. I also prefer Node and JavaScript over Ruby but I get what you say, and I agree.
I think Adonisjs ticks all the boxes to be that framework in the future. It just doesn't have the community it needs to be 100% successful yet... with more adoption it will get all the missing features, documentation and little annoyances it might have today polished.
But something I'm worried about is if that the fragmentation is just too big at this point. I don't see people agreeing on a single "full stack" framework as it happened in other environments.
I think this happens because most other "big frameworks" were born when there were not that much competition and not that many people on their ecosystems, so there were a lot fewer options and people concentrated around those frameworks and made them grow to what they are today (Laravel, Rails, Django, Spring...).
The "backend JavaScript" ecosystem is a freaking mess. So many competing options, all of them terribly incomplete, all of them claiming to be "full stack" just because they can execute JavaScript on the server... yes, maybe "full stack" but without the battery... it's a lamborghini that you have to put together yourself before being able to use it.
Same thing that other people sat about Next.js, about Remix, Nest, Qwik, and the other 10 thousand that "are coming for the crown". In fact, that's the problem.
Used to work at a Rails shop, and led an effort to get type safety into the codebase. It was a nightmare that wasted endless time and added plenty of stress.
Sorbet is great on vanilla Ruby code that doesn't try to use too much arcane metaprogramming. It's "okay" on vanilla Ruby code that uses some arcane metaprogramming that humans can reliably reflect in RBS files. In a Rails codebase, which is (IMO) a huge ball of relatively hard to statically analyze magic and quite heavily uses all sorts of tricks for either API ergonomics/skimmability or for performance, it was a mess, and frankly, I had a pretty nightmarish time selling almost any of the feature set beyond (1) ADTs/Enums (2) the subset of Interfaces as exposed by `T::Struct`.
Sorbet is a herculean effort by some extremely talented devs. I don't at all want to discredit that. Tapioca is likewise an impressive DSL-reflection machine on top of RBS files, particularly post-0.8 release. But type safety in a Rails app is, at least in my experience, extremely high cost both upfront and maintenance.
To offer another point of view: I work on a recent Rails app that was set up with Sorbet/Tapioca from the get-go. All Ruby code is `# typed: strict`, and we (I) feel like the ROI is generally positive. It's caught more than one bug, and it's easy to eject from it when it gets in your way.
That said, type safety via Sorbet/Tapioca is ultimately an afterthought in Ruby and the DX suffers from it compared to languages where type safety is baked in. In my limited experience, MyPy in Python was even worse though.
As for RBS, I have literally never seen it used in the wild and I don't know why the Ruby core team bothers with it rather than go all-in on Sorbet.
(your comment made me realized I kept typing "RBS" when I meant "RBI" in a Sorbet context. oops)
Anyway, I did have my strong suspicions that Sorbet would pay off more in a codebase that used it from Day 1. Glad to hear at least one report that indeed, that was the case.
We evaluated them, it's just not there and it's unclear if it ever will be. DHH, the lead for the Rails project has indicated that Rails will "absolutely not" have a type checker in reply to a tweet asking about it. And a huge amount of work would be required from the Rails team to get type checking to work.
I've worked with a lot of Rails code bases over the last 10 years and just haven't ever experienced this problem from a types perspective.
Certainly, if you let gems start to get out of date the dependency chains to get them updated can become a task but that's fairly true of any language. It's one of the selling points for moving parts of an app to isolated services too.
Everything is a tradeoff though. I don't know that you can get the Aspect Oriented Programming gains that you get with Ruby and Rails with a more strictly typed language.
I dodged that, started getting serious with rails 3 and ruby 1.9+
No,there are still many undocumented breaking changes. I recently upgraded an old app from Rail 4 to 7 that used minimal non-rails stuff and was shocked by the corner cases.
Manu changes to activerecord api go completely undocumented, but they break the code nonetheless
There is no upgrade guide from 4 to 7,so I did from 4.2 to 5,from 5 to 5.1, from 6 to 6.1 and then to 7.
I actually found a bug that broke my app at version 6 that was resolved in 6.1,so technically my tests were not passing in version 6 and I did an "unsafe upgrade" to version 6.1
Maybe you can with heroic effort, but you shouldn't. You should build within the constraints of your tools. HW + Stimulus are great - good enough for what most web apps need to do. It gives you "traditional web app, with a bit of realtime updating" - which is the perfect fit for most web apps.
But you wouldn't want to use it for a fully interactive desktop style application with lots of interacting components.
Agree. So unless you have a pretty big budget and you're building Google Maps or Figma you shouldn't use React.
Sadly, everyone things they have such a big budget and they're building the next Figma. Even if you're building a CRUD app. (I'm talking to you previous team of mine).
You can do anything with plain JS too, but that doesn't mean you'd want to. The problem with Hotwire is that you do often have the server round trip in there. That's fine most of the time, it just gets a little harder to understand as the complexity rises. That's not to knock it, I think Hotwire is pretty good.
In what scenario would complexity be higher in a simple UI - server loop? Doesn’t complexity usually arise from having additional logic in the browser and maintaining state separately?
I guess it depends somewhat on how you imagine up something and write it. I was working on some drag and drop UI that had multiple sortable lists and an action area. Figuring the server side and UI at the same time didn't work out. I reversed and implemented the UI with its required state, and then it was easy to transform that state to what the server side required, and vice versa.
Complexity is tricky. Are three simple things more complex than one thing thats harder to understand?
You can still use React or whatever on those pages. And for the rest (settings pages, signup pages and all the CRUD pages) you can use standard Rails with Hotwire.
