Why I would not use Rails for a new project

Original author: Jared Friedman
  • Transfer
We made 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 be making a mistake.


I started using Rails in 2006, right after the screenwriter David Hansson, in which he pompously introduced the world to the framework. 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 buzz around Rails at the time, but choosing it was a pretty risky move. Most of the new sites continued to write in PHP and Java - this was facilitated by the presence of a huge number of developers for these platforms. We bet that Rails will continue to gain popularity, will acquire a retinue of good libraries and an army of loyal developers.

We were lucky! While we raised Scribd, Rails grew with us. It became the underlying technology for the development of new Silicon Valley projects. The developers of Java Spring, PHP and ASP.NET realized what was going and started looking for work where they could switch to a new language. When our project took off, we won - talented guys came to us, because we could offer them to work on Rails.

The wind of change


I'm worried that the heyday of Rails is over. Starting a new project on Rails now is almost the same as starting a project on Java Spring in 2007. The graph below shows which web frameworks google from 2007 to 2016.



Source: Google Trends

It is impossible not to see that the interest of developers has moved from Rails towards 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 fairly slow languages. Facebook invested heavily in PHP and created HipHop to make it faster. And Google accidentally pushed the rapid development of the server side of JavaScript, making JIT compilation quick in JavaScript.

The Ruby interpreter is made by volunteers. Between 2007-2012, more than once attempts were made to repair 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, Rails' first large IT company, could pick up Rails and repair the interpreter. Exactly what Facebook once did with PHP. This could change everything and guarantee the dominance of Rails for years to come. But Twitter engineers decided that than speeding up Ruby, it's easier to rewrite Twitter in a faster language.

Rails stood still while others were catching him


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

At the same time, 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. Remembering the pain we experienced while upgrading Scribd to Rails 3, I'm not sure we will ever risk it with Rails 4.

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

Recruits


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

On the one hand, the Rails ecosystem won because the number of talented people inside it increased. Unfortunately, there was a reverse effect. Serious developers, especially those with a degree in computer science (CS), began to look down on these courses as "programming at the top." I noticed that more and more experienced developers refused to work on Rails because of the damaged reputation of the framework. I saw how this already happened with Flash / ActionScript: serious developers often (erroneously) treated him as a lightweight version "for designers".

New players


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


Source: CodingVC

And here is what is happening on 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 right now for microservices, but lacks large-scale applications. Django / Python seems to be holding on to its position, but not growing.

If you want to be sure of your web application, you need to understand what 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 on Facebook, you can use anything you like - people will still want to work for you. But most companies are not Facebook. In general, if you guess, then you don’t have to make additional efforts - a new popular framework will attract personnel on your own.

Also popular now: