Hanami is quite nice. I haven’t had the opportunity to use it in anger but I have had a crush on it for a while now.
I really do hope ROM-rb, the not-orm Hanami uses, gets some development love as a consequence of this more formal merger. It’s a rad tool with enough rough edges that I had to switch away from it when launching a product a few years ago.
I'm happy someone's challenging the Rails almost-monoculture in the Ruby ecosystem, but Hanami doesn't seem to bring much to the table. Is there anything in this release that Rails hasn't had for years?
I think what Hanami had to bring to the table is already on the table for years - slice architecture, repository pattern, true view layer, explicit dependency management and perhaps one that it recent - first class operations support. This release indeed does not bring a lot in that matter, rather fills the gaps in the ecosystem and DX.
I have loosely followed Hanami for years but never used it or heard of it used in a large codebase.
I still don't quite understand what it does all that differently from Rails?
There are plenty of comments that are along the lines of
> "Hanami brings is an intentional and well-reasoned architecture that supports building maintainable applications. It has taste" (posted below)
But concretely what does that mean? Their docs call out ways to avoid common rails anti-patterns and I agree with most of their opinions but you don't _have_ to write bad code in rails just because a lot of others have.
Having seen Rails deprecations at multiple large well known tech cos I appreciate the sentiment of an "architecture that grows with you" but I would say the driver behind those migrations wasn't so much the framework as the extreme flexibility of the code and what that produces with thousands of developers over 10+ years.
I don't see how any architecture of Hanami prevents that.
many years ago when Hanami was just getting popular I remember doing benchmarks against Rails when it comes to SQL and was unpleasantly surprised when Rails' ActiveRecord ended up being much faster, despite "speed" being advertised as one of the advantages :-(
I have been using Rails 8 for the past few months on a work project, but the Hanakai ecosystem looks really, really interesting.
My one question would be whether or not Hanakai supports Inertia or Svelte views - we've been moving away from ERB recently, which has made it much easier to write interactive code due to the ecosystem, and I'd rather not throw that DX away!
I've used Hanami in exactly one production codebase (but it was a huge one). I fully expect to hear the chorus of "skill issue" TM type of comments and honestly, I won't even argue with that. But that app was hands down one of the messiest, most overengineered pile of hot garbage I've ever laid eyes on, and I can't shake the feeling that at least SOME of the blame lands on the framework itself, for nudging you toward a design where you drown in an explosion of tiny classes that do nothing but hide the actual behaviour from you.
When I was working at a software house, we had a client with a Hanami app (version 1). It was one of the best-engineered apps I’ve worked on - much better than 90% of the Rails apps we were working with at the time.
The only thing I missed was better Dry.rb documentation.
wow, ai told me this was for enterprise-size apps, "symfony of the ruby world" (dependency injection, data mapping..), to which i nearly puked, and avoided since.. it's really interesting to see people try to design things in a clearer way (explicit, modular, functional/immutable, less cpu indirection/execution, etc.) in ruby. I'm new to this language, but i think it's cool that for one big framework go all in on the implicit object function magicks (rails) and another go in the opposite direction: explicit, functional, no magicks (hanami). Ruby is nutty. Reminds me of people abusing ast macro magicks of haxe to do anything. (i myself am starting with roda to have the freedom to design my own spaghetti from near scratch.. and it's perfect for me!!)
i'm glad it's built from little composable gems (unlike rails). I'll def check out the dry-rb stuff for some ideas. :) Ruby is so cool.. often leads people to make over-engineered, "clean" design solutions, but it's so easy to read and learn from, so modular, i feel i can quickly make the choice/decision to add a tiny abstraction lib or more likely DIY something even more simple, leading to near zero deps. <3 ruby!
12 comments
[ 0.21 ms ] story [ 40.3 ms ] threadI really do hope ROM-rb, the not-orm Hanami uses, gets some development love as a consequence of this more formal merger. It’s a rad tool with enough rough edges that I had to switch away from it when launching a product a few years ago.
Love the work though; having beautifully crafted options like Hanami around is a joy.
I still don't quite understand what it does all that differently from Rails? There are plenty of comments that are along the lines of > "Hanami brings is an intentional and well-reasoned architecture that supports building maintainable applications. It has taste" (posted below)
But concretely what does that mean? Their docs call out ways to avoid common rails anti-patterns and I agree with most of their opinions but you don't _have_ to write bad code in rails just because a lot of others have.
Having seen Rails deprecations at multiple large well known tech cos I appreciate the sentiment of an "architecture that grows with you" but I would say the driver behind those migrations wasn't so much the framework as the extreme flexibility of the code and what that produces with thousands of developers over 10+ years.
I don't see how any architecture of Hanami prevents that.
I have been using Rails 8 for the past few months on a work project, but the Hanakai ecosystem looks really, really interesting.
My one question would be whether or not Hanakai supports Inertia or Svelte views - we've been moving away from ERB recently, which has made it much easier to write interactive code due to the ecosystem, and I'd rather not throw that DX away!
When I was working at a software house, we had a client with a Hanami app (version 1). It was one of the best-engineered apps I’ve worked on - much better than 90% of the Rails apps we were working with at the time.
The only thing I missed was better Dry.rb documentation.
i'm glad it's built from little composable gems (unlike rails). I'll def check out the dry-rb stuff for some ideas. :) Ruby is so cool.. often leads people to make over-engineered, "clean" design solutions, but it's so easy to read and learn from, so modular, i feel i can quickly make the choice/decision to add a tiny abstraction lib or more likely DIY something even more simple, leading to near zero deps. <3 ruby!