Table of Contents
- Background and motivation for this
- AppSignal article and frameworks introductions
- Hanami target audience
- Real Hanami vs Rails
- Business side of it
- Conclusion
Background and motivation
Not so long ago, I've seen an article, featured on (I think) RubyWeekly. It came from AppSignal, a company whose products I respect, and the title immediately grabbed my attention due to the fact it was about Hanami. A subject that has lately been close to me.
I've written some articles about it, programmed some side project in it in the last 6 months. I am also actively trying to contribute to community on bug hunt, documentation, trying to answer some discourse questions or post my own, when they seem validated. In general I really want to help hanami contributors out, cause I really appreciate and value their work. Open source is a hard piece of bread and doing it well is impossible. You can never please everyone when you get paid, so doing it for free is ever more of a delusional idea. Open source projects always make some sacrifices, either in their quality, or the developers personal life. It's a hard job, and I respect it. Specially when it results in admirable software, that I think Hanami is.
To go back to the article - it was not to my liking and I think it only scratched the surface and with some statements, missed some crucial information. It was also very short for a rather big subject. It is a 5 minute read, maybe less. 5 minute to decide on what web framework to use when starting a new project/job? Might be okey when working with pet projects, but not professionally. You need more of a deep dive. I am here to provide a bit more context, expand or correct, and give you my own view.
So please, bear with me, cause this article is a bit longer, but I think it's worth it. I will try to give you a better insight into Hanami, and why you should consider it for your next project.
There is also Table of Contents, as I do not expect you to take it all in one go.
AppSignal article and introductions
As a starter I want to make sure I am not taken the wrong way. This is not an "attack" on the article or its author. I still think it is a valuable write-up by Aestimo Kirina and he did an overall good job with it. But I just think there is more to the subject. Much more, and given the work put in into both Rails and Hanami, authors and contributors to both, deserve a more thorough analysis. They have put a lot of thought into the design of their frameworks, and that is not explored well enough in the article to stay fair to the work put into this software.
Article presents 6 main parts, and a quick introduction to both framework, with some closing thoughts at the end. I will follow this structure and expand on all.
As for the introduction to both frameworks. We all know what Rails is. At the same time, our definitions and understandings of it may differ, sometimes even vastly. There was a time where I thought that none truly follow the pure Rails-way. Writing big models and skinny controllers (or the other way around by some), with callbacks, expansive helpers and logic in the views, split across dozens of partials, just seemed impossible in a big, complex project. But sure enough I have seen projects like this, worked on them, rewrote them, spoke with people that write like this and were happy about it. They were getting paid, often handsomely, and their clients/employees were happy with them.
So I thought "am I the classic example of an overthinking, overengineering developer?".
Maybe I am, but then again, I mostly met people who don't write Rails like this. They follow DDD, they use design patterns they picked up from schools, articles, books, other projects, other languages and frameworks. I've worked on about 20 projects professionally to date, add some minor consulting, code review, open source. I've seen a lot of approaches to Rails, and most of them were valid.
That is the thing with Rails. It is easy. It really is. Ruby is easy. And there is nothing wrong with that.
Because both the language and the framework are easy, it is also easy to modify them, bend them to your needs or likings. So many different apps are built with Rails, but even when you find two that are really similar in their business approach, they might be completely different in how they are built from technological perspective. I do not see this being said too much over the internet, but it really is the case. Rails is flexible. People keep repeating that Rails is/has:
- Dry
- Convention over configuration
- Big community
And so on so on, you know the stick. But this is all you can read in the documentation or any basic tutorial. What the reality is, is that Rails is hugely popular. It has been adopted by multiple programmers and companies. They each brought their own knowledge, ideas and experience to Rails and bend it to their needs. This is why Rails can mean so many different things to different people. I often make assumptions about RoR development based on my approach and then become surprised when I meet someone who has no idea what I am talking about.
This is what I am missing when people compare Rails to other frameworks. RoR is never the same one thing. I doubt any framework is.
But people like to make assumptions. They like to simplify things so that they don't question their own knowledge. They like to be right. And they like to be right fast. So they make assumptions. And they are often wrong.
Some devs liked to make fun of RoR for not scaling or being slow, and just ignore the fact that systems like GitHub or Shopify or AirBnB exists and use RoR.
So what are the Hanami assumptions? Taken from the AppSignal article would be:
- small memory footprint
- focus on modularity
- fast and nimble
In general, they are quite true. Hanami is fast and it is modular and composable. It sure is fast (to run).
But it is a quick introduction the author made, later on delving into some details to drive the same points home. At the end of this article I will present my own understanding of what Hanami is, and if you read the whole thing I really hope and think, you will see my main point clearly.
After all, you are a programmer. You are very smart.
Structure and Architecture of Rails and Hanami
The author of the article makes a few seemingly minor mistakes in presenting the structure of hanami. The regular Rails structure that is given is obviously correct, but he makes an assumption about Hanami.
As of now, Hanami 2.1 has no persistence layer. Main page has a guide how to add it though, using ROM-rb. Also the new (added in 2.1) view layer is optional.
First of, you could say the same thing about Rails, well at least the view layer being optional in API apps. I would assume there aren't many RoR apps without persistence. You can set up a new rails app without ActiveModel, but by default it is built in. Hanami has it the other way around. You want persistence? Add it yourself. It is planned to be added in 2.2 but for now, you are on your own.
What does that really mean and why is it a big deal?
Remember what I said about Rails? How pretty much every programmer can have a different approach? Convention over configuration is a mantra for Rails, but people forget, that there are different conventions. Adding persistence layer is a big thing, a lot of configuration and it has to follow a certain convention, right? Right now there is no convention and configuration is up to you. Hanami does that a lot. It is a big difference between the two frameworks. Hanami will have you configuring stuff more, and you can't count on existing conventions as much as in Rails, which has a gem for almost everything. Everything has been tried in Rails, so someone, somewhere presented their convention about implementing certain feature/tech in Rails, you can steal it/let it inspire it. In Hanami, you are sort of on your own (unless you try the discourse forum).
In general Rails does not really enforce too much, hanami does. In this case hanami enforces you to configure stuff on your own. We will explore more things it does enforce later on.
But for now lets think more about the structure and architecture. If you follow the other article, or know anything about RoR or Hanami, you know that both use the MVC pattern. But with Rails, it mostly comes down to "fat models, skinny controllers", so controllers end up delegating actions to models and some custom objects, like service objects and what not. I would call this flat MVC. It is surface level. It takes all the letters from MVC, assigns them one object/thing and calls it a day. There goes your convention, now build us a new facebook.
What Hanami offers is full MVC, with far more collaborators to assign responsibilities: real view objects, slices, providers, initializable actions. This is an important thing it enforces. A more thorough, thought-out separation of responsibilities in the MVC pattern. Controller does not mean one file that does all routes for a given scope. It means separate actions, with possibly quite different responsibilities, implementations, scope of actions, routing rules, authorization and so on. Model means what you make of it, but if you follow the recommended approach with ROM it means full on repository patterns, with entities, relations, commands, validations, mappers separation with multiple adapters.
And finally views means actual view objects, much faster than partials, with clear exposures, inputs, outputs, that are composable, DRY, can have different contexts, are easily rendered outside of actions, have clear dependencies etc.
Hanami expands on MVC greatly compared to Rails, yet it remains flexible as much as Rails is, if not more. That is truly admirable to me.
This is the something I was missing in the AppSignal article and that bothered me deeply. MVC pattern is just scratched by Rails, and carefully adapted by Hanami. Both approaches are fine. You build stuff faster in Rails, so a bare-bones approach makes sense. You build stuff slowly and methodically in Hanami, so a more thorough approach makes sense.
Ecosystem and Community
Author mentions that Hanami is relatively new. This is somewhat true, although under the name of Lotus, Hanami has been around for around 9 years. However it went through many changes, and recently the original creator, has departed from the core team and is no longer working on Hanami. This might be seen as a big blow to the community and framework itself, but seeing the wonderful work and efforts of Tim Riley I am quite hopeful for the future of Hanami.
Anyway my main problem with this point in the article is the documentation mention. I often do not like rails documentation. It is very vast, but not split up too well. ActiveStorage especially has a tangled mess of documentation. Hanami documentation also has it's own problems, specially with the search and version splitting, but at least it is split up well, and gets straight to the point with the description of different features.
However, the author is right, saying that if you are looking for something specific in Rails ecosystem, a simple google search will probably get you there. The quality of those solutions is your to verify, but it is hard to come up with a problem that does not have some sort of solution in Rails.
AI thinks RoR devs are happy artists. Most of them are happy, but remember that most artists are prostitutes.
There is really no comparison here. RoR has a monopoly on ruby world. This will not change, ever. Hanami will exist in the shadows, but its Lotus tree will cast its own shadow, and in it, its developers will hide from the burning sun that RoR can be. Smaller community, means higher chance of meeting someone and actually connecting. Hanami being a framework for an advanced, mature developer means community has a bigger ratio of people who you can learn from. It means less content, but more catered, and curated by people who actually use it.
In terms of ecosystem... well Rails has so many, many gems. It is ridiculous how many things people have built for it. It is also amazing. Hanami only has a small slice of that, and a lot of gems are outdated, do not work with hanami 2.x. However it is also a system that encourages DIY approach, and some things do not make sense as a separate gem. If you want a bunch of ready solutions, you will not even consider Hanami, not just based on gems or not, but based on its approach to development. Rails is fast. Rails is fast to write and run. Hanami is fast to run. You can write Hanami fast if you master it, sure, but you can also quickly write bad Rails code. Hanami makes it way harder to write bad code, makes it harder to add a gem, that later shows it true colors and breaks, or does not meet expectations, gets in the way, is limited etc. Code that is written fast is always more prone to breaking than the code that was written slowly and methodically.
If you ever used dry-rb gems, Hanami is in a big part based on them. They handle most backend problems in a way that takes the best of both worlds of functional and object oriented programming. They are not easy to learn, but they are very powerful. Some of them have a steep learning curve, but the code you produce with them is just awesome. Hanami is not a framework for beginners. It is a framework for people who want to learn, who want to be better, who want to build better software, but are already mature enough, or spent enough time with other systems, to know they need that change, that they need to make things harder for themselves, to be better and do better work. It is a framework for people who want to be proud of their work. Rails can be that too, but it will sometimes make it more difficult to do your best. Rails makes it easy to take the easy way out, take some shortcuts.
Ease of Use, Adoption, Governance, and Learning Curve
AppSignal article makes a good, quick point about Learning and as I mentioned above, Hanami is not for beginners. It is more more mature programmers, who want to learn. Rails is awesome for beginners and seniors alike.
Industry adoption is also not a real comparison, Rails dominates ruby world, and has been adopted by some huge companies and products. There are also no job postings in hanami. From my scouting in the community it appears that every company using hanami is a product company with a senior developer team, who made the decision themselves. None really looks for a hanami developer.
But all that is very obvious and does not need an article.
Governance on the other hand is a whole different beast. Article shows an example of DHH announcement from January that has half a million views. It is an exciting announcement and it is really nice seeing DHH so motivated. He has build something great along with many awesome people, and his undying dedication is admirable. Rails is however far from having a bus problem. If DHH has a change of heart, or (god forbid) something happens to him, Rails will still be here, alive and well, although sad. It is a huge project, with a lot of people working on it, and a lot of people using it. It is a huge part of the ruby community, and it will not go away.
What about Hanami? As I mentioned Luca left, the DHH of Hanami world has left. For now the project is alive, but there are no big companies using hanami, no GitHub or AirBnB, no Shopify. If in few years, Tim Riley leaves will there be someone to pick up the torch? If you look at the team page of Hanami, it is only a handful of people, and as of late, only Tim is truly active in the community and github issues etc.
This is a guessing game however. Both projects are open source, none can really tell where they will go and I don't want to speculate. I hope both projects thrive and its authors can find balance in maintaining it and having a life.
Performance: Ruby on Rails vs. Hanami
Now, the article shows a simple comparison. Hanami is 3x faster in average latency and handles 3x more request. In fact, hanami speed is really hard to beat in ruby's world. That is really impressive.
And it does not really matter.
My boss had an article that touches on the subject of benchmarks from a business perspective. People try to sell their thing on speed. Not just in ruby world, where people are a bit butt-hurt about programmers from other languages saying that ruby is slow.
I want to expand on what my boss said.
Starting off with an example:
Koenigsegg Jesko Absolut is supposed to be the fastest car in the world. With 1600 horse power, it reaches the speed of 531 km/h (330 mph). Sound barrier is broken at 767 mph. That car is really, really fast, no doubt about it.
Hanami request handling if it was a car
My car is a 2013 Suzuki SX4. It was bumped twice, while I left it in a parking lot. One of those left a somewhat significant scratch mark and a dent on the right side of the car. Second time, someone scratched the area above the right wheel in the back. And this other time, I borrowed the car to my dad on a cold, slippery Polish winter and he bumped it too. It still has a visible scratch mark over the left wheel in the back. None of those was fixed and in general the fastest I drove it was like 150 km/h.
But you know what? In any city, and in any country road or intercity road, I will take my Suzuki over that ugly monstrosity. Chance is, in the city I would be faster at my destination, than the angriest Koenigsegg Jesko Absolut driver, cause no doubt he would have an accident or would not make it on polish sharp, tight turns.
Rails request handling if it was a car
There are cases where I would pick Jesko, but they are sparse.
Why? Faster means better right? Well if you are a half-decent driver, you know that is not true. If you drive around the city, you know that speed is not the most important thing. You want a car that handles well, that is good at taking tight turns, that is easy to park, brakes well, and does not burn a lot of fuel when constantly stopping and starting at lights. Suzuki SX4 is a good car for that, and in 6 years, I only had 1 major repair.
What does it has to do with hanami and rails speed? That speed barely matters. Even if hanami router handles the request 3x faster, if we have a big, ugly query written in ROM, cause we don't know how to use it well, we will present a response slowly to the client. In comparison if we do the same in Rails, which we know, and we know how to use a query on ActiveModel, we will present the response to the client much faster than on hanami. On top of that we will write it much faster. No extra, new repository methods, no separate action and route generation.
Does request speed mean anything to your client? In a sales pitch, maybe. But while you are pressed for time to fix a bug, add new feature? You know the answer to that.
So in general, if ruby is slow, you made it so. Yes there are faster alternatives to Rails and Ruby, but when you see a benchmark comparison, always try to look at a bigger picture. So you know, when someone keeps spouting some benchmarks they made, just...
forgetabutit.jpg)
The speed of the tool you have in your hands is relative to your skill, environment and task you use it for. This is true both for and software. Your car goes max speed of 200mph? Awesome, city limit is 30, and many cities have photo-radars on every streetlights on streets that allow you to hit the gas for more than 1 second.
What's that? You reach 100 km/h in 2 seconds? Nice, the only roads with a road straight enough to do full gas for 2 seconds, have streetlights that turn red when they detect someone speeding. Good luck passing them without hitting someone. My car does not even allow me to break certain speed limits.
If you can't think of how all this translated to software development, you probably haven't been burned by the reality of modern software development or you don't drive in the city. Speed rarely comes first in RoR development. First you make it work, then you refactor it, make it fast and reliable, bug free. If your framework handles request super fast - great, but it won't matter if you write a bad, slow query, or use a bad views structure, write too much logic in it, render too many partials etc. Request handling speed itself won't save you from the responsibility of writing fast code, just like having a fast car, won't make you suddenly take less time to get to work, from one end of the city to another, at rush hour.
And yes, even though rails partials are slow, and hanami-views are much faster, all the points I made above still stand.
Testing
In the article, this is the worst part for me, since author barely touched on the subject. First off, a few things:
- Hanami comes with rspec built in (rails does not, it uses MIniTest)
- Hanami does not come with persistence layer built in, so factory bot without persistence layer will be useless
- If you use ROM, you won't be able to use factory bot, instead there is rom factory
- Hanami makes is super easy to test actions as unit specs, since each action is easy to initialize, rails controllers are a pain to initialize, and controller specs are full of magic (and are discouraged nowadays)
- Hanami makes it easier to have truly unit tests, with clear, or no dependencies
- You can use any testing framework with both frameworks
- You can use any testing approach with both frameworks
- You can write integration specs or not in both frameworks
What the author misses in this section is that this comparison is useless. Ruby community and RoR community, do not have one approach to testing. There are multiple approaches and tools to use, and both framework have their own defaults, but projects often follow their own rules.
Hanami makes it easier to create a very clear unit specs, that are truly unit specs. Rails makes it a bit harder, cause it has way, way more coupling. Rails has a big global scope, many things are tangled up with models or controllers, and you often cannot test something without them, even if they are, from design perspective, unrelated. If you tried for example rendering a view without controller context, you might know what I mean (using turbo makes it possible, but rails often comes in the way).
In general testing comes down to test framework you choose. RSpec in hanami and RSpec in rails, will result in somewhat similar test suites, depending on how much you customize it for your project. Framework determines what you test, but not exactly how. This depends on you, and Hanami, as I think we established, is better at entrusting more stuff to developers, where Rails relies more on its magic.
Deployment
In short: as long as you can produce a Dockerfile for your project, you have plenty of options for deploying. Hanami does not have any recommendations on deployment, Rails has too many, there is a sea of tutorials on how to deploy rails to (insert the new cloud thing here).
There is no point in dwelling on this one, you know how many options Rails has, and it will only have more with Rails 8 having a planned, default dockerfile and seamless Kamal integration.
There is probably 0 chance of this happening to Hanami, but people are running Hanami on production. You will have to figure your own way, or ask the community to recommend something based on your apps architecture and stack.
Article conclusion comments
Ultimately the article's author summarizes how to choose a framework in 4 sentences and a "Ultimately, what you end up choosing is really up to you" and it is a true statement, but also something you know. There is no right or wrong in choosing a framework. There is only what you know, what you want to learn, what you want to build, what you want to achieve, how you want to do it and... oh, wait, it just goes on? It is more complicated than a short article conclusion?
There are multiple, pretty much endless factors when it comes to choosing how to write new projects.
Over the projects I've worked on, around 6 were greenfield project, 4 of those I was a lead on. Choosing a framework was always obvious - Ruby on Rails. Choosing a tech stack was always a challenge. How do we do frontend? Is StimulusJS enough, or will it be limiting? Do we use tailwind, or do we need custom styling? Vite or importmap? Do we use Devise or do we need a more robust solution, like RodaAuth? Custom CMS, or something ready, but also new, like SpinaCMS?
There are so many questions, and even more answers. You need to plan, but you can't plan endlessly. You always have to ultimately make a decision, and then live with it, master it. I usually steered towards technologies I know well, when time was very limited, and picked new stuff when I felt more safe. Not always though, sometimes I took a risk, and it usually payed off.
What I want you to get from my comments about this article, is to think. "what you end up choosing is really up to you" is very simple and very true, but also remember that if you go around, reading articles about what framework to choose for a new professional project, you are probably not ready to make that decision and lead a project. If you want to base your knowledge about Hanami on a 5-10 minute read, then you are not a mature programmer in my eyes.
You need to try it. You need to take a risk on some small professional project, or sacrifice some free time and code something in it in your free time. There is no other way. Reading documentation and looking at public repos is not gonna cut it. You want knowledge? You want experience and perspective? You gotta earn it yourself. No amount of articles is gonna give it to you. Not this one either. This one wants to debunk some stuff and provide you with a fresh look, maybe a nudge towards a more sceptical and curious approach to choosing a framework and comparing them.
This concludes my thoughts about the article AppSignal posted, that kinda awoken something in me. The rest of this is my own thoughts, and I hope you will find them valuable. They will mostly be about Hanami and my experience with it.
Hanami target audience
Key thing to understand is that Hanami is in no way targeted towards new programmers. Rails is a great first framework, and I am speaking from experience here, since I started with it. Along the way I touched on some pure ruby applications, Sinatra apps, RODA + Sequel stack apps, tried different languages and technologies. Rails remains my main tool at my day job, and I would need a lot of convincing to switch to something else. It is fast, flexible, pleasant to work with most of the time.
Hanami is a bit more complicated. Well, actually it is a lot more complicated. It assumes you, as a programmer, have a baggage of experience. You tried many approaches to code structure of web apps, and you have been burned. Here Hanami offers a return to simplicity. However this simplicity is so simple, that it might become complicated. This probably sounds like a over-bloated, self-loathing statement, or simply makes no sense, but let me explain.
Rails offers a lot of magic. It is a big framework, with a lot of stuff built in. It is easy to write a lot of code in Rails very fast, built big things in Rails in no time. That makes it is easy to write bad code in Rails, it creates many shortcuts, and if you take too many of them, and grew accustomed to them, you are gonna have a bad time.
If you spend a lot of time in rails, and then go write pure ruby, no doubt you will subconsciously use some rails only methods that you assumed were part of ruby STD lib. This is also caused by Rails magic, where things are not explicit, where stuff "just works" and you don't really know how and why. Finding out might take a while in case of Rails, because it is huge, full of callbacks na mysterious, expansive modules, global state etc.
Hanami takes a few steps back, and enforces you to build your own magic if you want it, but at the same time gives you tools to keep this magic well organized and explicit. Components and containers system along with slices, and architecture of configuration and providers are the main tools behind it. Of course this requires you to have experience and knowledge in code design. Without it, you will be lost, you will see no point in it and it will be easier to write just the worse, over-engineered, unreadable code that is impossible to maintain and extend.
But if you get some experience in design, and maybe functional programming (which influence can often be seen in dry-rb libs, that Hanami sits upon), things might start falling into place like blocks of tetris.
I think the main audience that might have their eyes glow while exploring Hanami, are people who saw a lot of bad Rails apps, tried a lot of different things, including functional languages, and always wanted something to take the best parts of all those stuff and mix them into one. It is a dangerous thing, since it makes it easy to create a framework with high bar of entry, and honestly, Hanami kinda does set this bar up high. It entrusts a lot in the programmer, but lets be honest - so does ruby. No static types, no strict rules, no enforced design patterns. Ruby is a language that lets you do whatever you want, and Hanami is a framework that lets you do whatever you want, but also gives you tools to do it well. You just need to learn how to use them correctly.
Real Hanami vs Rails
So what would be my comparison of Rails vs Hanami? To be perfectly honest, going back to the Appsignal article I think it was a bit pointless. No ruby programmer, when starting on a greenfield project, really considers Rails vs Hanami. Maybe some of them, when they get a really small project with a free hand, but then again, at this point this programmer is a senior with experience, and won't need an article to help him choose, he will take a look at the documentation, source, code, try it out etc.
In reality, there might be no comparison between the two. At certain areas, they are very similar, except for using the same language, they make heavy use of Rack, follow the MVC pattern (although with a different approach as we explored earlier). They both give a lot of freedom in terms of design, but Hanami offers more tools aimed at creating the design, Rails does not and in those cases where design matters, Rails does come in the way more often.
But in this manner, we could go on and on and on. Hanami does this, Rails does that, this has certain advantages but, that is more blablabla.
You want a real comparison? Write the same simple app in Hanami and Rails. A CRUD that manages books. We both know in which you will write the CRUD faster. Now add an authorization using email password and OAuth. Also rather clear where you implement it faster, even if you got similar experience in both Rails and hanami.
Now add multitenancy, payment system, add authors, readers, sellers and publishers account. Separate it all into DDD contexts, test it all (ofc I don't expect you to do it, but think about it, use your imagination).
Where do you think is the border, where Rails is no longer faster to develop? Where do you think Hanami starts to shine? It is not at CRUD level, and it might not be at design level if you are an super-uber developer that knows it all, and rides RoR like Tony Hawk does skateboard. But if you are not, you should quickly see which framework makes it easier to enforce a good design. Which one sticks closer to pure ruby and adds less magic. Which ones uses ruby to achieve more with less?
If you prefer simplicity, Hanami is better, but first you need a certain perspective and experience, that will make you see that Hanami makes things simpler rather than more difficult. It also does not makes things faster to develop until a certain point.
That is the real comparison to me. I haven't used the old, stupid mantra of "it depends", and I will not. I don't want to make a list, that will ultimately be pointless, I will not give you bullet points of what rails does better, what hanami does better. They are both tools for programmers, they have been designed a certain way, and developed by other humans who make mistakes and try to correct them. It always falls upon to you to learn those tools and make use of them.
However if you are a Rails programmer you probably often saw those "Rails does not scale", "Rails is slow" etc. articles and rants. They are stupid and tedious, often annoying cause of how ignorant they are. If you want to belittle Hanami (which I saw quite a bit of), be aware you are displaying the same level of ignorance as people bashing Rails for things that are simply not true and come from the lack of knowledge and experience.
Rails and Hanami in business
For the end I leave the nasty part.
There are no jobs in Hanami.
There are no companies that look for Hanami developers. There are companies that use Hanami but they don't really talk about it out load, they don't post job offers for Hanami. They will usually look for Ruby developers most likely.
Asking around in Hanami community about this, I got a few answers. There are a few places in Australia and some other serious apps out there, that do use Hanami, so in general, companies that have their own products, built by experienced programmers, have decided on Hanami. They keep quiet about it, cause why would they not? Senior programmers tend to be protective of their knowledge or simply don't have the time or the will to share it so Hanami lives somewhere in the shadows.
Rails jobs market is still healthy despite the recent IT - and I guess general global - crisis, and companies using Rails will not go away. You still have huge companies using it, and more projects coming in. There is no comparison and it seems the only real way to use Hanami in production is to build your own thing, or work in a product company where you get to choose the tech stack.
Conclusion
This was a bit of a rant, I admit. I wanted to give you a fresh look at Hanami, and I hope I did. I hope you see it as a tool for experienced programmers, who want to build better software, who want to be proud of their work, who want to learn and grow. It is not a tool for beginners, and it is not a tool for people who want to build stuff fast. It is a tool for people who want to build stuff well, and are willing to put in the time and effort to do so.
I see Hanami as a breath of fresh air. It is not perfect, nothing is, I think I made some of it flaws rather clear, and pointed out that not all comparisons were fair. But it is a great tool, also one that I found after trying out many different things, and working with dry-rb for many years. As a mix of functional programming and OOP it is an interesting experiment, one that is very impressive, but a difficult one for sure. It will get stuff wrong and get bugs and mistakes, redesigns. So does Rails and both will continue to do so, as most software does. But both tools are well designed and maintained with passion and care, with no competition between themselves and no real, sensible comparison.
I hope I shed some new perspective on Hanami and its place in Ruby world - in Ruby web world to be precise - dominated and monopolized by a single framework. And if I did not, that's okey, I wanted to ramble anyway. I've been trying out Hanami for over half a year, and so far I learned a lot thanks to it. If I wasted your time, be sure to argue with me on the internet, I promise I will respond.
Top comments (0)