Every year, we’re pelted by articles proclaiming the death of this gem of a framework. And while Ruby on Rails (RoR) is almost 15 years old, it’s nowhere close to passing on from the world of programming.
Why use Ruby on Rails you’re wondering? In fact, there are many use cases where RoR offers a better fit than any other tool.
What is Ruby on Rails?
Ruby on Rails is an open source server-side web application framework with an MIT license. While Ruby on Rails is written in Ruby, a dynamic, general-purpose programming language from Japan; RoR is in fact a framework not a language. Many entrepreneurs and non-developers often confuse the two, thinking Rails when hearing Ruby but rarely the other way around.
This may be brought on by the fact that the majority of Ruby developers use Ruby on Rails framework for development.
Ruby really only gained momentum as a programming language following the launch of Ruby on Rails.
Rails was created in 2004, following that Ruby won the “Programming Language of the Year” award from Tiobe in 2006; despite being written in 1995 (a great year for action movies—Goldeneye anyone?).
There are other frameworks based on Ruby, but their popularity with developers, and active contributors are low compared to Ruby on Rails. We’ll take a closer look at that later on in the article.
This isn’t to say that other Ruby frameworks are lower in quality than Rails. Quite the opposite, actually—they were built to respond to very specific use cases, and often outperform Rails in these instances.
Rails, however, will be a good fit for the majority of projects that call for using a Ruby framework.
Ruby on Rails Revolutionized the Web Developer World
When RoR entered the scene in 2005, it introduced a fresh approach to building Web applications.
One of the things Rails brought along was the convention-over-configuration software design paradigm that facilitates developer work on many levels—for example, by eliminating the need to write boilerplate code.
Together with Django, Python’s most popular Web framework released the same year, Rails propagated the use of the MVC pattern and good development practices, such as the DRY principle.
The Rails way of Web development unshackled devs from the tedious parts of coding, freeing them up to focus on the business features and logic of the app.
It also increased productivity and helped developers deliver MVPs and startup apps much faster.
Why Do So Many Think Ruby on Rails Is Dead or Dying?
Almost an urban legend by now, the myth of RoR’s demise is the product of many misconceptions that grew around the framework and the language it’s based on.
Time to dissect them, then.
#1. Slow Performance
While Rails has slower runtime speeds than, for example, Node.js or Golang, this only becomes noticeable with huge products with large-scale traffic.
And if this isn’t a huge app with a lot of users and requests, Rails isn’t necessarily the culprit behind the slow speeds—there’s also server architecture or databases to consider.
With a well-thought-out architecture and infrastructure (a necessity in all large-scale projects, regardless of the programming language), even huge apps, or their parts, written in Rails can be fast.
Examples of large-scale RoR apps include Basecamp, Airbnb, or GitHub.
So where does all that bad rep come from?
Because Rails does so much for the developer, inexperienced devs tend to make wrong decisions when writing the code. With bad code, the drop in performance is significant.
When it comes to Ruby and RoR’s inherent performance issues, they are actively being worked on.
Ruby 2.6.1, released in December 2018, included performance improvements and new features. Moreover, the developers behind Ruby 3 aim to speed up the language by three times compared to Ruby 2.
Also, Rails 6.0 is expected to come out in April 2019, packing solutions that simplify building Web apps even more. And since “Rails 6.0 will require Ruby 2.5+,” the framework will have all the perks of the new Ruby aboard.
#2. Scalability Issues
I’ll start by explaining that it’s wrong to blame only the framework for scalability issues and deficiencies in handling many user requests.
For the application to serve requests quickly, each element in the server system architecture, not only the Web app’s backend, should be configured correctly and be appropriately performant.
Ruby on Rails was accused of being difficult to scale when Twitter moved away from Rails to Scala. The transition was probably what first sparked the debate around RoR’s scalability issues.
Still, let’s keep in mind that we’re talking Twitter-size traffic here.
So, before condemning Rails, try to identify which element exactly is responsible for the slowdown.
Available scaling options with Rails:
- code optimization
- service-oriented architecture
- horizontal scalability
#3. It’s Mature, Hence Boring
Whenever a new framework emerges, especially one that brings something innovative to the table, it goes viral and suddenly hundreds of its users and contributors pop up all over the world.
Then a few years pass, the hype dies down, and what was once cutting-edge becomes much less exciting, intriguing, and challenging.
It’s maturing. But maturity does not necessarily have to be boring.
Maturity means stable, refined code; and maintainable Web applications, even if no longer written in a trendy framework.
Chasing technology trends isn’t always a good idea. Instead of improving business operations, a change to something more popular can actually yield adverse results and increase overhead.
Here’s an example of what can go wrong:
You have Ruby on backend, but Python is the top dog now, so it’s natural to feel like Python might benefit your business.
But is adding yet another language to your server-side stack necessary? Or maybe it would only make the codebase more confusing and difficult to maintain?
Unless your application is as big as Twitter, business benefits from adding Python won’t be big enough to compensate for the implementation costs.
A better approach is to use what’s available within your current setup and solve the problem with a minimum waste of resources.
When used by experienced developers who are well-versed in building apps in Rails, RoR’s maturity combined with excellent tooling, libraries, and community support makes addressing most of the pressing issues a rather straightforward affair.
Let’s look at the state of Ruby on Rails in 2020.
Ruby’s and Ruby on Rails’ Overall Popularity
Although way behind main contenders, such as PHP or Python, Ruby still makes the cut for the most popular programming languages list.
As for interest in RoR over time, Google Trends reveals a steady interest in this technology.
What is Ruby on Rails Used For
To dive into what Ruby can be used for, we have to remember that it is a dynamic, general programming language which is versatile and mature. The list of products you can build with Ruby is very long due to the vast (and still growing) number of gems and libraries, which serve as building blocks for different types of apps. Here are the most common types of apps built with Ruby. MVPs
Ruby is often chosen for cost-effective and fast development of MVPs. This language is also often used for prototyping, introducing updates and testing different versions of products before building fully functional apps. Social Networking Apps Because of Ruby’s ability to support traffic-heavy apps, it is perfect for social networking apps like Twitter. It’s also used for apartment sharing and booking apps – Airbnb and Couchsurfing because it swiftly manages a big amount of daily transactions and property bookings.
Ecommerce platforms Ruby is a programming language of choice for many ecommerce platforms like Spree or Shopify which gives a home to over 800k online stores. The reason why it is perfect for the job is the speed of development, flexibility and cost-effectiveness of Ruby, which allows for managing a lot of transactions at once. It also gives developers access to a wide ecosystem of gems – right now there’s over 150 thousands of them.
Platforms that support complex databases Some of the best examples of such platforms are GitHub – the biggest Git repository hosting platform for developers and Bloomberg – a multi-platform financial news and analytics hub.
Because of its speed, efficiency and flexibility, Ruby is also used for:
- automation, backup,
- DevOps tools,
- API Clients,
- report generators,
- servers,
- static website generators
- command-line media players.
While Rails’ popularity might have dropped off over the years, the framework is still used by almost a million websites globally, including by a number of major players, such as Dribbble and Hulu.
Community: Ruby vs. Python vs. PHP
Even though PHP and Python are used more widely than Ruby, two of their most popular frameworks, Laravel and Django, respectively, have significantly fewer contributors than Rails.
A higher number of contributors means gems (libraries) are of very good quality, and as the saying goes, there’s a gem for everything in Rails. Rails is often praised for the effort of its community to create reusable libraries that encapsulate solutions to standard problems.
GitHub contributors to Ruby frameworks:
- Rails: 4260
- Padrino: 228
- Hanami: 146
- Sinatra: 387
GitHub contributors to Django (Python) and Laravel (PHP):
- Django: 2,007
- Laravel: 740
Ruby on Rails Job Demand
If Rails were dead, hiring managers wouldn’t be looking for Rails developers.
Here are worldwide job ads from LinkedIn for Rails, Laravel, and Django along with the languages they’re written in:
- Ruby on Rails developer: 1,692
- Laravel developer: 563
- Django developer: 485
- Ruby developer: 738
- PHP developer: 16,778
- Python developer: 5,653
Results from Indeed:
- Ruby on Rails developer: 1,276
- Laravel developer: 412
- Django developer: 632
- Ruby developer: 3,885
- PHP developer: 5,895
- Python developer: 20,298
Because the world of Rails is somewhat specific, with many people referring to Rails when meaning Ruby, the analysis above might be slightly inaccurate.
Conversely, many hiring managers mean Django when recruiting Python devs, and Laravel when looking for PHP developers.
Why You Should Pick Ruby on Rails
With coding by convention, building applications in RoR is fast and easy—an excellent choice if you’re on a tight budget and under tight deadlines.
Thanks to the sizeable talent pool, finding experienced RoR developers shouldn’t take long.
Ruby on Rails is mature and offers stability that directly translates into successful, hassle-free maintenance for years. Good developers will know how to tap the magic of Rails and use the saved time to focus on business features and application logic.
In the hands of inexperienced developers, Rails will never be a good choice for advanced, complex applications.
It can actually be a source of many headaches and future issues with maintenance, performance, security, and stability—all of which incur significant costs that could otherwise be avoided.
For simple APIs or blogs, Rails is an excellent pick, even for beginner devs.
Why You Should Pick Ruby on Rails in 2020 [UPDATED 21.02.2020]
While Ruby’s scalability may be the subject of some controversy, there’s no denying that the language is still alive and kicking in 2020.
Below, you’ll find Wojciech Maciejak, our senior Ruby and JavaScript developer, briefly reviewing recent, major changes in the world of Ruby on Rails.
Sorbet type checking = less bugs
Sorbet is a type checker for Ruby, built by the Stripe dev team.
Ever since I started working with Java, I have been genuinely missing Ruby’s static typing. While most devs don’t actually have strong opinions on type checking, the lack of it was particularly bothersome to me when it came to large projects.
Fortunately, someone finally decided to do something about that and now we have a solution.
Why is this important news?
Well, a type checker may be of huge help in spotting simple (and complex) bugs well before pushing an application to testing.
It’s a gamechanger, not only from a development, but also from a business perspective. After all, fewer bugs mean more time for developing features and improving user experience!
Sorbet is currently in version 0.5 and we’re still waiting for more features that will improve it even further, but now is really a good moment to check it out!
Ruby 2.7
With the latest release, Ruby itself gained a couple of really nice upgrades in the ease of use department:
- Improved IRB—it now supports inline method editing, auto completions, and syntax highlighting! Quite nice if you ask me!
- Numbered parameters—you can now access the parameters passed to a block by using numbers, eg. _1, _2, etc. It’s a really useful feature, especially when you’re pushing a single argument to a block—no need to declare it anymore, you can just use `_1`!
- Pattern matching—it’s still an experimental feature, but writing cleaner code is something every Ruby developer will be really interested in! Although it’s a bit slow at this point, we believe that Matz and the team will soon optimize it to be a much smoother experience.
While most of these upgrades will appeal primarily to developers, the improvements in the latest release of Rails will definitely speak to people handling the business side of things.
Rails 6
So what changed in the sixth version of Rails? Well, there are five specific improvements that I think warrant your attention. What are they?
Let’s start with Action Mailbox.
It’s an awesome new framework that routes incoming emails to controller-like mailboxes in Ruby on Rails. It allows Rails applications to better integrate with inbound emails.
Older Rails versions had Action Mailer, but this brand new implementation looks a lot better. Additionally, it offers integrations with awesome services like AWS SES, Mandrill, Mailgun, and more. It’s also designed to be as easy to use as possible.
How does that translate to improving your business, you ask?
Let’s say you’re running a platform for selling items in bulk. This usually means a daily flood of incoming emails about items currently available in stock.
To respond, you first need to check with the wholesale platform and then draft a reply. A lot of repetitive work, and the effort does not scale at all.
With Action Mailbox, however, you can create an internal mailbox with additional logic that automatically checks the availability of items and then automatically responds to queries.
Sounds awesome? That’s because it is!
Next up, the Action Text.
In the words of RoR creators, “Action Text brings rich text content and editing to Rails.” It’s a really complex solution that brings text manipulation in Rails to the next level.
In an equally awesome development, embedded contents are now automatically stored in connected services defined in ActiveStorage. It’s a powerful and super easy-to-use solution.
With these changes, we will be able to implement better text-editing solutions in our application in much less time and have them offer a much better user experience!
The creators also added a feature that I have been missing ever since creating my first big application in RoR.
If only I could have used multiple databases, the app would have had much better infrastructure and reliability. Now I can!
In my opinion, it’s a game changer—not only does it open up new avenues for development, it also makes our apps more secure and reliable.
The changes in Rails 6 also testify to the attention that its creators have given to the question of testing.
Nowadays, automatic tests tend to take ever greater amounts of time. Even if we try our best to reduce the test load, the reality is that as the app grows, the time we have to invest in testing will grow as well.
Unfortunately, more time for tests means less time for development and more money to pay for Continuous Integration tools.
Rails 6 introduces parallel testing, which fixes this problem and adds a whole bunch of additional benefits.
And last but not least—webpack as default bundler.
Integrating webpack with Rails-based applications has become much easier ever since Rails 5.1 came out, but it still was not the default configuration for new apps.
This changed with the release of Rails 6, and the shift brings Rails closer to current standards and trends.
As always, less configuration means more time for development and more time for improving our product!