Why Is Ruby on Rails So Popular?

Hi! I have been using Ruby on Rails for a significant amount of time - 5 years (as for me it’s quite long period). In this article I will try to sum up my experience and answer a question: why I’m still using Rails and why you should (or shouldn't) use it.

At first, I'd like to answer the question from the title of this post. Is RoR really popular now, in the middle of 2015 year?

The following comparison table, based on popularity of repository on GitHub and quantity of questions on StackOverflow, shows that Rails is still one of the top leaders (source HotFrameworks):

Frameworks comparison table

According to Google Trends, Rails and the alternative frameworks are almost equally popular in search requests.

Google Trends - Web Search interest - RoR, Django, Node.js, Spring

I think, we can say with confidence that yes, Rails is a popular tool.

Some history

The first release of Rails was in 2004 and it became a very hot topic by 2006. It was considered a silver bullet, magic ingredient of a successful project. As time passed, the fashion changed, Node.js, Angular.js and other new trendy things appeared on the horizon. Beliefs about Rails came down to the earth. It turned from the silver bullet to just a good tool.

The following graph shows Google Trends in search queries for Rails from 2004 to 2015.

Rails trends since 2004

Why you should choose Ruby on Rails if you are a business owner

There are many well-known brands which created their websites on Ruby on Rails. Airbnb, Groupon and Shopify - these are some example sites built with Ruby on Rails that come to mind first. Lots of startups take these companies as a reference and dream to repeat their commercial success. Sure enough, choosing the same technology platform may be a good idea.

Ruby on Rails development is good not only for e-commerce marketplaces and site-building platforms. GitHub (hosting and collaboration platform), Heroku (cloud PaaS), CrunchBase (database of technology companies), SoundCloud (audio distribution platform), Hulu (streaming video service), Dribbble (social media network for designers), Diaspora (distributed social network) and lots of other websites are based on the Ruby on Rails technology stack. So, it's truly a universal platform.

Our team have been working with RoR since the time when it was launched. From our own experience we know, that due to its flexible and innovative nature, this framework can be used for creating websites for all industries, e.g. HR management (Turbine), travel (eBookingServices), project management (Tracker), daily deal site building (Getsocio) and many more.

To cut it short, the key reasons why startups choose Ruby on Rails:

  • it allows to actualize ideas and add functionality quickly,
  • it is cost-effective and works well for fast prototyping.

Why to use Ruby on Rails if you are a project manager

Rails is an excellent choice for a fast project launch, thanks to its impressive development speed and the reduction in required code. The vast array of open source libraries, tools, cloud platforms, and PaaS, coupled with accessible extensive documentation and educational resources, make it easy to get started. With a large and helpful community, any problem can be addressed with ease. The ecosystem is stable and mature, and standard tasks already have solutions available.

Moreover, many ideas, conclusions, and approaches that originated in the union of Rails and Ruby have been adopted in other frameworks, further proving the significant influence of Rails on web development. Just type in Google "rails like + language". Rails-like frameworks sprang up rapidly for many popular platforms - Java, Scala, NodeJs, PHP and even Erlang. The entire Ruby/Rails ecosystem had an effect on the development tools of other platforms. Tools for application deploying, package managers, dependency management systems, template engines and preprocessors. If you want to be on the leading edge of web-technologies and don't want to wait till it is ported to your platform, then Rails is your choice! The continuous development, functionality and help of the community make Rails a credible and effective tool.

Ruby on Rails advantages, such as predictability, stability and reliability, define it as a perfect choice for long-term projects. Rails will not die if the "main maintainer" gets bored and leaves to do other things. If a member quits the team there won't be a problem to replace him. Rails has become an elaborate and stable tool a long time ago that’s why it continues to be popular. When you are selecting a platform and technology stack at a project start, take a closer look at Rails - it may become the key decision for your project success.

What can you do with Ruby on Rails as a developer

One of the peculiarities of Rails is Convention over Configuration approach. In practice, it means that when you follow the conventions, you don’t have to be concerned about configuration and settings for all components and layers of abstraction. If a convention doesn't suit you, that's OK, you always can set up everything as you want. The framework hides the complexity of problems and, as long as you are following the conventions, everything works like magic. Problems appear when the convention doesn’t suit your needs.

Rails is an amazingly modular and customizable tool. You have a standard (provided by developers) way to expand and override the behavior of any component. You can embed in the process of sending emails and modify the email. For instance, you can change the subject of email, so that on the test server all emails should come with the postfix “[Staging]”. Do you need to support the visual themes for web-pages and dynamically determine the path to where the html templates will be taken from? It’s easy, all you need to do is to override the corresponding component (path resolver). Do you need to execute some service code before starting processing the request by your code? Simply embed your middleware in the queue of standards.

Everyone who faces the need to choose framework or technology stack finally comes up to some checklist of features and the choice is made based on whether a particular framework supports some specific features or not. Let’s take a look at what you get when you select Rails.

You get ORM - ActiveRecord. As you can guess, the pattern of the same name is used for accessing data in a database. The accepted conventions make your life much easier. You don't have to configure anything. If you follow the standard conventions, you don't write even a single line of configuration (of course, it's not really true, in any case you have to configure access to database, provide username, password, etc.). Here is an example of classes-models, they represent specific tables of database from documantation:

class Customer < ActiveRecord::Base
  has_many :orders
end

class Order < ActiveRecord::Base
  belongs_to :customer
end

And that’s all. It works without a single line of configuration. By default, it’s assumed that your database contains tables orders and customers. There is a foreign key with name customer_id in table orders. Primary keys have name id. That's it. You follow the naming convention and everything works by itself. Now you can build and execute SQL queries in the most evident and native way:

customer.orders
#=> [order1, order2,...]
order.customer
#=> customer

Well, let's go further. Routers. It’s incredible. You can do everything and most of this "everything" is free. But this is only if you follow the conventions. An example of route from documantation:

resources :books

Thanks to the magic of Rails, this short line is able to create a bunch of routes for CRUD:

$ bundle exec rake routes | grep book
         books GET      /books(.:format)                 books#index
              POST      /books(.:format)                 books#create
      new_book GET      /books/new(.:format)             books#new
     edit_book GET      /books/:id/edit(.:format)        books#edit
          book GET      /books/:id(.:format)             books#show
             PATCH      /books/:id(.:format)             books#update
               PUT      /books/:id(.:format)             books#update
            DELETE 	    /books/:id(.:format)             books#destroy

Once again, according to the naming convention you must have class BooksController and analogous methods index/create in it, i.e. books#index corresponds to BooksController#index. In addition, you should also consider constraints, namespaces and modules.

HTML forms. What can be improved here? Html is html and there is no way to escape this. But you can try to ease the pain. Example of creating a form from documantation:

<%= form_for @article, url: {action: "create"}, html: {class: "nifty_form"} do |f| %>
  <%= f.text_field :title %>
  <%= f.text_area :body, size: "60x12" %>
  <%= f.submit "Create" %>
<% end %>

It’s supposed that @article is ActiveRecord model but in fact there can be any object. Furthermore, if you use FormObject pattern there may be an object which is completely detached from the ORM layer.

Database migrations. Everything is standard here. Easy and quickly.

Authentication of users and supporting functions like sign up, sign in, sign out and password resetting. To make it work you have to use one of the available libraries: Devise, Authlogic, etc. You just need to add a few standard lines for using them.

Deploying applications to server. There is a solution - Capistrano. Here is an example of standard script with comments.

# config/deploy.rb

# config valid only for current version of Capistrano
lock '3.4.0'

set :application, 'aircat'
set :repo_url, 'git@bitbucket.org:applabsservice/aircat.git'

set :deploy_to, "/var/www/apps/aircat"
set :git_shallow_clone, 1
set :deploy_via, :copy
set :branch, 'master'

set :host,   '127.0.0.1'
set :user,   'deploy'

role :app, %w{deploy@127.0.0.1}
role :web, %w{deploy@127.0.0.1}
role :db,  %w{deploy@127.0.0.1}

namespace :db do
  desc 'Make symlinks'
  task :symlink do
    on roles(:app) do
      execute "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
    end
  end
end

after 'deploy:updating', 'db:symlink'

# then other callbacks go for web server restart

What does it give us? For every deployment, a new version of app is copied to a separate release directory, located next to previous one. Migrations run, compilation/bonding/minification of static css/js files is being done and when everything is ready Web server switches to the directory with the new release. In case of an error at any step you can simply roll back to the previous release. New code is run on updated database. There is a point, that during migrations the old code is operating on the new database for some time. But this can be addressed.

Uploading images or video? Take any of alternatives - CarrierWave, Paperclip, etc. Example of using PaperClip:

class Post < ActiveRecord::Base
 
  has_attached_file :image, styles: { standard: "1280x1280>" },
    default_url: "/images/:style/missing.png"
  validates_attachment_content_type :image, content_type: /\Aimage\/.*\Z/

  has_attached_file :video
end

And that’s all. Migration can be automatically generated for saving metadata of file in database and it is already running:

post.image = File.read("test.jpeg")
post.save

Well, file is already in the right directory in the hard drive. If it’s an image you can cut, convert and compress it. You can also create several variants of image resolutions with a couple of magic lines.

Localisation. Of course, here it is, everything is easy and implemented in a standard way.

Testing. There is a framework for unit-testing in the standard Ruby library. Out of the box, Rails supports functional and integration tests. But it is much cooler to use a bunch of RSpec for unit tests and Capybara + webdriver for integration tests. Imagine, in integration tests you can run a real browser installed in the system (for example, through Selenium Webdriver), or a headless browser based on WebKit. The second option is more reliable, stable and quick for now.

As for disadvantages for the development, the are the following:

  • Rails gives you the conventions. You follow them. Your code is short, nice and covered with tests, everything is done in Rails-way. But there is a back side. You get a tight coupling of components, fat controllers and models. Rails suggests a MVC pattern and nothing more. No standard abstraction layer, this solution falls on your shoulders. If you have noticed that standard components (views, models or controllers) are overloaded with logic, which is not appropriate for them, you have to do something. What options do you have? You can refactor, move the logic to separate layers - so much is already written about it. You can use Form-objects, extract complex SQL queries to independent objects and detach business logic from ORM/controllers.
  • The documentation for Rails and popular libraries is excellent but it doesn't release you from learning their source code in order to sort out things missing in the documentation. Sometimes code can say even more.
  • The speed of tools’ and libraries’ development has an obvious tricky side - from time to time you have to do updates to get the latest versions installed. This concerns both Rails versions and libraries. Migration to another major library version for testing can take more than a couple of days. It also happens, that a successful analogue of the library used in your project appears. Your library is no longer supported and suddenly you find out that it doesn't work in the new version of Rails and you have to switch to analogues. Nothing from that is specific for Rails only but in case of long-term project there is a big chance to face such problems.

When you don’t need Rails:

  • You clearly understand all your project requirements. You don't expect fast changes in functionality. For instance, you have a prototype or you have already done something very similar and so you can start making a solid architecture at once.
  • You are looking for something which you will never find in a dynamic programming language e.g. a high performance and a low consuming of the server’s resources.
  • You already have team of professionals who prefer to use another framework.

When you need Rails:

  • You develop a trivial web application. You expect that it’s a long-lasting project. You need your tool to be evolving and live, you want to have community support and the possibility to hire a professional. In this case Rails is an excellent choice. There is a wide range of alternatives, you have what to choose from. But anyway you will pick up Rails because it’s still trendy.
  • You are planning constant changes of requirements, functionality and direction of the project development. You don’t have a strong product concept, it’s changeable and depends on the users` feedback. In this situation Rails is a great solution.
  • You need a quick prototype. Rails is still good enough for it. There is no doubt that alternatives exist but Rails is a perfect candidate.

Hopefully, the question "Why Ruby on Rails is so popular?" is now answered. To summarize, I’d like to add that it’s a great pleasure for me to use Rails and Ruby. These are very convenient, soft and flexible tools. Skilled hands can do magic things with the help of Ruby and Rails.