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 "dryness" I really do like the structure though with repositories for data.
Overall I think the focus with clean syntax/DSLs in Ruby projects with pervasive metaprogramming is one of the reasons the code is so hard to maintain.
Overall I think the focus with clean syntax/DSLs
in Ruby projects with pervasive metaprogramming
is one of the reasons the code is so hard to maintain.
I don't have any opinion on Hanami and don't want to bring any negativity to the Hanami 2.0 party. Congrats to the team on this release!
However, in general, I wholeheartedly agree with your statement. Sometimes Ruby frameworks get way too cute with the metaprogramming.
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
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.
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.
Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
Contributions to Hanami components would be appreciated for sure! There is a whole persistence and views integration to be done fir 2.1 release! The core team will not rest for too long after 2.0 being out :D
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.
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 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.
Maybe the maintainers are nice and release patch versions for older major releases. I don'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.
I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" 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.
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.
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.
Hanami 2.0 is almost completely rewrite in it's core from 1.3, and it took over 3 years. I could not imagine companies relying on owned frameworks - maintaining it, documenting it, educating people to work with them - it's just too expensive.
The ruby community is able to do it by having a rigorous set of defaults. When you look at the ecosystem there is far more inter compatibility than say JavaScript/ npm because there are robust norms.
The obsession with magic is actually more an obsession on developer speed and ease because that is the biggest cost and driver of software. The magic also promotes following well tested patterns.
You seem to be advocating a dependency free path where the developer builds everything from scratch. Totally a valid approach but at the cost of development speed and ease. It also results loss of the collective knowledge of a community.
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.
I hope I can have some time in the near future to use Hanami in a real world project.
Looks like the new 2.0 guides doesn'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?
Yes the view layer will be introduced in 2.1. We have hanami-view ready but we need to build hanami-assets and hanami-helpers + add integration code to the main hanami gem.
For me it's a shame that they doubled down on the "interactors" (which are now called operations?) pattern. I really like the containers system from `dry-rb` and overall how the routing/controller system works. I like the concept of multiple apps and slices as first class citizens.
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.
Most of these complaints are, of course, not inherently the fault of these commands/operations/interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.
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.
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/ folder should be loaded into Deps instead (Deps["slack_notifier"] ?
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
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 ?
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.
Hanami aims to be a complete Ruby framework, allowing you to write web apps, but also gems, and non-web ruby applications. Hanami 2.0 only ships for API focus, but in next minor versions this is going to be extended. I see it as a direct alrernative to Rails for anyone who would like to try different style of programming while still using Ruby.
Overall I think the focus with clean syntax/DSLs in Ruby projects with pervasive metaprogramming is one of the reasons the code is so hard to maintain.