A lot of people have asked me why I stop doing Rails development, especially after finally making my contribution to the framework with web_console. While it's true that my full-time job doesn't involve Rails anymore, it's not the real reason. The real reason is that I no longer find the Rails philosophy suitable for me.
Rails is too big. As a framework it tries to include everything the community think is useful, a lot of which ends up being unnecessary. I often use Rails without core components like ActiveRecord or default gems like Jquery and CoffeeScript. Whenever there's something I don't need, I'll remove it from the runtime environment to gain more control and avoid overhead later on. While it works well for me, most Rails developers I work with don't like the idea of convenient stuff taken away from them. I usually end up in pointless arguments about which components are needed and whether they should be removed. Those
arguments can be avoided if we use lightweight frameworks that enforce manual inclusion of necessary components instead of removal of unwanted ones. The less opiniated a framework is, the less headache to put up with.
Another source of my frustration with Rails is the abundance and over-using of gems. Pure Ruby gems are generally well-written, and some are fantasic at what they do. However, Rails gems are the opposite. There are so many of them, almost one for every little thing you can think of in web development. In my previous projects, a Gemfile with 100+ gems is quite normal with a whole bunch of features I'll never need. It's quite a nightmare to clean up when the project becomes bigger. Moreover, I always try to stay away from gems that alter database structure or production environment in some way, including extremely popular ones like like
paperclip. While they're undeniably convenient, it's not very transparent about what they do behind the scene. If the internal working of the gems are not easy to tell, explaining application structure on top of them would be a challenge. Therefore, to make the code easier to maintain, it's best to just implement the features yourself and use Gems when they're really needed. Unfortunately lots of Rails developers don't understand or don't have the time budget to do this. Technical debts are then unavoidable.
Breaking down a monolithic Rails application is another thing I hate. At some point a Rails application will become too big and hard to scale horizontally. The best strategy at this stage is to break it down into smaller services, each of which can be scaled individually in a distributed environment. It's not an overnight work for sure and requires a lot of commitment from both engineering and business. All of the time saved by rapid development at the start of the project will probably be eaten up by this process, not to mention the frustration that goes along with any big refactoring. That's why nowadays I very much prefer non-monolithic, service-oritented approach. It gives me more control of the whole stack and the flexibility to adapt to changes later on.
To be clear, Rails is not bad at all. In fact, it's a fantastic framework for building conventional web applications and quick prototypes. However, I've experienced the bad side of the framework and now its philosophy is not working for me anymore. I'm sure there are better ways to do Rails development, and people are having huge success with the framework. But for now, I'd like to explore different options to find out what works best for each of the projects I do. I'm still contributing to
web_console, but it'll be a while before I create web applications with Rails again.