No, seriously!
- Rails is optimized for happiness, they said.
- On the other side, Rails is packed with sharp knives, they said.
Does that sound ok to you?! In this situation, only the very experienced chefs would be happy.
The rest of us find ourself in trouble, with fingers and other parts of our bodies cut, when it comes to bigger projects.
I believe that Rails needs not only the documentation, but also some sort of "safety instructions" to explain safe ways to use its features.
It is also about many unspoken unquestionable rules in the community, which make things even worse. Newcomers tend to follow them thoughtlessly:
- use devise, rspec and factories,
- always write unit and integration tests.
These are good tools and techniques, but many of them have limited scope of usage. We tend to focus on instruments, but it keeps us from seeing the forest for the trees.
We starve for answers
Since Rails itself doesn't address many of our problems, we have to come up with our own solutions. As a result, we have dozens of ways to do Service Objects and Form Objects, and it makes everything even more complicated.
Some of us seek the truth in pure Object-Oriented approach and turn our applications into a semblance of Java-like enterprise monsters. A pure functional approach, on the other hand, results in non-idiomatic Ruby code, which is no good too.
Best people in the community get tired of ideological stagnation of Rails and its inability to give answers to the most burning questions about big Rails codebases organization, and migrate to other technologies: Elixir, Rust, Go, Clojure, you name it.
I've been through all these stages:
- from Rails way disciple
- to Rails criticist
- and to the stage of lost hope.
The hope is not lost
Luckily, I've discovered an approach which finally gave me the answers I've been looking for.
These days I am exploring this approach and describing it in the book. I called it "Painless Rails". On the one hand, it gives just enough structuring to support good old monolith of any size. On the other hand, it:
- Doesn't fight against the framework
- Doesn't rely on discipline
- Brings as little overhead as possible
- Provides a single way of doing a certain thing
- Embraces meaningful abstractions
Now I know that it is possible to stay on Rails, but avoid its pitfalls.
This makes me happy Rails developer again.
- Read more about the book
- Follow on twitter
