[poszlem]

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.

[cllns_ruby]

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 :)

[shoqr]

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.