Why We Develop with Ruby on Rails in 2024

Our team has experience developing with Ruby on Rails since 2006 when the Ruby on Rails: Up and Running book was released. In 2006 it was a pleasure to work with an opinionated framework that nicely handled models, views and controllers (MVC).

Fast-forward almost 20 years and it continues to deliver a great MVC experience, but it has added many other features that simply work out of the box. Delivering and receiving email, storing files or managing rich text are just a few examples of native framework features that we use in virtually every project.

In this post we'll offer some of the reasons that we continue to prefer developing with Ruby on Rails in 2024.

Forgo Opinions for Efficiency

Ruby on Rails is an opinionated framework. If you ever deviate from these opinions, it will let you know with a world of pain. We think this is a positive! When new developers join the team, if something seems "too hard" it is mostly likely because the implementation is going against the grain of the framework.

As a team, we're ok with accepting reasonable defaults and embracing conventions. The Model-View-Control implementation that Ruby on Rails offers works perfectly well for virtually every web application that we have developed. Sometimes we abstract away more complex logic into services, but overall our large projects don't deviate much from a call to rails new.

We appreciate that losing some options may be seen as a negative by those who want more fine grained control. For some projects that control is quite possibly needed. We tend to focus on delivering immediate end user value and the out-of-the-box Ruby on Rails framework components tends to get us there quickly without sacrificing the ability to scale down the road. We've never thrown out a MVP in the name of rewriting it as "enterprise" software.

Mature and Complete Package Ecosystem

Ruby on Rails has a fantastic package ecosystem through rubygems. The fact that some gems are less active is actually a positive for us as we do believe in things becoming "feature complete". Our industry is so obsessed with the latest and greatest (along with a lot of commits), however, when things work and the underlying principles remain valid there is no need for a bunch of change. For example, the devise gem for authentication has served us wonderfully and the package is at least 12 years old.

It is rare that we encounter a situation where we cannot find two or three versions of mature gems to solve a problem. Sure, we have our favourites, but virtually any of the popular choices in the community are good choices.

Super Powers for Small Teams

The small team productivity that Ruby on Rails offers has still never been beaten in our mind. The ability to start a project, add Bootstrap and then generate scaffolding for an initial set of models is amazing. The ability to give developers just enough database tooling via migrations saves the need for deep database expertise until much later in the project. The simplicity of ERB for views means that designers and UI/UX staff can instantly work with views while avoiding the code.

The recent introduction of HOTWIRE (including turbo streams and turbo frames) along with Stimulus.js has brought new life and interactivity to the framework that would have been looked to in heavier frontend frameworks. There is no drag like managing the interface between the "backend" and the "frontend" like marshaling a bunch of ruby objects into JSON to then parse them back into JavaScript objects. No client or user has ever asked for this overhead.

NoOps Deployment

Ok, a bit of a stretch, but the idea of NoOps (as in no operations) implies that a system is so straightforward that it can run without an operations team. Thanks to bedrock services like Heroku, open source alternatives like dokku and the new IaaS approach with Kamal and Docker, deploying a Ruby on Rails project is straightforward and functional from day one.

We've deployed, scaled and maintained applications in consistent and low-risk ways for years thanks to these above choices. They also alolw us to run on infrastructure that is a fraction of the cost of more complex architectures (yes, we've played with the big boys) but you would be surprised what can run on a $10/mo DigitalOcean droplet.

Great Community

Since the beginning, we've had nothing but a positive experience watching and participating in the Ruby and Ruby on Rails community. It is a supportive group of individuals that not only understand that Ruby on Rails is based on a language invented to maximize developer happiness but that we're all working on the same base.

The lack of variations in the core framework allows the community to consolidate expertise and experiences in a way that is difficult in other piecemeal development ecosystems. Questions are answered quickly on StackOverflow or GitHib issues and there are an amazing set of community leaders that create A+ content to further you Ruby on Rails skills. Some of our favourites include , SupeRails, CJ Avilla and Ruby Weekly.

If you're new to Ruby on Rails, or thinking of giving it a try then we believe you have made a great choice and are on a productive path for years to come. If you have been a Ruby on Rails developer and are contemplating another path, well, we've tried them all and all we can say is that we still choose Ruby on Rails!