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.
We re-did our homepage recently, and we should make these things clearer. They're legitimate concerns and questions. We agree you don't have to write bad code in Rails, and we don't pretend that we can prevent bad code in Hanami. Instead we give application builders the tools to architect their applications in the way they desire. Really what we're doing is building an *option* for building Ruby apps that may speak better to some people. If you're completely happy with Rails then there's no reason to change. Still, you may learn something that'll help you build Rails apps by seeing how we do things. Additionally, it's completely modular: you can pull parts of Hanami into a Rails app. The most popular one people pull into Rails apps is dry-validation [1]
Some concrete differences:
- We have small, simple API's. Rails core classes have hundreds of methods for convenience, not to mention dozens of core extensions (a.k.a. monkey patches) to base Ruby classes. We prefer small, narrowly focused classes over large ones with many responsibilities.
- We have a dependency injection framework dry-system [2] included by default. This lets you write `include Deps["repos.article_repo"] to get an automatically instantiated (and now memoized!) `Repos::ArticleRepo.new` within your class. This makes dependencies trivial to stub out, and it also declares your dependencies in a single place, instead of littering constants throughout your code.
- We have sub-applications called Slices. Similar to Rails Engines but well... good, since they're a first-class concept that we encourage. Importantly, they're independently deployable. You can export and import components across slices, too. We can't tell you how to slice up your application, but we give you the tools to decide for yourself.
A long time ago I had a "Component Based Rails Application (CBRA)" using engines as the domain boundary. It was unpleasant because it just moved pain points into unfamiliar places. The slices approach is very interesting.
Overall I like dry-rb.
If I find myself on a ruby project again I will investigate more thoroughly!
Taking a workshop at Rocky Mountain Ruby on "Component Based Rails Applications" with Stephan Hagemann (the author of that book) was my introduction to all of this stuff! I found Hanami (then called Lotus) shortly after and I never looked back.
I tried out Rails Engines on a couple projects, with such high hopes and ran into issue after issue. Sure it's theoretically possible to build whatever you want with Rails, but in practice it's infeasible. Some people have experimented with arbitrarily nesting Hanami slices too and had success. It's not something we're focusing efforts on because it's rather niche and get inherently complicated but it's possible.
Modularity is such an important part of large software projects and Rails doesn't give you any tools for it (and Ruby doesn't help either). Packwerk was an attempt to constraint Rails, with limited success: https://shopify.engineering/a-packwerk-retrospective.
Small world! We were one of the clients at labs he tested that concept with while developing the book. Chatted with him about his newer book using packwerk a couple years back. Looks like we’re all on the front range!
Agree on the engines, you’re just fighting the framework the whole way.
Coincidentally working on modularity approaches for a different type of monolith https://viaduct.airbnb.tech/ (time is a flat circle etc. etc.)
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!
Hanami doesn't have any specific Inertia or Svelte specific integrations, but our view layer (and assets layer) is very flexible so it's certainly possible. It's worth investigating. If you try it out, let us know what you learn on our forum https://discourse.hanakai.org/
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 :-(
Hanami's DB layer was completely rewritten for Hanami 2 (based on Rom, and we've since merged teams), so you should try doing these again!
Rom has some other advantages, like not needing a 1-to-1 mapping between tables/columns to models/attributes. For example, you could have a `users` table that maps to Profile and Account structs. Profile could include a `bio` whereas Account version could have the email, ensuring data doesn't leak beyond what's needed. They're two different use-cases for the same data, so should be modeled separately. This also lets you work with DB's where you don't control the schema (owned by other teams or legacy DB's): you can map the data into the structure you need for your app, instead of carrying around irrelevant attributes.
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!
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.
Definitely on the roadmap! I've also run into some rough edges with Rom and we want to fix those all up in a new version. We were just prioritizing Hanami 3 for the medium term, but hopefully we can focus efforts on Rom soon.
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.
That statement means nothing. You could say the exact same thing about Rails and have an equally defensible position. What about its architecture makes it better?
It is not, Hanami is a batteries-included framework. It not even a pay-as-you-go framework like Pyramid. The equivalent of Flask in Ruby land is Roda+Sequel.
Completely agree! I did most of this work and I wanted to add before-and-after benchmarking but I got busy. I have an in-progress (private for now) implementation of the Medium clone RealWorld [1] project. I want to make that public with some benchmarks, then write up a modern implementation in Rails so we can compare performance. It will also help people compare our code side-by-side, to translate concepts they know from Rails into our approach in Hanami.
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.
Hanami follows very good design patterns, useful for bigger applications. You may not see the value immediately with simple 5 minute blog app but over time, when the app grows, the abstraction layers will pay off.
Sorry to hear about that. We definitely can't protect developers from themselves. Over-engineering is definitely a risk to be aware of and guarded against. We provide powerful tools that can help your codebase, but they can also be misused.
I'm confident you've also ran into large messy Rails apps too :)
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.
Hanami core team-member here :)
We re-did our homepage recently, and we should make these things clearer. They're legitimate concerns and questions. We agree you don't have to write bad code in Rails, and we don't pretend that we can prevent bad code in Hanami. Instead we give application builders the tools to architect their applications in the way they desire. Really what we're doing is building an *option* for building Ruby apps that may speak better to some people. If you're completely happy with Rails then there's no reason to change. Still, you may learn something that'll help you build Rails apps by seeing how we do things. Additionally, it's completely modular: you can pull parts of Hanami into a Rails app. The most popular one people pull into Rails apps is dry-validation [1]
Some concrete differences:
- We have small, simple API's. Rails core classes have hundreds of methods for convenience, not to mention dozens of core extensions (a.k.a. monkey patches) to base Ruby classes. We prefer small, narrowly focused classes over large ones with many responsibilities.
- We have a dependency injection framework dry-system [2] included by default. This lets you write `include Deps["repos.article_repo"] to get an automatically instantiated (and now memoized!) `Repos::ArticleRepo.new` within your class. This makes dependencies trivial to stub out, and it also declares your dependencies in a single place, instead of littering constants throughout your code.
- We have sub-applications called Slices. Similar to Rails Engines but well... good, since they're a first-class concept that we encourage. Importantly, they're independently deployable. You can export and import components across slices, too. We can't tell you how to slice up your application, but we give you the tools to decide for yourself.
[1]: https://hanakai.org/learn/dry/dry-validation
[2]: https://hanakai.org/learn/dry/dry-system
Thank you for the thorough reply!
A long time ago I had a "Component Based Rails Application (CBRA)" using engines as the domain boundary. It was unpleasant because it just moved pain points into unfamiliar places. The slices approach is very interesting.
Overall I like dry-rb.
If I find myself on a ruby project again I will investigate more thoroughly!
Taking a workshop at Rocky Mountain Ruby on "Component Based Rails Applications" with Stephan Hagemann (the author of that book) was my introduction to all of this stuff! I found Hanami (then called Lotus) shortly after and I never looked back.
I tried out Rails Engines on a couple projects, with such high hopes and ran into issue after issue. Sure it's theoretically possible to build whatever you want with Rails, but in practice it's infeasible. Some people have experimented with arbitrarily nesting Hanami slices too and had success. It's not something we're focusing efforts on because it's rather niche and get inherently complicated but it's possible.
Modularity is such an important part of large software projects and Rails doesn't give you any tools for it (and Ruby doesn't help either). Packwerk was an attempt to constraint Rails, with limited success: https://shopify.engineering/a-packwerk-retrospective.
Small world! We were one of the clients at labs he tested that concept with while developing the book. Chatted with him about his newer book using packwerk a couple years back. Looks like we’re all on the front range!
Agree on the engines, you’re just fighting the framework the whole way.
Coincidentally working on modularity approaches for a different type of monolith https://viaduct.airbnb.tech/ (time is a flat circle etc. etc.)
Big congrats on the release!
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!
Thanks!
Hanami doesn't have any specific Inertia or Svelte specific integrations, but our view layer (and assets layer) is very flexible so it's certainly possible. It's worth investigating. If you try it out, let us know what you learn on our forum https://discourse.hanakai.org/
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 :-(
Hanami's DB layer was completely rewritten for Hanami 2 (based on Rom, and we've since merged teams), so you should try doing these again!
Rom has some other advantages, like not needing a 1-to-1 mapping between tables/columns to models/attributes. For example, you could have a `users` table that maps to Profile and Account structs. Profile could include a `bio` whereas Account version could have the email, ensuring data doesn't leak beyond what's needed. They're two different use-cases for the same data, so should be modeled separately. This also lets you work with DB's where you don't control the schema (owned by other teams or legacy DB's): you can map the data into the structure you need for your app, instead of carrying around irrelevant attributes.
Is this still the case? I was able to find only one fresh comparison, and in it they show approximate parity, with Hanami being slightly faster.
https://web-frameworks-benchmark.netlify.app/result?asc=0&f=...
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!
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.
Definitely on the roadmap! I've also run into some rough edges with Rom and we want to fix those all up in a new version. We were just prioritizing Hanami 3 for the medium term, but hopefully we can focus efforts on Rom soon.
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.
What Hanami brings is an intentional and well-reasoned architecture that supports building maintainable applications. It has taste.
That statement means nothing. You could say the exact same thing about Rails and have an equally defensible position. What about its architecture makes it better?
You could not.
“Nuh uh” Isn’t a good rebuttal.
How about some examples comparing where a solution in Hanami is “tasteful” while the same solution in Rails is “not tasteful”?
What? This doesnt mean anything
This says more bout you than me.
Yikes
It's basically the flask/fastapi but for ruby, compared to django/rails. It has it's purpose if you want to stay in ruby land
It is not, Hanami is a batteries-included framework. It not even a pay-as-you-go framework like Pyramid. The equivalent of Flask in Ruby land is Roda+Sequel.
It'd be nice to see some benchmarks to compare the before vs after on the perf gains in the Faster by default heading.
Love the work though; having beautifully crafted options like Hanami around is a joy.
Completely agree! I did most of this work and I wanted to add before-and-after benchmarking but I got busy. I have an in-progress (private for now) implementation of the Medium clone RealWorld [1] project. I want to make that public with some benchmarks, then write up a modern implementation in Rails so we can compare performance. It will also help people compare our code side-by-side, to translate concepts they know from Rails into our approach in Hanami.
[1]: https://github.com/realworld-apps/realworld
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.
I had the complete opposite experience.
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.
Hanami follows very good design patterns, useful for bigger applications. You may not see the value immediately with simple 5 minute blog app but over time, when the app grows, the abstraction layers will pay off.
Sorry to hear about that. We definitely can't protect developers from themselves. Over-engineering is definitely a risk to be aware of and guarded against. We provide powerful tools that can help your codebase, but they can also be misused.
I'm confident you've also ran into large messy Rails apps too :)
Great web design.
[flagged]