Rails Isn’t Dead, Not Even Close. 6 Rails Advantages Keeping It Alive
Are you more of a visual learner? Jump to our video presentation on Rails advantages in 2019!
Last week we published “Ruby on Rails e-Commerce in 2019” where we used Rails, RefineryCMS, and Snipcart to create an online store. If you haven’t checked it out yet, it’d definitely be worth your time.
That said, something from the post stuck with me all week:
‘Is ruby on rails’ is one of my favorite things to type into Google because the search engine automatically suggests, ‘dead.’
I thought my colleague Max, the author, was being facetious to make a point. Ruby on Rails is a well-established framework with a thriving community. Plus Rails’ advantages provide efficient, practical, and time-saving solutions for building sites of any kind—not just e-commerce. So I found it hard to believe that the first assumption Google would make from “Is Ruby on Rails...,” would be “dead.”
Low and behold, it was no exaggeration. In fact, Google jumped straight there after typing “Is Ruby”:
Cool story, Hansel. So what?
The reason I find this so bizarre is because Google’s auto-predict isn’t just a random time-saver (fun fact though: it’s estimated that Google’s auto-predict saves 200 years of typing per day!). It’s also a great indicator of popular search trends. When you start typing, Google compares your first few words with millions of other searches. That way, they can make a highly educated guess about what you’re looking for.
Which means that in this enlightened year of 2019, there’s evidence to suggest that the most popular search for Rails isn’t anything like:
“Is Ruby on Rails compatible with x,y, or z frameworks” “Is Ruby on Rails difficult to learn” Or even, “Is Ruby on Rails fun to learn?”
No. The most popular seems to be “Is Ruby on Rails dead.”
To be fair, this isn’t only true of Rails. The same pops up with Django, Vue.js, Node.js, etc. For some reason, programmers are just obsessed with death. And while I can’t save ‘em all, I can make the strong argument that as of 2019, Rails is still alive and kicking.
So today I’m going to take a closer look at:
So let’s start by getting all that negativity out of our system.
Can’t we all just get along…
If you look at any dev forum, you’ll run into 4 types of critiques against Rails.
“It’s good, just not my thing”
“No thanks, Rails is on its way out”
The “sassy back-and-forth” between five-year-old coders:
And last but not least, the scathingly depraved (I’ve censored the rude or profane terms for my more sensitive readers):
In full transparency, that last quote is pretty old (2008) and the writer, Zed Shaw, is now gainfully employed. He may have also softened over time. The others, however, all come from just last year. And at the end of the day, most of the criticism comes from the fact that Ruby on Rails has a reputation for being a bit too easy to learn and use. As we said in the last post, most people think that if you can only build with Rails, you’re simply not a “true, hardcore dev.”
But whatever you may think about Rails, there are some undeniable advantages to the framework that come from the combination of three underlying elements.
Rails advantages built on 3 pillars
At its core, Ruby on Rails has three developer friendly components from which all its goodness flows. These are Model-View-Control (MVC) architecture, Conventions over Configurations, and the Don’t Repeat Yourself (DRY) mentality.
Because it’s the more complex of the three, let’s dive into MVC.
1. Model-View-Controller architecture
The Model-View-Controller (MVC) architecture is key—but certainly not unique—to Rails. I know, you’re probably familiar with MVC and you’re also getting tired of people asking what it is. But for those of us who need a quick refresher, it’s worth a quick look.
With MVC, software gets divided into three parts: model, view, and controller. Model is the logic behind the software in the form of data. It’s where, as they say, “the magic happens.” View is what the user sees when viewing the software (UI). Finally, controller handles the communication between the view and the model. Take a look at the following diagram from Girish Magram’s article:
Think about it like this:
Let’s say you’re super rich. So you decide to hire a personal assistant. We’ll call him Alfred. You woke up one day and realized that you wanted—nay, needed—a custom-built Lamborghini with the specialized plates “D3v L1f3.”
Congrats, you’re a baller.
You thought the Lambo (the model) would be a nice addition to your garage, so you told your controller, Alfred, to make it happen. You really don’t care how it gets done. You just want it done. So Alfred goes off and does his thing. Soon you walk out and see your brand new car (again, the model) in your garage so you stop to admire the craftsmanship. You don’t actually drive (you have chauffers for that, of course), you just want to view it as a display of your wealth.
Because the controller is given very specific tasks and only focuses on their execution, it means that others can pull and reuse those tasks (to follow our analogy, other people could hire Alfred to go find them a new car). Plus, having the controller be task-specific makes it really easy to find and repair bugs or update code as needed.
2. Conventions over configurations
Conventions over configurations is like the Rails mantra. You see it everywhere. If Rails had their own 10 commandments, this would be the first one.
But it’s become a cliché for good reason: it’s vital to Rails’ mass use and appeal. Rather than writing code for every single action you need performed, you can simply pull from pre-written conventions. There are a lot of different examples of conventions like Application Structure or Application View, but you only need to manually define what is not included in those pre-built conventions. As you can imagine, this is a huge time saver for devs.
And for all you type-A coders who like to tinker under the hood, don’t worry. You still have that option, too.
At the end of the day, you’re free to do whatever you want with Rails. However, right out of the gate you have a ton of pre-built conventions that, if you choose to use them, will save you countless hours in the future. This, by the way, has become even truer over the last 2 years. As the framework has evolved, the massive GitHub community has created more valuable gems to pull from—we’ll get into these soon.
3. Don’t repeat yourself (DRY)
DRY is probably the most important aspect of Rails. It’s like “going green” for the programming world. You recycle as much code as you can to keep your coding environment as clean as possible.
Reduce, reuse, and recycle.
The biggest payoff, though, isn’t the aesthetic simplicity of your code (though that is a nice bonus). At the heart of DRY, the real benefit is that you don’t have to go back and change the same lines of code over and over in different sections. So rather than changing the “header” of your code for every page of your site, you only have to change it once and the other pages will follow suit. Corey Schaffer has an excellent video explanation of DRY that can help further clarify if need be.
When writing code, though, most Rails fans whole-heartedly agree that less is more.
And it’s precisely these principles that made Rails so appealing, especially to younger devs in the entrepreneurial space. It’s also the combination of the three that makes Rails’ advantages indisputable.
The value of Rails in 2019
Ruby on Rails has multiple advantages for developers. Its 6 main advantages are:
Low learning curve
Technical flexibility
Community support
Gems
High marketability
Great fit for startups (it does scale)
Let’s get deeper into each of these so you can see the real value of Rails.
1. Low learning curve:
The language on which Rails was built, Ruby, was created by Yukihiro "Matz" Matsumoto to be simple to learn and easy to use. David Heinemeier Hansson, the creator of Rails, followed suit. It should be no surprise, then, that Ruby on Rails has a reputation for being easier to learn than other, more complex frameworks. And this isn’t necessarily a bad thing no matter what “hardcore devs” may say.
But here is the most common question I see in forums and one that shouldn't be asked at all:
“How long will it take me to learn Ruby on Rails?”
It’s a bad question because there’s no “one-size-fits-all” answer. It will depend on your technical background, knowledge base, and familiarity with web development. Starting from scratch, you’re looking at a year or two to make sure you have a handle on the basics (but, again, the basics being a separate course of study than Ruby on Rails).
Already have a good foundation? Some people claim to have learned Rails in a matter of months. Realistically, you’d probably be looking at 6 months to a year, depending on how much time you can put in. Regardless, it definitely has a reputation—for better or for worse—as having a low barrier of entry.
So for an up-and-coming programmer looking to get into the field, it’s easy to see why Rails would be a tempting option!
2. Technical flexibility
Please don’t misread that as, “Well, technically, it’s flexible.” What I mean is that in terms of its technical capabilities, Rails is very flexible. This comes straight from Conventions over Configurations (remember the mantra). Because Rails has pre-built conventions, there are a lot of things “working under the hood” that you never have to look at.
On the other hand…
...you can certainly pop that hood open if you want. You can add, remove, customize, or tinker with any aspect of your site to your heart’s desire. You just don’t need to.
3. Vocal Community
I had always heard rumors about how nice the “Rails community” is, but it was never more clear than after publishing last week’s article. Here was a comment we received from Reddit:
That was on Reddit.
Let me repeat. Reddit, people!
Hands down that was nicest criticism I have ever received from Reddit. And it wasn’t unique. Most of the comments received were positive or, at the very least, constructive and as I read through other peoples' questions/threads, it was all the same in every Rails forum!
Knowing that you have a Rails army behind you to shoot either your troubles or the breeze when you need them is very comforting. Still not sold? Just go into some Rails forum and see for yourself!
4. Gems
Ok, this one is an offshoot of number 3 but Rails’ library of gems is an incredible resource for devs. If you’re unfamiliar with gems, they’re essentially home-built apps/features (or packaged libraries) that are then shared with others. They can be installed using the tool RubyGems and you can run them on your own Rails site in the same way that you would use a “plugin” for WordPress.
Packaged libraries are not unique to Ruby (though calling them “gems” was brilliant marketing), but that doesn’t take away from the fact that Rails is well stocked. As the community has grown, so has the number of gems. Rails users are encouraged not only to contribute gems to the community but to improve RubyGems’ site itself.
For developers, this means that the features for their Rails’ site are ever expanding. If they run into problems, they have loads of enthusiasts to turn to for support who have (presumably) already used the same gems.
5. High marketability
We definitely covered this in our last post, but it’s well worth repeating: there are loads of jobs out there for Rails developers. While there are no specific metrics to quantify how many—at least none that I can find—you can do a standard job search on any platform to see how prevalent they are.
In his article, “Demand for Ruby on Rails Is Still Huge,” Yoel Blum makes it as simple as running a job search in Linkedin. This is what he found:
San Francisco Bay Area:
Rails 1066Django 636Spring MVC 304ASP.NET 298
The list goes on, but you get the idea. Feel free to do a similar study in your own area and you're bound to get a similar result.
The bottom line? Job demand is still high for Rails’ devs.
6) Great fit for startups (it does scale, despite the rumors)
Due to the three pillars of Rails discussed above (MVC, Conventions over Configurations, and DRY), it’s an extremely practical framework for startups. Just take a look at the following Rails advantages:
Dev friendly coding language
Reusable code
Easy maintenance/upkeep
Parallel development
Quick site creation
Large community help
Pre-built features in the form of gems
And the list could go on, I’m sure. The point is that for a startup, all of these advantages equal money in the form of time saved. Plus, the quality and scalability of Rails’ sites are just as professional as other frameworks, if not more so.
I know, I know, Twitter left Rails because they couldn’t scale like they wanted to. But plenty of others have scaled just fine. Let’s take a look at some of those popular Rails’ sites.
Companies built with Ruby on Rails
Sure, some of these sites needed to get a bit creative to scale, but Rails is still the heart and soul of all these popular sites. The truth is that even though Twitter made the infamous switch away from Rails, that was back in 2009. If you’ve followed the 10-year challenge online, we all know a lot can change in a decade!
Closing thoughts and moving forward
Before all the “Yeah, but…” comments start flowing in, I want to make sure I’m being clear: At no point have I said (or will I say) Rails is better than X, Y, or Z framework. Saying that Batman is awesome doesn’t take away Superman’s powers.
Two things can be true at once.
It’s the same with Rails and other platforms. My only point here is that Rails certainly isn’t dead, isn’t dying, and will likely be part of the web dev world for a long time to come. In other words, whether your a novice web developer or a pro in the trenches, it may well be worth your time checking out Ruby on Rails for your next project. To help in your quest, check out a few of the following links:
Ruby on Rails Tutorial by Michael Hartl
That should be more than enough to keep you busy for a few days if you are just getting into Rails (or getting into the idea of getting into Rails). If you're already a pro Rails user, let us know what you thought about this article! We love questions, comments, and feedback of all kinds!
For our visual learners
If you've enjoyed this post, please take a second to share it on Twitter. Got comments, questions? Hit the section below!
