Why I Love Rails

DHH is taking quite a bit of heat lately with is strong opinions regarding TDD.1 So far I've mostly seen quips that DHH doesn't know how to program, or people discounting his ideas because he always has strong opinions. Many fail to reproduce what he was trying to say (he is not saying do not test, for example.) I expect if we were at the receiving end of almost 44000 commits, we too might have strong opinions about bad code, test driven or not.

I am, frankly, very thankful for Rails. There were many things that Rails gave us a taste for.

It is easy to find opinions that Rails has outlived its usefulness. I do not think so. It is still a very valid solution for a large range of problems. I am, frankly, very thankful for Rails. There were many things that Rails gave us a taste for. Here are the things that now I would not live without, regardless of the framework:

  1. Opinionated software: Does anyone remember how much code was needed to get an MVC app going in Tomcat? You had to specify everything. It was an enormous amount of work, and it had to be done every time. Rails was a breath of fresh air. Convention over configuration meant it was so easy to work with, and you could override as needed. Many frameworks since reproduce this feature (I'm thinking of Ember at the moment.)
    This particular feature would not have come if we didn't have a strongly opinionated author, like DHH. In other languages, options were not being limited; instead, they were growing at a staggering pace. It was only getting harder to start a new project.

  2. Generators: The flexibility and ease of using generators was amazing. Create models, controllers, migrations, scaffolding, all with a single command. Many have moved on from scaffolding, but I still find it useful, though I seldom keep the results for long.

  3. MVC: We had MVC before Rails, but never had it been so easy to implement. Rails raised the bar, and for me made MVC fun to write.

  4. Standard MVC file structure: The convention for organizing files made sense. There were no questions as to where a file should go. When a new page was created, it could be placed where it was needed.

  5. REST and API: Rails steeped me in REST terminology. I know it is foundational to the web protocol, but my real experience of it began with Rails.

  6. Database migrations: The ease of creating migrations and recreating them in other places was staggering to me. I had done something like it, but Rails made it very easy to move forward and backward.

  7. Environments: I had created my own half baked environment distinctions with Java. With Rails they were complete. I did not have to think of or configure each environment.

  8. Testing: Rails was the environment in which I discovered TDD. It certainly existed before, but with Rails testing came right out of the box. Ruby made it simple to write.

  9. Object Relational Mapping: Rails was my first experience with ORM. ActiveRecord made database access a breeze. No more specifying every column (which made db changes a chore.) It simply worked. And the easy use of validations and filters let me do things I'd never thought of. It changed the way I think of database access.
    Yes I still write SQL, but even now I seldom parse results. There was little else you could do back then.

  10. Plugins or Engines: It is definitely taken for granted how easy it is to grab a gem and insert it into your app. I had no such experience before Rails. Now, working with node and npm, or grunt, or yeoman, or lineman, it is expected that a repository of modules is readily available.

  11. Deployment: Capistrano wasn't easy to set up at first, but it sure made deployment a breeze. Now there are wonderful deployment tools of all kinds, but capistrano raised my expectations.

  12. Console: The console was love at first sight. Why hadn't I thought of this before? It made it easy to view your app from the inside. Debugging tools have come a long way since, but I still return to the console.

  13. Asset Pipeline: Now, whether I am creating a static web page, or a Rails app, I expect there to be some sort of processing pipelin via grunt, or CodeKit, or Rails. I learned this expectation from Rails.

  14. Sandard Web App: With Backbone, Angular, and Ember, or with the mobile web, it is hard to get excited about normal stateless web pages. They certainly have their limitations, but they are not wrong. It is important to remember that plain linked pages are a very acceptable solution if it meets the requirements. Given the right framework, they are very easy to implement and maintain. Rails does them very well, and with caching and turbolinks they perform very well (e.g. Basecamp does very well.)

These are a few of the reasons I am grateful for Rails. I'm sure eventually I will think of more.

As should happen, all of these concepts have matured. Many people have moved on from Rails, either using Rails as a backend for their Javascript apps, or dropping it altogether. This is quite appropriate. We should always use the appropriate solution for the task at hand.

For the reasons above, Rails will always be a strong contender to play some role when I begin new projects. If I use another framework, it will certainly contain at least some of these benefits.

1. View the keynote that started it all, and follow the friendly TDD debate between DHH, Martin Fowler, and Kent Beck.

comments powered by Disqus