21–30 of 32 posts
I'm happy someone's challenging the Rails almost-monoculture in the Ruby ecosystem, but Hanami doesn't seem to bring much to the table. Is there anything in this release that Rails hasn't had for years?
It's basically the flask/fastapi but for ruby, compared to django/rails. It has it's purpose if you want to stay in ruby land
Earlier quoted context omitted.
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 bui…
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!
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.
many years ago when Hanami was just getting popular I remember doing benchmarks against Rails when it comes to SQL and was unpleasantly surprised when Rails' ActiveRecord ended up being much faster, despite "speed" being advertised as one of the advantages :-(
https://web-frameworks-benchmark.netlify.app/result?asc=0&f=...
many years ago when Hanami was just getting popular I remember doing benchmarks against Rails when it comes to SQL and was unpleasantly surprised when Rails' ActiveRecord ended up being much faster, despite "speed" being advertised as one of the advantages :-(
Rom has some other advantages, like not needing a 1-to-1 mapping between tables/columns to models/attributes. For example, you could have a `users` table that maps to Profile and Account structs. Profile could include a `bio` whereas Account version could have the email, ensuring data doesn't leak beyond what's needed. They're two different use-cases for the same data, so should be modeled separately. This also lets you work with DB's where you don't control the schema (owned by other teams or legacy DB's): you can map the data into the structure you need for your app, instead of carrying around irrelevant attributes.
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…
I'm confident you've also ran into large messy Rails apps too :)
Earlier quoted context omitted.
That statement means nothing. You could say the exact same thing about Rails and have an equally defensible position. What about its architecture makes it better?
You could not.
How about some examples comparing where a solution in Hanami is “tasteful” while the same solution in Rails is “not tasteful”?
Earlier quoted context omitted.
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!
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, bu…
Agree on the engines, you’re just fighting the framework the whole way.
Coincidentally working on modularity approaches for a different type of monolith https://viaduct.airbnb.tech/ (time is a flat circle etc. etc.)
I'm happy someone's challenging the Rails almost-monoculture in the Ruby ecosystem, but Hanami doesn't seem to bring much to the table. Is there anything in this release that Rails hasn't had for years?