I’d argue that the pitch didn’t exactly lie to you, but the person delivering it may have unintentionally done so, much like I’m probably going to sound like a jerk in this response, though I assure you that I don’t intend that.
Is Hanami lighter than Rails? Incredibly. Is it more approachable? To some, but almost certainly not to all (particularly those that learned development the Rails Way). “Approachable” and “easy” are a matter of taste, and some of us find the counterpoints to Rails present in Hanami to be outright delicious.
- Code generators: I just don’t see the need. Suggests to me that it’s already too complex.
I’m not a big fan of code generators in general. A lot of people do like them and/or have come to expect them to ship with every framework, so they were requested and implemented in kind. It’s an unfortunate situation where expectations within the industry have been managed in that specific direction. The awesome part is that you don’t have to use them, but if they’re present, the guides and related reading are always going to illustrate the use thereof.
Aside: From my POV, Hanami is one of those things that is both simple and complex. The implementation itself leans towards simplicity, and the usage of that implementation leans towards complex (relative to other solutions). It also seems that it’s geared less towards the development of a specific sort of application than frameworks that lean toward simpler use. I’d argue It’s trading out ease of use in favor of classically “better” programming practices, and I quite like that myself.
Like, as a practice, or the way the practice is used in Hanami apps/guides/whathaveyou?
I’m pretty biased in favor of the practice, but I’m not gonna tell you how to do you. I mostly wonder if the reasons you hate it align with the reasons that I used to hate it.
- Views + Templates: I’m sure there’s a reason but MVC seems like plenty of separation already.
Here’s the part where I’m worried about coming off like a so-and-so, mostly due to too many years as a developer and the opinionated nature of both sides of the argument. The following is going to come off as a statement of fact unless I point out that it’s totally just my perception:
The MVC model presented to the Ruby community for the last several forevers, depending on who you ask, is basically just a subset of “real” MVC, mutated by the opinions of the Rails dev team. The MVC model represented by Hanami is a bit closer to the “real,” but that’s splitting hairs. The reasoning with all of the separation within Hanami MVC is to express an actual, tangible separation of concerns, which is generally considered to be a good thing.
- Data: Specifying my data 3 times seems unnecessary (entity, repository, migration)
If using hanami-model, it’s necessary, as hanami-model is an implementation of the Repository and Data Mapper patterns. If using a different persistence mechanism (activerecord, sequel-model, what have you), it might not be necessary. Persistence in a Hanami app is configurable, though the guides (and most related reading) are going to point you toward hanami-model.
I’ll keep going but I feel some wind has been taken out of my sails.
All the above said, best of luck, and I very much hope that I haven’t made the problem worse. I’m having a bit of trouble getting rolling with Hanami myself, but that’s mostly a lack of time and effort on my own part.
Speaking from my own experiences, that deflation is going to happen on occasion (particularly with the way our community is prone to hype). On the bright side, it could just be that Hanami is not the tool that you need for your specific use case, and that’s manifesting as frustration with the framework.
