Hanami 2.0

It looks clean because the developers are also the people behind dry-rb. However, I made one production service in Hanami and never again. They put clean syntax above all else. This results in a TON of metaprogramming with very weird results. There were times when a variable name I was using in my code was conflicting with a method called in one of the many `instance_evals` to achieve such &quot;dryness&quot; I really do like the structure though with repositories for data.<p>Overall I think the focus with clean syntax&#x2F;DSLs in Ruby projects with pervasive metaprogramming is one of the reasons the code is so hard to maintain.

I come from ramaze (very old, not maintained, very simple), used rails for work (and was never a big fan) and use hanami for a couple of years now.<p>I wrote a wrapper that handles&#x2F;maintains multiple hanami apps and makes plugin usage easy with multiple projects I use them in. Everything gets deployable with capistrano. I run a few sites with more or less complex features and quite happy with it.<p>Will see how the migration goes...<p>Grats to 2.0 and kudos to the hanami guys! Great software.

Looks really nice. Makes me wish I worked in Ruby, a little.

Framework-style libraries (i.e. Hanami) pulling in other framework-style libraries (i.e. dry-rb) which themselves pull in other framework-style libraries (i.e. Zeitwerk) is asking for a whole lot of trouble.<p>If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn&#x27;t adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.<p>Maybe the maintainers are nice and release patch versions for older major releases. I don&#x27;t know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.<p>I don&#x27;t understand the Rubyist obsession with having a whole bunch of magic stuff just &quot;happen&quot; in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.

This is great!<p>I love Rails but have used Sinatra and Padrino in the past. The knowledge you get using these frameworks can sometimes be brought back to your Rails apps to improve some things.<p>I hope I can have some time in the near future to use Hanami in a real world project.<p>Congratulations to the team.

dry is a neat framework. It also works with rails. [0]<p>0. <a href="https:&#x2F;&#x2F;dry-rb.org&#x2F;gems&#x2F;dry-rails" rel="nofollow">https:&#x2F;&#x2F;dry-rb.org&#x2F;gems&#x2F;dry-rails</a><p>I&#x27;m sad that the trailblazer stack went so commercial as to be FOSS-hostile and unusable.

Looks like the new 2.0 guides doesn&#x27;t have anything regarding views and templates yet. Is that a documentation gap or is it like some of the closer ROM integration, where it will be 2.1 where that is functionally fleshed out?

For me it&#x27;s a shame that they doubled down on the &quot;interactors&quot; (which are now called operations?) pattern. I really like the containers system from `dry-rb` and overall how the routing&#x2F;controller system works. I like the concept of multiple apps and slices as first class citizens.<p>But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logic lost inside of these procedures and almost no POROs in sight.<p>Most of these complaints are, of course, not inherently the fault of these commands&#x2F;operations&#x2F;interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.

def call(name:, email_address:) email_client.deliver( to: email_address, subject: &quot;Welcome!&quot;, text_body: welcome_email.render_text(name: name), html_body: welcome_email.render_html(name: name) )<p><pre><code> SlackNotifier.notify(&quot;Welcome email sent to #{email_address}&quot;) end </code></pre> This code is bad.<p>If you want Hanami to be an IoC framework, why still allow direct SlackNotifier to be injected to the action layer here ? I guess, lib&#x2F; folder should be loaded into Deps instead (Deps[&quot;slack_notifier&quot;] ?

Anyone who knows how this is different from Sinatra and Roda?<p>They seem to be the other two &quot;micro frameworks&quot; (with Rails obviously being the primary Ruby framework).

looks pretty good, congrats to the team.

Is...?