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, most of his arguments are not so 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 frameworks or any other alternatives 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 isn’t the best fit. But its strong development principles and eye-wateringly rich ecosystem make it incredibly productive to develop with. This productivity is useful not only in developing rapid prototypes — especially relevant when iterating an early product proposition — but also when developing large-scale web applications that require rich functionality and longevity.

“Ruby is slow.” Comparatively so, 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 you heard the argument made for not choosing Rails 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 it isn’t, but as arguments, they’re weak, as both offer considerable 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 twisted 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 here 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 in production, but only when they’ve been the right fit.

Without focusing too much on the validity of the evidence, I would note that search volumes don’t equate usage. Interest in something doesn’t mean that it’s being used in anger. Equally, looking at what back-end languages AngelList companies are using is certainly interesting, but hardly conclusive evidence that a particular framework will suit your use case or enjoy lasting popularity.

Which 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 likely not going to have a company three years from now.