Eight years ago, when working with a client for whom we were proposing to build a new publication website and CMS in Ruby on Rails, one of our client’s advisors referenced a blog post that advised against using Rails. I wrote up our response to this and then lightly edited it into a blog post. I didn’t publish it at the time, but coming across it in my notes recently, I thought that revisiting the arguments against a particular tech stack at a given point in time might be interesting as a curiosity.

While I don’t have a view of Rails’s viability in 2023, the arguments for or against choosing a tech stack are still as relevant as ever. Do you choose based on what developers use today or what they (might) want to use in the future? Which is more important: performance or productivity?

Was Rails a good or bad call? All I can say is: the site we built for the client is still running and actively being developed. (Unlike the blog posts I referenced, I might add, which I had to dig out of the Wayback Machine.)

The following was originally written in October 2015.

Jared Friedman wouldn’t use Rails for a new company. Fair enough, he’s entitled to his opinion. However, his reasoning deserves scrutiny. While the trends in web frameworks that he cites are interesting, I’d say that most of his arguments are less than clear cut. The biggest flaw in his blog post is that it doesn’t mention what kind of application “a starting company” would be developing.

Rails certainly isn’t suited to every situation, but the same can be said for Node.js or any other framework–language alternative available. Leaving this critical aspect out fundamentally leaves Friedman’s titular claim without a leg to stand on.

For example, in systems that require real-time communication, Rails quite obviously isn’t the best fit. But the strong development principles and eye-wateringly rich ecosystem make it eminently suitable for large-scale, read-heavy web applications that require rich functionality and longevity.

“Ruby is slow.” Perhaps, but the speed of the executing language is hardly the key factor in providing a fast user experience in web applications. So much more goes into architecting a modern web application that can scale.

Some years ago, the argument for not choosing Rails was that it wasn’t mature or popular enough — meaning that it lacked functionality or it’d be hard to hire developers. It’s somewhat ironic to now hear that Rails’s maturity (“development has stalled”) and increasing availability of developers (“bootcamps teaching Rails") are now considered weaknesses!

These two arguments essentially boil down to “Rails isn’t cool any more”. Maybe so, but as arguments, they’re hardly clear cut, as both have upsides: increased talent pool (which Friedman mentions) and a more stable framework not taxed by constant upheaval typical to early-stage frameworks. (As our devops engineer tweaked the “devil you know” idiom: “I prefer in-your-face evil to the lurking evil you have no idea is going to hit you.”)

Admittedly, as a company with lots of experience in using Rails, we are naturally predisposed to use a framework and language that we’re familiar with. However, we constantly investigate and evaluate various new technologies and frameworks at Made by Many (see our provocatively titled, three-part series on replacing Rails with Go). We have also used both Node.js and Go, but only when they’ve been the right fit.

Building a modern, scalable web service, like a publication with structured data, massively plays to Rails’s strengths. Rails offers both the productivity to develop software quickly and the robustness to support enterprise-scale applications that are maintainable and can scale and grow as needs change.

Without focusing too much on the validity of the “popularity” evidence, I would note that search volumes don’t equate usage. Interest in something doesn’t mean that it’s being used. (The comparison of Rails and Node.js in job trends, mentioned by Charles Nutter in the comments, is interesting as well.) Equally, looking at what back-end languages AngelList companies are using is certainly interesting, but it does beg the question: what percentage of companies on AngelList will end up going bust?

Which neatly brings me to Friedman’s final summation:

“If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now.”

Without productivity now, you’re not likely to have a company in three years.