Why You Shouldn’t Sleep on Ruby on Rails in 2022

First released to the public in 2004, Ruby on Rails is an open source web-application framework written in the Ruby programming language. We sat down with Carbon Five Director of Engineering Matt Brictson to discuss all things Ruby on Rails, including the benefits of using Rails versus an all-Javascript stack, what’s in store for the upcoming Rails 7, and why many bootcamps don’t teach Rails anymore (even though they probably should).

How did you first get started working in Ruby on Rails?

I was doing a lot of programming in Java and Python early on in my career, and it felt like there was a lot of ceremony when dealing with Java — it could be hard to get stuff done quickly. I had been hearing a lot about this thing called Ruby on Rails that promised a faster on-ramp into building, especially for greenfield projects.

When an opportunity came along for me to work on a greenfield app, I decided to try using Rails. This was around 2011, when Rails had just moved from version 2 to version 3, and it was a pretty big generational shift. Things started settling down, it was a little less of a Wild West, and a little bit more mature of a framework. It seemed like the stars were aligning and that it was the right time to jump in.

What do you enjoy about working in Rails?

What sets Rails apart is that it’s an extremely opinionated framework, and those opinions are informed by the idea of building web apps quickly that are going to be useful for end users. If there is something you want to do in Rails, chances are the authors have thought of it, and the framework implements a good set of best practices that you can leverage with very little effort. And Ruby is an extremely expressive language, so these incantations require very little code. As a result, Rails has a reputation of being a little too magical.

That magic can be controversial, because some people find it beneficial to be able to see exactly how the system is working. In Rails there’s a lot of stuff hidden away from you, but most of the time it does exactly what you want. It almost feels intuitive —  you only write a few lines of code, or maybe none at all, and you get some great functionality right out of the box. So as long as what you want to build is in alignment with what the creators of Rails anticipated that you will want to build, things go remarkably smoothly. The things that are common from web app to web app are already decided for you, so you can focus your time on what makes your product unique.

What do you think is the value of learning or even mastering Ruby on Rails as a developer?

At Carbon Five, we place a lot of value in collaborating across disciplines. It leads to really good outcomes if you have close-knit teams that have design, engineering, and product all represented. Rails is a framework that gets out of your way and lets you experiment and iterate quickly. I think those are really powerful things, especially if you’re working with non-technical folks, because sometimes someone on the team will say, “I have this idea. Can we try it out?” As an engineer, you can turn that around and get them a prototype very quickly with Rails.

Knowing Rails allows engineers to more effectively participate in that sort of iterative development. If you’re on a small team — and you’re maybe the only engineer, or only one of a few engineers — you can get a lot done and have some good back-and-forth conversations and exploration with folks from other disciplines.

What’s been going on in the Rails community recently? What are people talking about?

Rails is currently on version 6.1, and version 7 is on the horizon. Rails 7 is bringing some pretty big changes in the world of front-end development — and the front-end community moves really fast. It seems like every month there’s a new hot framework, or a discussion about the best way to implement CSS, or the best framework to use for client-side code.

What interests me about Rails 7 is that it looks like it will offer a menu of options for how to deal with JavaScript and the front-end stack. There’s a heavily opinionated stack called Hotwire that’s being promoted by the Rails maintainers, which is pretty niche. It isn’t widely popular in the JavaScript community right now, but it does have that Rails-esque promise of being able to deliver some impressive features very quickly for developers. I’m curious to see what it will offer.

It seems like many bootcamps don’t teach Ruby on Rails anymore. Why do you think that is?

JavaScript is kind of taking over the world in terms of programming languages. Fundamentally, the web is made up of three things — HTML, JavaScript, and CSS. JavaScript is baked into the heart of what the web is, and more and more software is being built using it. A lot of mobile apps are also written primarily in JavaScript these days.

So as a developer, if you know JavaScript, it probably gives you the broadest range of opportunities. If you were only to learn one language, I think JavaScript should be it, but I do think there’s still room for Rails, and I think there are certain advantages of learning it.

If you pick up JavaScript, it’s true that you can use it everywhere, but on the flip side, it’s also a little bit different everywhere that you use it. For example, if you’re building a web app in JavaScript, and you were to join two different teams, those teams would probably be using completely different technology stacks. So you’ll have some familiarity in terms of the core language itself, but the language is a very small piece of what constitutes the entire set of technologies that you use to deliver software, and those technologies vary a lot.

Whereas if one team is building an app with Rails, and another team is also building an app with Rails, you’ll likely be very comfortable on both of those teams because Rails prescribes a certain way of doing things. I think that’s why we value Rails a lot at Carbon Five — it’s still one of our go-to technology stacks, especially for greenfield projects, because we know that we are all proficient in Rails. We can quickly assemble a team, and deliver really fast. The commonality of having used Rails aligns people quickly.

You are one of the core contributors to Carbon Five’s Raygun project. What is Raygun, and what has been going on over there recently?

Raygun is kind of like the Carbon Five starter kit for Rails projects — we’ve taken what Rails gives you and made some tweaks here and there. Carbon Five has been around for a while, we’ve been working in Rails for a while, and we know how we like to use it. It’s not a big departure from what you get with Rails out of the box, but we’ve changed a few things to align more with how we work.

For example, we prefer using RSpec for testing, whereas Rails uses something called Minitest. So that’s an example of where Raygun is going to generate a new Rails app for you with RSpec instead of Minitest. It’s a small change, but it aligns with our testing philosophy and how we deliver Rails projects at Carbon Five.

Raygun is always evolving because we’re starting new projects and learning from existing ones all the time. We’re constantly optimizing to be able to get from zero to delivering features to a client as fast as possible, but without being over-prescriptive or limiting, since every client has different needs. We’ve been honing the balance in Raygun over the years to reflect that. And if you use Raygun, you’re benefiting from what Carbon Five is learning about how to deliver software quickly.

Is there anything else that people should know about Rails?

I’m a really big fan of Rails. It’s not in the spotlight as much as it was 10 years ago, but I want people to know that they shouldn’t sleep on Rails as a framework.

Interested in working on Ruby projects? We’re hiring! Looking for software engineers, product managers, and designers to join our teams in SF, LA, NYC, CHA. Apply at www.carbonfive.com/careers