I Wish I Liked Hanakai

Ruby on Rails means a lot to me. It was the main stack of my first “real” job, and I immersed myself in its culture. It’s also a tool I’ve found joyful to use in personal projects. Rails even hails from Chicago, my adoptive hometown. But Rails has a couple big problems.

First off, being web framework that made the language highly desirable for a while (at least in monetary terms), its popularity dwarfs the language community. Ruby is so synonymous with Rails that it’s sometimes easy to forget that there’s anything else. ActiveSupport for example is pulled into so many things by default that I am still occasionally surprised to learn that a utility wasn’t in the stdlib to begin with (lookin at you #symbolize_keys). Rails has an outsized gravitational pull and it warps the community around it to a degree.

And then this paragraph was going to be the section where I say DHH is a bit of a jerk but actually at this point we are way past that. Deciding to parlay his relevance as a techbro has-been into twitter popularity among the euro-racists, DHH is now openly calling for a new era of ethnic cleansing in Europe. I think that is vile. I would rather not have even a tenuous connection to him, and having him heading up a project I rely on is upsetting.

That’s not a very satisfying conclusion for me either though. I think that in the end you have to be able to live with somebody. Cutting ties with a project over the personal views of their maintainers leads to a smaller world than I would like. But there’s a lot of cruel people in the world, and I don’t know how much I want a share in a world where people like DHH are rewarded for their cruelty.

Enough About Rails

This is a blog post about not using Rails.

I have been following Hanakai for a while now, and I think it’s a cool project. I like that they are undaunted by the more popular framework in their domain. Their style finds a nice balance in acknowledging that their users are likely familiar with Rails without trying to focus too much on being a drop-in replacement for Rails. Plus, they have an engaged (if small) community and they seem to take listening to that community serious. Hats off to them.

I just wish I actually liked using their libraries more. One of the interesting design threads through their work is low-magic declarative interfaces with pluggable implementation backends. In principle, I really like this, and it is a breath of a fresh air coming from a heavy Rails background (where I have lost hours digging through the source code to make sense of the unconfigurable “convention” that my edge case is running up against). It feels like a toolset that lives up to Rails promise that you can just use the parts you want.

I have a personal project involving archiving images that is fairly boring, a collection of Ruby scripts. I have recently decided to put the information in Postgres instead of the pretty printed JSON file that was holding it before. I wanted to give ROM a try because it seems like the kind of project this component-oriented design ought to work well for. I have literally a single table I want to work with, and at the moment there is no web server or other scaffolding to hook into.

I did not succeed. The tab with ROM’s documentation sat open for a week, then two, and yet I could not tell you what the difference is between a relation and a repository, nor why I should care. The docs had a lot of examples emphasizing the generality, but I don’t use many different databases and I struggled to find the specific postgres initialization options (for personal projects Postgres is the only one I’ve ever really found to be worth the trouble). As I usually do when the docs aren’t specific enough for my liking I went looking for the code, but the modular repo structure made it difficult for me to figure out where the relevant bits of code even reside.

Then one night I decided to write it with plain old pg and a couple handcrafted queries and it was done in the span of a few half-watched episodes of King of the Hill.

I don’t think it’s really fair to blame Hanakai for this experience. Rails is at least as complex and inscrutable if not more, but that complexity is accepted because it’s just so common. I’ve been into the guts of ActiveRecord with enough frequency that the gnarls don’t stand out to me anymore. A framework targeting the same kind of production-grade use cases as Rails has an uphill battle to fight getting folks like me who have already learned a lot of Rails’ twists and turns to accept the cost of learning a new way of doing things instead of just doing it the way we know.

Also I think to a degree I’m a bit too much of a dirty hacker for my own good. I know reasonably well how Postgres works and how to create the DDL and queries I want by hand. A library like ROM treats abstracting this away as a feature, value added to the busy developer who may have only a passing familiarity with the database and just wants to ship this today. To me however it feels more like a cost because I already know (or at least I think I know) what it is I’m trying to do so I’m frustrated about trying to coax a library into the writing the query I have already written in my head. pg handles the dirty work of the wire protocol and (de)serialization but otherwise it leaves the abstractions or lack thereof up to me. Sometimes I’m just not in the mood for a library that’s trying to hold my hand.

If there’s a nugget of real critique though it’s that the modularity seems like it’s something I have to work for rather than something that works for me. Users appreciate options, but if those options don’t come with easy defaults then the user needs to make potentially complex design choices just to get off the ground. For a hobbyist, that’s a big hurdle to clear just to give something new a try.

I’m not done with Hanakai though. Using Rails for my small hobby apps sometimes feels like using a backhoe to build a sandcastle, and I have long had my eye on Hanami as an alternative. I’ll probably even give ROM another try at some point, when I have a data layer complex enough to warrant it (or if I want to use something other than stock Postgres). We just have a ways to go still before I can love it like I have loved Rails.


Blog

Home