Rails Hurts
Let's fix that

Also read:


Book
Scared to change anything in your code?
Try Painless Rails approach

The state of Rails in 2018

In short:

  • Rails is not evolving
  • Hanami is not a panacea
  • There is no common Rails Way 2.0 or anything like this
  • Finding the golden mean between Rails way and Java way is hard
  • …But doable!

Giving Rails another chance

I didn't use Rails for quite a while. Recently I decided to take part in one project to refresh my skills and knowledge of Rails.

I was trying to follow the Rails way as long as I can. Once I've got into troubles, I switched to my "fallback strategy" - I started using extra building blocks like Services, Form Objects etc.

Although, even after that I wasn't satisfied with the result. I saw that if the app will keep growing, I will have problems.

I had the same exact feelings like wo years ago, when I was using Rails more actively. Nothing has changed, I still had more questions than answers.

Quick research demonstrated that the state of Rails community is still more or less the same:

  • A decent part of developers are tired of Rails and keeps looking for alternatives. It is hard to find a single Ruby conference without an Elixir talk.
  • Popular resources keep teaching treating all Rails features as safe and useful. The more and more developers get into same problems as we did for years.
  • Rails didn't change. They're adding things here and there, but conceptually it remains the same.

The major difference between now and then is that Ruby underground (Hanami and DRY) has become mature. If you're tired of Rails, but still in love with Ruby, you have a place to go.

Rails vs Hanami dilemma

Though it is important to realize that 90% of Ruby jobs are Rails-related, so it might be hard to find a practical usage of Hanami.

I personally gave Hanami a try, and I was a bit disappointed. Yeah, Hanami is based on the Clean Architecture principle, it has a strong flavor of Java. It is not necessarily a bad thing, of course. Although, it forces you to care about all the building blocks up-front. It means that you have to write a lot of boilerplate code, therefore more work when you're starting a new project.

I can't say for the whole community, but my personal We're spoiled by Rails approach when you get a lot of things done by a little of code. I love when framework allows a certain amount of laziness. Unfortunately, it is not about Hanami.

It is hard to predict the future of Hanami, but I doubt that it will become a mainstream.

Can we get something in between?

The search for the golden mean

Ways

Here's what happens to a lot of Rails developers:

  1. You're excited about Rails ecosystem and all the power it gives you.
  2. One day you see where this approach leads you, and you become far less excited.
  3. After few more attempts, you start to explore the opposite approach - SOLID, OOP, and the Java way.
  4. You find the price of Java way too high and trying to get best parts from both worlds.

I am not saying it is the only possible trajectory, but it is what happened to me.

This final position is very uncomfortable. It is because you can't rely on simple rules anymore. Now you have to turn on your thinking process:

  • Is this feature of Rails good or bad? Why?
  • Should we get rid of ActiveRecord?
  • Should we care about SOLID in Rails applications?
  • Is SOLID even applicable to Rails apps?

..and millions of other interesting questions.

RailsHurts is back in business

Luckily enough, I recently attended a workshop of Hexlet CTO, Kirill Mokevnin. He described their way of organizing code in Rails applications.

When I listened to it, it felt like he is telling me the contents of a book I always wanted to write. Basically Kirill described a set of conventions and techniques to prevent negative effects of Rails.

So, I have some good news for you:

  • It is possible to develop a system in Rails to keep code maintainable over time
  • The biggest part of the techniques are simple and easy to apply

And the bad news:

  • To understand why these techniques and principles work, you need to go far beyond frameworks and programming languages
  • It might be hard to introduce these techniques to a regular legacy Rails app

So, that's me again full of aspiration to finish the book, I started more than two years ago :) In fact, it will be a different book, but it is going to serve the same purpose - to help Rails developers produce maintainable Rails applications.