Talking webdev: Ruby, the minimal way

This is not another “Oh, Rails is sooo yesterday” post. I have a lot of respect for Ruby on Rails. It made me a better developer and exposed me to concepts unknown to me at the time. It enabled me to grow. It also introduced many people to Ruby, helped to form a great community around it and changed the way we code for the web. Recently, I was introduced to a different way of doing things that excited me. These are my thoughts on it. (I know that there are ways to slim down Rails to the absolute minimal configuration, but that’s not what Rails is about as it wasn’t built with that in mind)

It would be a lie to say that many people didn’t get introduced to Ruby because of Ruby on Rails. That’s the way it happened for me in 2009 and that’s the way it happened for the majority of the developers I’ve worked with since then.

Some years later and things have changed. Ruby on Rails grew bigger (a lot bigger actually), Bundler was made a necessity and rvm became very popular when it came to Ruby version management.

Working mostly at the backend, these were my tools of the trade for many years. I started using them and once I got fluent with them, I never considered to replace them, not even when new tools came out.

However, a couple of years ago, when I start digging into front-end for the first time, I had the chance to look back and question the way I was doing things, especially using Ruby on Rails. By working in the frontend you can see backend requirements and responsibilities from a different perspective.

So, the combination of the tools I’ve mentioned earlier might have been an overkill after all. They gave me a lot of power and made my life as a developer a lot easier, however, this came with a cost. They came with functionality that I didn’t always need and that was something I never questioned or thought about. You could argue that this isn’t an issue. Well it’s not, until you realise that it is actually an issue.

I had the chance to work on quite a few projects and I noticed something in every single codebase I got to touch: lots of Rails features have been abused. I’m also guilty of this. Depending on the time the project was put together, I was able to see techniques that were trending around that time. And that’s perfectly fine. However, the abuse of these techniques isn’t. These were applied to parts of the application that didn’t make sense to be applied or they were being used when it wasn’t necessary, just because they were pronounced as the “new way of doing things”. Call it observers, action filters, model callbacks, validation context, concerns, etc. I’ve seen a case for each one of them.

You can’t blame your framework for the quality of your code. These features were abused because we, the developers, were allowed to do so and get away with it for a long time. Well, at least before we hit a wall.

I still remember articles that encouraged the “Skinny Controller — Fat Model” approach. Yay! Let’s move everything to the model: validation, callbacks, business rules. Everything! Now that I think of it, why should I make my model fat? Obesity isn’t a good thing for humans. Why should it be for my Ruby class? Cluttering responsibilities in a single unit was never a good thing. Then, there are these sort of questions:

• Do I need all this magic Rails provides for everything I build?
• Performance? Is the ease of use worth the trade-off?
• Is Bundler necessary for handling a small gemset?
• Should I feel guilty for not doing things the Rails way?

All of the above could be summarized in one single question: Should I allow my tools to dictate the way I build things? For the sake of this article I’ll have to answer no.

The more time passes, the less I feel the need to base my work on an “all in one” framework. I’ve noticed it slows me down and eventually, having to battle with its overhead makes me unhappy.

I recently got introduced to the Cuba micro-framework. Cuba is a gem that does one thing and it does it pretty well: it handles HTTP requests. Apart from providing integration with various template engines, it does not provide any additional functionality and does not dictate the usage of any library. You will have to choose your ORM, template engine, mailer solution from a range of great libraries that are out there. It might sound like you’ll have to re-invent the wheel, but that would be a wrong way to approach the subject if you are after simplicity. I like Cuba for a variety of reasons, but I’m not going to get into details or examples of how to use it as the Github repo provides lots of examples and documentation.

The creator of Cuba suggests using gs and dep for handling your application dependencies. I’d never heard of these two before. gs recreates the absolutely minimal feature set for managing gemsets by using a hidden directory inside your project directory in which dep installs your dependencies. Then it adds this dir to your $PATH so that gem binaries become available to your session. One thing that I don’t like about gs though, is that it allows you to modify your $PATH for as long as you keep running the gs command.

For Ruby version management there’s chruby, a very simple tool for the job that plays nicely with gs and dep. Nothing happens under the hood with this one as it does not override the cd command or switch rubies automatically by default.

That said, by going minimal you will not find the ease you experience when using Rails. There might not be many resources to get help from because you will be putting your own framework together. However, the whole experience will definitely serve as food for thought and make you question the way you have been doing things for the most part. You will find it very rewarding.

In the very end, no matter the approach you choose, keep in mind that all these are just tools and tools don’t make the master craftsman. It’s always the result that makes the difference.