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

▲

pclowes an hour ago | parent [-]

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!

	▲	cllns_ruby an hour ago \| parent [-]
		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.