Friday, May 27, 2016

Is Rails a cul-de-sac?

A lot of people know and respect Piotr Solnica. His blog ( is really good. He is a core developer to a number of Open Source Software projects. And he was a RoR user.

I say he was because last week Piotr wrote this interesting article criticizing Rails and stating clearly he is leaving the Rails and the Ruby communities. His article mentions lots of technical reasons why he believes Rails is not good. And any average-to-good software architect is going to agree with most of his points.

Rails is not just a meta-framework for Ruby language. Rails is also, and mainly, a set of decisions made to create an easy environment for web developers to create their applications. Of course, not all the decisions taken by the Rails team are based on the best architectural techniques.

Some of these decisions are, in fact, very bad, although they seem very good at first sight. And I have a great example to show this: scaffolding.

When I first saw a Rails presentations I got fascinated with scaffolding. Imagine that! Creating a whole set with Model, Controller and all needed Views with a single command! This fascinates new users, for sure, but it is not good. Now that I am an experienced RoR developer, I seldom touch scaffolding. In fact, I only do that when teaching Rails to someone else. And even so, clearly stating this is not a good decision when working with a real project (

And this is only a "visible" point, in the sense scaffolding is something Rails users really see happening. If you enter Rails code ( you'll surely find lots of points where practical matters replaced good architecture.

This is one of the reasons why Rails is so heavily used nowadays. Most developers are looking just for a fast and (relatively) safe developing tool. They are not interested in the architecture quality behind the scene. In fact, the common web developer is not even qualified to understand this architecture completely. But this common web developer loves Rails exactly because it is practical and fast.

Piotr also says that, after six months, Rails applications may turn into a maintenance hell (the words are mine, but this is what he meant). My experience says he is right, but not for the right reasons.

Most Rails developers are looking for a fast tool because they are always in a hurry. They are always behind schedule. And this means they are not going to do the elementary procedures to keep their systems easily maintained. Like documenting! I've studied thousand of lines of RoR code in the last few years, exactly because one of my skills is fixing systems when they are broken. I haven't seen many inner documentation. And I'm not even going to mention external documentation. In these days of Agile-all-around, nobody cares about creating lots of diagrams and text descriptions. Things are discussed on GitHub issues or Trello boards and this is all the external documentation you'll find out there right now.

I think Piotr has a great point when he says that Rails core team is a bit "bad mannered" (here again this is my interpretation of his words). I noticed that long time ago and this is one of the reasons why I never got interested in contributing to Rails directly, although I keep an eye on the development almost daily. If you do the same you'll frequently see what I mean. People create pull requests and Rails developers reject them with no more explanation than "We believe this is not useful". Not a great courtesy, except from one or two of them. This strongly discourages people to contribute. When your pull request is rejected but you receive a good explanation telling you why it was rejected, you feel that they care about your contributions at least, even when they don't use it in the software. But if one says only: "Not useful" most people got upset with this approach. I don't really care. I have no personal feelings when it comes to work. But I'm not a good example, since I've been in this market for the last 32 years and then I had enough time to learn that: a) My code is not the best code in the world; and, b) Rejecting my code is not rejecting myself. Some people do confuse these things and react really bad in these situations.

Fabio Akita wrote a great answer to Piotr's article:

I suggest you to read both articles before taking a decision about what side you're going to line up with.

After that, I'd be really pleased in reading about your position on this subject in the comments.

See you soon.