Why Use Ruby on Rails? My Take After Two Decades of Programming

Sometimes I hear people complaining about their clients, saying that they insist on using Rails, that they’ve had too much Kool Aid. If they’re recruiters, they almost feel sick in the stomach about having to find yet another Ruby on Rails ‘primadona’ developer. Then they pull out something similar to this amazingly ignorant comparison between Git and PHP to prove their point. “They don’t even know what they’re asking for,” they say.

For us as programmers, sometimes it does indeed seem like our clients don’t have a clue. We love to exaggerate cases like this. When you think a bit about it, it does not seem right to think that a person that is giving me money to build things is somehow limited and ‘just doesn’t get it’. In fact, I believe that most clients know their options just fine and yet they still decide to go with Rails.

Why Ruby on Rails? I’ll try to explain what, in my opinion, makes Rails beneficial enough to be seriously considered for a plethora of projects and needs.

When to Use Ruby on Rails

It’s possible that nobody would even know about the benefits of Ruby if it weren’t for Rails itself. Some people like to belittle Ruby by saying that it’s “so easy for Ruby” with its “knight in shining armour called Rails” and that without Rails, “Ruby would be irrelevant”. I can’t say for sure whether or not that’s true, but I do know that it would be a huge shame if the world missed out on such a superb language. The fact is: the author of Rails picked Ruby deliberately, and his ‘wild’ bet paid off with huge interest. What he saw back then, many others can see today. Ruby somehow enables programmers in a special kind of way that is so hard to explain to the ‘unwashed masses’. So, why use the Ruby on Rails framework? Ruby makes programmers happy, as advertised.

While most developers agree that Ruby is handy, some see it as too much so. They worry about what might happen with all the freedoms that Ruby allows, all the potential for misuse. Let me illustrate with some monkey patching:

"1".to_i 
#=> 1

class String
  def to_i
    raise 'foobar'
  end
end

"1".to_i 
#=> RuntimeError: foobar

It’s that easy: with just five lines of code, we’ve taken an existing class and overridden its behavior. Nohting is sacred–not even a String. This particular error would be easy to spot, but things can get much more sinister:

class String
  def to_i
    self.to_f - 1.13
  end
end

"2".to_i 
#=> 0.8700000000000001

Just like that, we’ve introduced an error into the String class that could be wrapped into and obscured by layer upon layer of complexity.

So, you might be thinking: Can everybody and their mother mess up my precious application? While this behavior indeed looks scary–it’s really not. In five years of using Ruby, I’ve had exactly zero problems with this behavior. It may seem counterintuitive, but then again, so is driving cars at 60 MPH in opposite directions separated only by a thin white line in the middle of the road. In practice, both work remarkably well.

Another benefit is that Ruby is a versatile tool. As such, it has sharp, knife-like edges. I like to think that grown-ups can handle knives just fine–child-proofing is for, well, children (Tweet). And being treated like a child in IT leaves you a victim of Paul Graham’s Blub paradox: you think you are better off without certain features that you don’t understand or that someone told you are too dangerous. Of course, today we are asking “why use Ruby on Rails”; thus, this is a debate for another time. Admittedly, Ruby misses out on some features that other languages have (Lisp hmm, hmm). All-in-all, Ruby is close to the top of the ‘language power continuum’.

My first few years with Ruby were humbling. I learned so much just from reading through others’ code. Sometimes, I was amazed; sometimes, I was mad; but eventually, this knowledge enabled me to communicate with my computer much more effectively than before. I almost feel sorry for some other ‘red tape’ languages that make you jump through hoops just for the sake of jumping through them, all while telling you “I am just doing what’s best for you, it’s for your own good!”

Pragmatism

There is a deep respect for pragmatism knitted into Rails’s DNA at the lowest possible level. In combination with the benefits of Ruby, this pragmatism produces elegant solutions and encourages/inspires the Ruby on Rails development community to do the same. Pragmatism is often advertised as a tenet of Rails software, so this claim isn’t new, but I was reminded of it’s truthfulness quite recently as a friend of mine tried to show me just how “cool” Hibernate really is. He was struggling. I could feel his pain as he was unable to set a myriad of options and configuration parameters that should have been framework defaults in the first place.

With age, my standards for artificial complexity have grown higher and higher. Considering that I started writing production code back in 1989 at age 11 (beginning with a project for my next door neighbor in Clipper Summer ‘87), I have close to zero tolerance for unnecessary complications. And Rails scores really high in that department. It’s more than just ‘convention over configuration’; I am talking about the whole pragmatic mindset that is highly valued within and permeates through the Rails community.

Expressiveness

Rails is as close to English as it gets (unless you are using COBOL). It uses what’s known as an internal DSL, extending Ruby with its own semantics. Constructing a DSL is always dangerous as you are effectively developing a new language. Because it is internal, you don’t need to use an external parser, but in a sense it feels like a new language. The Rails team struck a good balance with its DSL, using it where it makes sense and only seldom overdoing it, demonstrating excellent self-control. I think that any programmer, regardless of Rails experience, (and even some non-programmers) could understand this:

class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable

  validates_numericality_of :years_of_experience, 
                            :allow_blank => true

  acts_as_taggable
  acts_as_taggable_on :certificates, :expertise_kinds

  validates_presence_of :first_name, :last_name, :email

  has_many :translations

  has_attached_file :avatar, :styles => {:small => "240x240>"}
  has_attached_file :cv
...

In fact, if you’re not familiar with Ruby, this might look odd–it’s almost as if it’s not a programming language. Once you realize that it’s just method calls without parentheses, you are good to go. Still, the Rails DSL feels like it is this special language for describing requirements when in fact it is just smart naming and inherent usage of Ruby’s excellent syntax.

Community

Rails has an army of committers that make sure it stays in tip-top condition. Many projects simmer down with age, yet with Rails, sparks still fly when decisions need to be made. It feels like the maintainers (still) truly care and want people to use Ruby on Rails and understand its benefits.

Underneath Rails itself, as a cherry on top, stands Ruby with its formidable package manager, RubyGems, comparable to CPAN in terms of number of packages–and considering CPAN’s age, that claim is (to put it mildly) very impressive. Rails had a brief derail when it tried to make its own “Rails plugins”. Fortunately, this did not stick, so RubyGems remains the unified, superb source for code programmed by very bright individuals.

The synergy between a cool language, pragmatic web framework, and superb community gives Rails a result much better than the sum of its parts.

Maturity

Rails has been around the block. In a hipster kind of way, it’s not even that cool anymore. This is good thing when it comes to choosing a technology stack: you want something proven. And Rails is just that. We recently wrote a piece talking about the wide variety of Ruby interpreters and runtimes that are now available.

Marketing

I know, I know. As an IT professional, I should really value ‘serious’ things and ignore the ‘glitter’. It may seem shallow, but lets face it:

1. Compared to the competition, the Rails site looks good.
2. Rails’s first screen cast, back in the day, was simply breath taking. It might not look that impressive today, but remember that the only reason we all know about Java is that everybody was so fired up about possibility of running a Java Applet in the browser. This turned out not to be that important after all, but still, this put Java on the radar. Similarly, this 15-minute blog engine screencast was a huge hit that excited a lot of people.

This isn’t even about vanity; it’s about engaging as many smart people as you can to put water into the mill. When frameworks are considered, the best place to be is in the crowd. Choosing a framework that these smart people are focusing on simply means that a lot more ground is already covered for you. And this brings me to my next point.

(Not) Reinventing the Wheel

I have a soft spot for tiny frameworks. I like when I can understand what a particular framework is doing and why. In this sense, Rails is somewhat bloated, and even overwhelming at times.

The dilemma here: how many times do you want to write the same stuff over and over again? Some of it can be rewritten better I am sure, but it takes time–a lot of time. The more you allow Rails to do for you, the less you have to worry about re-writing or re-implementing your functionality.

Rails is (as they say) ‘batteries included’. This is not a good thing if you are keen on sparsity or if you feel the need to have extensive knowledge of how everything works. In practice, if you let go of your fears, it does seem to work. Rails has reasonable defaults for almost everything you need and is modular enough to avoid cornering you into a tight spot.

Conclusion

Ask yourself again, why use Ruby on Rails? Rails is suitable for both state-of-the-art public websites that compete with Single Page JavaScript applications, and complex enterprise core system applications that usually look a bit ‘uglier’ (with a more generic, lower fidelity UI), but compensate this blemish with a ton of complicated business rules and logic. Aside from these Ruby on Rails use cases, its benefit is that it is versatile and able to compete with both the sleek and the powerful.

For most of common problems, Rails has a component at your disposal almost right out-of-the-box with documentation that is consistently above average (somehow, the Rails core team persuaded contributors that writing documentation is cool (even though we all know it’s not), leading to well written, concise and time-saving docs).

When you put aside unicorns and Friday hugs, you end up with a mighty framework that you can be used both for your future game changer and your next middle-of-the-road business site. And with your pool of top-of-the-line gems, you have at your finger tips an arsenal that implements some of the brightest ideas in computer programming. With no fuss.