Rails is done
The core of Rails has stood the tests of time. To this day, it is a great way to build web applications. But DHH's view of the world is fundamentally incompatible with mine, and I'm not the only one who feels that way. About a year ago, a bunch of people, including me, signed an open letter to the core team to finally cut ties with him and hard fork Rails. That, unfortunately, did not happen. So it's time that we do it ourselves.
If you need more context on why Rails needs a new leadership, here is David Celis summing it up a year ago, Paul Battley a few weeks ago, and—even though it is hard to believe—it even got worse since then.
How could a fork even work?
Rails is a huge code base and has multiple engineers who can invest significant work time into improving it. How could a few people fork and maintain it in their free time? Because Rails is done. Since I started to update The Rails 5 Way to Rails 6 (and then later 7 and 8), I’ve been monitoring the changes to Rails closely:
If you generate a Rails application with rails new --minimal, you only get the core parts of the framework (railties, actionpack, activesupport, activemodel, activerecord and actionview). There is a lot of other stuff in Rails nowadays, but if you focus in on those parts, they are done. We haven’t seen any major changes to these core gems since Rails 6.0 in 2019 (outside of ActiveRecord1) with the introduction of the Zeitwerk autoloader. What has happened since are just additional components that are just gems or npm packages you could add if you fancy them:
- A series of asset pipelines.
- A set of JavaScript libraries you could use with Rails, or any other Ruby/PHP/Java/… framework.
- A deployment tool that can deploy any containerized web application.
- A reverse proxy written in Go.
- New default gems as backends for ActiveJob, ActionCable and caching.
Why is that? Because Rails is done, and that’s great! It covers the needs for web apps from small to large, and there is nothing you need to add to it. So if all we fork is the core and not all the optional gems you could add on top of it, we have a stable target. The job is to monitor the Rails repository for security patches and port them to the fork as well as look for performance and smaller improvements and evaluate if we should add them. This will be challenging, but doable.
Codename: Amiko
Right now, we have a really nice community building up in Matrix and spikes of how the fork will work. The current name is Amiko, but it will probably change before we do the first release. If this sounds interesting to you, join the community. You can find an entry point here.
Amiko’s primary goal is to provide an LTS version of Rails 8.x built and maintained by a community of people that do not tolerate nazis, transphobes, racists, or any kind of bigotry. The idea is that if you have an existing Rails 8.x application, you switch out the gems2, do a few search and replace operations, and your app is ready to go. We want Amiko to be boring and friendly.
Changes
We might also work on some flaws in Rails if we can do that without breaking compatibility. The asset pipeline comes to mind that has been in a state of absolute chaos of a dozen half-working approaches since the core team lost their frontend knowledge in 2021 when Basecamp imploded. We also discussed how amiko new could work if it wasn’t designed by someone who has not understood that if a chef serves the same meal to everyone, that’s called “fast food” and not “omakase”. But expect little changes to what you already know from Rails 6/7/8.
Why not Hanakai?
Ryan Big wrote a blog post that disagrees with Amiko’s goal. He suggested that instead we should all join Hanakai. And in a way we do. We join them in their mission and core values:
“The Hanakai community is a place where people of all backgrounds and experience levels can feel respected, and can share and grow. A place for people to be proud of, and feel safe within. We do not tolerate nazis, transphobes, racists, or any kind of bigotry.”
Like Tim Riley, we want Ruby to be a thriving ecosystem, not a monoculture. Please watch his excellent keynote that really inspired me. In our view, the perfect job queue works with Amiko, Hanami, and Roda. We see ourselves as another alternative among many awesome choices. And we want Amiko to be an especially great choice for everyone who has a big Rails app that they can’t “just rewrite in Hanakai” or that like the design of Rails, but not their leadership. If you want a completely different design than Rails, I encourage you to check out the awesome work of the Hanakai community. If you want an awesome static site generator with the option of adding server side logic, check out Bridgetown (which I use for this website, for example). And if you want to mix and match with Amiko as the web framework, Rom as your data layer and organize your business logic with Dry::Operation, you have embraced okonomi.
Conclusion
I hope we can all thrive together. We want to add a choice to the Ruby ecosystem, and join the other groups that want to build for a community of people of all genders, skin colors, sexual orientations, experience levels and backgrounds. We want nazis, transphobes and racists to run away screaming and will kick them out if they don’t. And we want to continue building our web applications without feeling icky.
Thanks
Thanks to Bodo and Dirk for their feedback ❤️
Footnotes
-
And most of the improvements were added in 6.1 in 2020, except for at-work encryption, asynchronous query loading, some authentication methods, and composite primary keys. ↩
-
With a clever alias hack so your dependencies will also use the forked gems. ↩