Why we use Ruby on Rails

March 30th, 2016

I was recently browsing Reddit when I came across a thread asking “How bad is Ruby on Rails performance, really?”, and while I wrote a response there, I wanted to expand on it a bit, in the context of the projects we work on at 3e8.

Ruby on Rails isn’t anything new—it’s over 10 years old, and even in the beginning, there were people claiming it was “too slow”. Now, with new frameworks like Node.js and new paradigms like single page applications popping every day, Rails is often perceived as old and out of touch. It’s easy to get caught up in the newest trend, and there are lots of great technologies being developed, but at the end of the day, just because something’s new and shiny doesn’t mean it will move the needle for your business.

We work on backend infrastructure at 3e8, and it’s all built in Rails. While I’ve played around with a lot of new tech, I keep going back to what I know. Why? When it comes down to it, I’m most productive when I’m writing Rails code. Sure, I could build out my next project in Node.js, or Go, or whatever else is out there, but I’m going to be able to crank out the best, most productive code in Rails. I know it best. I’ve been working with it for almost as long as it’s been out, so I know all of its ins and outs.

But really, if you’re spending a lot of time trying to figure out what backend technology will power your app, you’re probably asking the wrong questions. In reality, your biggest cost is people, whether it’s an employee, a freelance developer, or a consulting agency, so in most cases, it’s better to optimize for development time rather than performance. Spinning up a couple of extra servers to deal with traffic is way cheaper than paying a developer to fight with some brand new technology that she doesn’t know very well, rather than letting her use what she knows best.

That being said, at some point, you do have to actually pick your technology stack. Here are the questions you should be asking:

  • Is the framework actively maintained?
  • Will it continue to be maintained?
  • Is it secure?
  • Can a new developer easily pick up where others left off?
  • Is it widely supported?

Whatever framework you or your developer chooses, you need to be able to answer “yes” to all of these questions. Sure, if it’s something brand new, there might be a lot of initial activity, but what happens when the framework developer gets bored and stops working on it? All of a sudden, this awesome new framework is your responsibility to maintain. A mature framework, while it may not be as exciting, has had thousands (maybe tens of thousands) of hours of developer time spent getting it to where it is, which generally results in a more stable and secure platform.

For us, Rails checks all of the boxes above, and it’s where we’re most comfortable. It’s not necessarily right for everyone, but it’s right for us, and for all of the projects we work on.

And really, while you might be concerned about performance, pretty much any modern framework will perform just fine for most apps. Rather than spending your time wrestling with the newest, trendy platform, you use your focus where it most matters: on your business. Your app will be just fine.

Interested in working together?
Make Contact