Why Ruby on Rails?

October 17, 2012,   |   Business
Agile League

As a follow up to John’s post, I’d like to discuss why we use Ruby and Rails. John covered why the web is still a great platform for application development, and now I’ll explain why Ruby and Rails are the right tools.

Speed of Development

By far, our favorite Rails feature is the speed at which we can make progress and deliver value to clients. All of us at The Agile League have written code in a multitude of languages, and we can move much faster in Rails than anything else.

This speed benefits our clients in many ways. Obviously, getting things done faster and cheaper is nice in and of itself, but this speed has a lot of side benefits as well. For example, since we can deliver new functionality very quickly, our clients can experiment with new business models and features without investing a lot of resources. In short, our speed allows our clients to innovate faster and react quicker to their customers.

Open Source Community

A large contributor to the speed of development is the incredibly huge amount of open source software available for Ruby and Rails projects. Neatly packaged as Ruby gems, these discrete pieces of functionality allow us to tap into the incredibly talented Ruby community as a whole and bring the expertise of thousands of developers to our clients.

A common problem in software development is having to re-invent the wheel over and over. Thanks to the open source community, developing a Rails application is like living inside a wheel shop where a simple Google search finds you the perfect wheel you need, and all you have to do is attach it to the vehicle you’re building.

Continuity and Convention

A popular motto in the rails community is Convention over Configuration. In other words, instead of everyone doing things slightly different, why don’t we all just agree on a single way to organize our files, name our classes and methods, arrange our database tables, and so forth? It seems like a small thing, but the true payoff occurs when a project handoff occurs.

Much of our client work involves projects that were started by other Rails developers. If the original developers followed all the basic conventions that Rails lays out, we can just in and get to work immediately. To think of it another way, it’s like driving one car for a while, then climbing in another. Steering wheel, gas pedal, brake pedal, and so forth are all in the same place. If every car maker decided to put their own spin on things, driving a new car would require completely re-learning how to drive in the first place. Likewise with Rails, when we take over a project, we can jump into the driver’s seat and hit the gas without having to read the owners manual and figure it all out.

What about Node? Meteor? Sinatra? or some other platform-du-jour?

I could go on at length about why we like Rails, but I want to take a little time to address all the up-and-comers in the arena. Every few days you’ll read another post about some new technology that has or will “kill” Rails. These days, node.js is the most popular murderer, but Sinatra paired with a snazzy front-end library like Backbone or Ember is also a popular suspect.

We at The Agile League think these new platforms are awesome new tools for the toolbox, but just like a screwdriver doesn’t kill the other screwdrivers, nor do these new technologies represent a threat to Rails. Node is great for certain event-driven areas like proxies, but suffers from a lack of support and maturity. Likewise, Sinatra can be quick to get started with, but once your project grows to a certain size, you begin to miss all the bells and whistles that Rails provides. In both cases, you will find yourself rewriting large portions of what comes out of the box with Rails.

In any case, the point is not to sit in an armchair and pontificate about which framework is best, but instead to understand which framework is best for a given specific context. Just like choosing the correct screwdriver requires knowing which screws will be turned and where, choosing the best web framework requires knowing the application space and how it will be used. We have found Rails to be a good general purpose fit for most web applications, but we would not hesitate to pull a different tool out of the toolbox if circumstances called for it.

Rails: Still Alive and Kicking

Ruby on Rails is a mature, robust, and dare I say, awesome web development framework. We use it every day to make spectacular websites for our clients, and we have no plans to abandon it any time soon. There are a dizzying array of choices now when it comes to building a feature-rich web application, and choosing the right tool for the job can be confusing. That’s where the expertise of The Agile League comes in. If you’re unsure of what framework to use for your project, reach out and let us help. We’ll help you see the pros and cons of all the various technologies, and you’ll have a much better understanding of why our eventual answer is, “Go with Rails. Definitely.” 😉