Introduction
I've been using Rails for a number of years now. In a world of isomorphic JavaScript, single-page apps, and microservices, I still reach for Rails when writing most web applications. After reading the Rails Doctrine, I was inspired to write about why I make this choice.
Decision Fatigue
Mark Zuckerberg famously wears the same T-shirt every day. President Obama has spoken about only wearing gray or blue suits. The reason for this is decision fatigue. Our decision-making ability deteriorates as the number of decisions we have to make increases. It is important to save our good decisions for things that matter. (This idea has been generating some controversy lately. Seems like a good topic for a future post…)
Rails gets criticized for its convention-over-configuration and omakase approaches. But to me, these are actually strengths. Decision fatigue is reduced. I am free to focus on the important decisions, like how to model the domain or the user experience. Now this is not to say that I blindly accept these decisions without thought, but I have come to understand which ones work for me.
Gems
Ruby has a rich and vibrant ecosystem of gems. If you find yourself in a position needing some additional functionality, chances are someone has already written it. While I strongly caution against including gems willy-nilly, as this can cause your dependency tree to explode and create a maintenance nightmare, it’s great to have them available as rapid prototyping and your path to a minimum viable product become that much easier.
While this is specific to me, I suspect this may be true about other Rails developers as well. I have built a number of libraries over the years that I use across my projects. This is yet another reason I can be so productive in Rails.
Performance
Yes, I know Ruby is slow. There are a plethora of languages that are more performant, some of them by orders of magnitude. But I couldn’t agree more with the desire to optimize for programmer happiness instead of raw performance. What is important to me is to optimize for my own productivity. And my happiness is an integral part of this, as well as the speed at which I am able to produce quality software. Rails affords me both.
I contend that while Ruby may be slow, it is definitely fast enough for most. We can look to Basecamp and Shopify, who are able to push 2,000 and 17,000 requests per second respectively. Sure this pales in comparison to Twitter, but let’s face it, most everyone is not Twitter.
There is a ray of hope however. Ruby performance is continually improving. Ruby 2.3.0 has optimized HTML escaping, which can lead to performance gains in Rails. Matz also recently announced Ruby 3x3, which will attempt to increase performance of Ruby 3 by 3 times.
Cargo Cult Frameworking
Now this is not meant to say there is only one right way to write web applications. Absolutely not. This is what works for me. Feel more productive using a client-side MVC framework like Angular or Ember? Go for it. Want to write isomorphic JavaScript using React? Feel free. But please, don’t pick these solutions because they are the new hotness or the way you “should” be building web applications. Stay away from the cargo cult!
Conclusion
So yes, here I am, unabashedly writing Rails applications in 2016. That’s not to say that it is the only tool in my toolbox. Far from it. But it is one that speaks to me, gives me great pleasure, and makes me extremely productive. I expect to continue writing in Rails for at least the not too distant future, though Phoenix and Elixir are looking more and more intriguing these days…