Anyone who knows how this is different from Sinatra and Roda?
They seem to be the other two "micro frameworks" (with Rails obviously being the primary Ruby framework).
Hanami 2.0
21–30 of 50 posts
Re: Hanami 2.0
#22It 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 "dryness" I really do like…
What you're describing should've been reported as a bug because we do use metaprogramming for DSLs but the "runtime" objects are actually designed to have very minimalistic public API. I can assure you we do not put clean syntax above all else but we do like clean DSLs that reduce boilerplate
Re: Hanami 2.0
#23Framework-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. 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't adopted the new version of Zeitwerk, you may…
You're right in principle but not in this case. Zeitwerk is not a regular dependency, it's stable and the risk it will change in an incompatible way is very minimal (reminder - it's used by Rails too). When it comes to dry-rb as deps - dry-rb core team == hanami core team. This means we are on top of the things and we'll ensure that things are evolving together w/o breaking anything.
Re: Hanami 2.0
#24def call(name:, email_address:) email_client.deliver( to: email_address, subject: "Welcome!", text_body: welcome_email.render_text(name: name), html_body: welcome_email.render_html(name: name) ) SlackNotifier.notify("Welcome email sent to #{email_address}") end This code is bad. 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/ fold…
You missed the context of this example - it's just there to show that IF you don't want to use constructor DI, you can put things in lib and they won't become part of the automatic DI system
Re: Hanami 2.0
#25Earlier quoted context omitted.
Hanami 2.0 doesn’t have any interactors
Oh, I saw an example with `app/operations` and assumed they were just renamed. Guess that changes everything for me. Will definitely give it a try.
Haha no it's just an example of a custom directory that you can place under app dir We're still thinking about an abstraction for operation-like objects (I actually started experimenting with this a couple of months ago) but I don't think it will become part of the main Hanami stack.
Re: Hanami 2.0
#26Anyone who knows how this is different from Sinatra and Roda? They seem to be the other two "micro frameworks" (with Rails obviously being the primary Ruby framework).
Hanami is not a micro-framework, it is composed of multiple gems though, so if you remove them all you're left with a core of the framework that doesn't do anything except providing an API for plugging in components, configuring them and managing their state.
When it comes to differences - Sinatra is not as feature rich and it's got a less powerful plugin system. Roda has a completely different router using so called Routing Tree, which Hanami doesn't have (it's got something more akin to what Rails has) but it's also highly extendible through plugins, so there is similarity there. A huge difference is that Hanami ships with a very powerful code loading system that supports automatic dependency injection mechanism.
Re: Hanami 2.0
#27def call(name:, email_address:) email_client.deliver( to: email_address, subject: "Welcome!", text_body: welcome_email.render_text(name: name), html_body: welcome_email.render_html(name: name) ) SlackNotifier.notify("Welcome email sent to #{email_address}") end This code is bad. 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/ fold…
You missed the context of this example - it's just there to show that IF you don't want to use constructor DI, you can put things in lib and they won't become part of the automatic DI system
The point here, is, let's code in production.
No good production code allows such things to accidentially happen, so to me, it's the error from framework. What's the point of using a framework if it couldn't help me do silly things then ?
Re: Hanami 2.0
#28I 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.
I wrote a wrapper that handles/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.
Will see how the migration goes...
Grats to 2.0 and kudos to the hanami guys! Great software.
Re: Hanami 2.0
#29[deleted]
Re: Hanami 2.0
#30Framework-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. 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't adopted the new version of Zeitwerk, you may…
This is the sort of cargo-culty FUD criticism people often bring up about Rails. So many programmers would rather reinvent the wheel, badly, than learn how to use existing products and focusing on their USPs.
What would your successor prefer when they take over: Bob's ad-hoc framework built from the ground up where they don't know how anything works, or some app implemented on top of a framework they've used in 10 other jobs?
While I agree that using frameworks like rails/django/hanami/react has an upfront cost, it's so hard to justify doing your own thing if your usecase is fits within what they offer.