Rendered at 22:08:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pclowes 2 hours ago [-]
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.
cllns_ruby 4 minutes ago [-]
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 is [dry-validation](https://hanakai.org/learn/dry/dry-validation/v1.11).
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 (via [dry-system](https://hanakai.org/learn/dry/dry-system)) 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.
swe_dima 2 hours ago [-]
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 :-(
itsdesmond 4 hours ago [-]
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.
paozac 4 hours 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?
neko_ranger 26 minutes ago [-]
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
itsdesmond 3 hours ago [-]
What Hanami brings is an intentional and well-reasoned architecture that supports building maintainable applications. It has taste.
choilive 2 hours ago [-]
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?
itsdesmond 54 minutes ago [-]
You could not.
jatora 1 hours ago [-]
What? This doesnt mean anything
itsdesmond 53 minutes ago [-]
This says more bout you than me.
xswhiskey 4 hours ago [-]
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.
cllns_ruby 1 minutes ago [-]
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](https://github.com/realworld-apps/realworld)" 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 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 is [dry-validation](https://hanakai.org/learn/dry/dry-validation/v1.11).
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 (via [dry-system](https://hanakai.org/learn/dry/dry-system)) 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.
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.
Love the work though; having beautifully crafted options like Hanami around is a joy.