Why would I not use Rails for a new project?

We did Scribd on Rails, and it became the third most visited site on Rails, and the framework worked as it should. But today I see a huge number of new projects that use Rails, and seem to make a mistake.


I started using Rails in 2006, immediately after the screenwriter David Hansson, in which he introduced the framework to the world with fanfare. We wrote the first version of Scribd on Rails 0.7. Then, when the framework did not even have migrations.

There was a lot of noise around Rails at the time, but choosing it was a rather risky move. Most of the new sites continued to write in PHP and Java - this was due to the presence of a huge number of developers for these platforms. We bet that Rails will continue to gain popularity, get a suite of good libraries and an army of loyal developers.
')
We were lucky! While we were raising Scribd, Rails was growing along with us. It became the base technology for developing new Silicon Valley projects. Java Spring developers, PHP and ASP.NET understood what was going on and started looking for a job where they could switch to a new language. When our project took off, we were the winners - talented guys were drawn to us, because we could offer them to work on Rails.

Wind of change

I'm worried about the heyday of Rails already behind. Running a new project on Rails now is almost the same as running a Java Spring project in 2007. The graph below shows which web frameworks googled from 2007 to 2016.



Source: Google Trends

It is impossible not to see that the interest of developers has moved from Rails to the side of newer frameworks.

Rails biggest problem is Ruby

Everyone knows that Ruby is slow. But in fact, Ruby is the slowest language among popular programming languages.


Why is Ruby so slow?

Some will point out the characteristics of the language that have developed historically. And this is true. But I think there is a deeper reason. Ruby has no corporate sponsor.

Back in 2007, Python, PHP and JavaScript were quite slow languages. Facebook has invested heavily in PHP and created HipHop to make it faster. And Google accidentally pushed the rapid development of the server-side JavaScript, making a quick JIT-compilation in JavaScript.

The Ruby interpreter is made by volunteer efforts. Between 2007-2012, there have been more than once attempts to fix the interpreter and make it fast (Rubinius, JRuby, YARV, and so on). But the lack of a reliable sponsor led to the fact that the volunteers were bored and blown away. JRuby is still active and the latest versions are promising, but there is still a lot of work ahead.

Twitter, the first large IT company on Rails, could pick up Rails and repair the interpreter. Just like Facebook did with PHP in its time. This could change everything and guarantee the dominance of Rails for years to come. But Twitter engineers decided that rather than speeding up Ruby, it’s easier to rewrite Twitter in a faster language.

Rails stood still while others caught up with him

Rails owns many discoveries that have made writing regular web applications faster. But after some time, other frameworks just picked up these innovations. Now Django for Python is a Rails clone. The same can be said about JavaScript Sails.js. And these frameworks do not suffer from the fact that they are written in “non-mainstream” programming languages.

At the same time, the development of Rails itself stalled. Its third version was released in August 2010. Github did not switch to a new version of the framework for four years - the benefits were not significant enough. Recalling the pain we experienced while upgrading Scribd to Rails 3, I’m not sure that we will ever take a chance with Rails 4.

It is interesting to compare the growth of innovation in JavaScript and front-end development with the stagnation on Rails. In the past 7 years, our backend has been changed in small steps, and the front-end migrated from Prototype to jQuery, then to Coffeescript, then to Angular, then to React. Every time - with an increase in productivity.

Recruits

In the past two years, many beginner programming learning centers have grown. They teach a lot of things, but when it comes to developing the server side, the advantage for Rails. Apparently, this is the market's response to the still high demand for Rails developers from startups.

On the one hand, the Rails ecosystem won because the number of talented people inside it increased. Unfortunately, there was the opposite effect. Serious developers, especially those with a degree in computer science (CS), began to look down on these courses as “programming on tops”. I noticed that more and more experienced developers were reluctant to work on Rails - due to the framework's tainted reputation. I saw how it happened with Flash / ActionScript: serious developers often (erroneously) treated it as a light version “for designers”.

New players

Among the frameworks there are several strong contenders for the status of a Rails heir. Node.js leads Do not believe? Here are statistics on the use of server languages ​​by popular companies:


Source: CodingVC

And here it is shown what happens in the labor market:


Source: indeed.com

This is despite the fact that all new languages ​​have flaws. Node.js suffers from crushing with six competing frameworks. Go is very popular for microservices right now, but lacks large-scale applications. Django / Python seems to hold its ground, but does not grow either.

If you want to be confident in your web application, you need to understand what the engineers will want to write on in three years. This is more important than choosing a framework that will increase productivity right now. If you are Facebook, you can use anything, people will still want to work for you. But most companies are not Facebook. In general, if you guess, then additional efforts will not have to be made - a new popular framework will attract personnel to you on its own.