We built Scribd into the #3 largest rails site by traffic and it worked for us, but these days I see a lot of new companies using rails and it feels like a mistake.
I started using rails in 2006 right after DHH’s screencast which introduced rails to the world with a bang. We wrote the first version of Scribd in rails 0.7, when they hadn’t yet invented fancy things like migrations.
At the time, rails had buzz but was far from a safe choice. Most new sites were still being written in PHP or Java, and there were huge numbers of engineers for those platforms. We were making a bet that rails would continue to gain mindshare, creating a deep set of open-source libraries and, most importantly, a pool of developers interested in working in it.
It was the right bet. As we grew Scribd to the #3 largest rails site, Rails grew with us, becoming the default web application stack for new silicon valley startups. Java Spring, PHP and ASP.NET developers saw the writing on the wall and sought out jobs where they could switch. As one of the first rails sites to hit scale, we benefited enormously from this, picking up great talent by offering a chance to work with rails.
The winds are changing
I worry now that rails is past its zenith, and that starting a new company with rails today might be like starting a company using Java Spring in 2007.
This graph shows the relative Google search volume of different web frameworks.
(from Google Trends).
You can see how rails is losing mindshare to newer frameworks.
Rails’ big problem: ruby
Everyone knows that ruby is slow. In fact ruby is by far the slowest mainstream programming language.
Why is ruby so slow?
Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.
The ruby interpreter is just a volunteer effort. Between 2007-2012, there were a number of efforts to fix the interpreter and make it fast (Rubinius, JRuby, YARV, etc) But lacking backers with staying power, the volunteers got bored and some of the efforts withered. JRuby is still active and recent versions are showing more promise with performance, but it’s been a long road.
As the first major tech company to grow up on rails, Twitter could have embraced rails and fixed the interpreter, much like Facebook did with PHP. That would have been a game changer, ensuring rails’ continued dominance for years. But Twitter’s engineers decided it was easier to rewrite Twitter in faster languages than to make ruby fast.
Rails is static while others have caught up
At the same time, development on rails itself has stalled. Rails 3 was released in August 2010 but Github didn’t upgrade to rails 3 for four years because the benefits were not that compelling. Based on the pain we experienced upgrading to rails 3 at Scribd, I’m not sure if we will ever upgrade to rails 4.
In the last two years, there has been an explosion of programming bootcamps. These bootcamps teach a variety of things, but when they teach server-side development, they overwhelmingly teach rails rather than other languages. Presumably this is the market’s response to the still-heavy demand for rails developers at startups.
On one hand, this benefits the rails ecosystem by increasing the talent pool. Unfortunately it has also had a perverse effect. Serious developers, particularly ones with CS degrees, look down on bootcamp programs as “programming light”. I’ve noticed a disturbing trend of experienced developers not wanting to work with rails now that it’s been “polluted” by this reputation. I saw a similar thing happen with Flash / actionscript where serious developers often (wrongfully) regarded it as a watered down language for designers.
New games in town
A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead. Don’t believe me? Here’s the breakdown of server languages used by popular companies on AngelList:
And here are the growth rates in job trends on indeed.com:
Granted, the new languages all have drawbacks. Node.js suffers from fragmentation with a half dozen frameworks competing. Go is hot right now for microservices but the frameworks are lacking for large-scale apps. Django / Python seems to be holding steady but not growing.
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. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook. If you bet right and get in early, you can ride the wave of momentum that a new popular framework generates.