It is a shame people here can't get past the font size because it is a really well written and interesting book. Just zoom it down to the desired size and enjoy.
Say what you want about bloated Electron apps, but they've improved the Linux desktop experience. Slack, VSCode, Atom, KeeWeb, among others. Also the modern web, PWAs, etc.
This article really doesn't resonate with me. I'm excited about Hanami, but there are a few considerations that keep me from using it.
First, I'd love to see that there are successful implementations of Hanami for larger "real-life" projects. On github right now the most robust Hanami app I can find is this https://github.com/ossboard-org/ossboard. Which is still a relatively simple app compared to what I tend to work on/with.
Second, a while back developers in the ruby community began advocating that too many libraries/gems were Rails centric - often the gems or libs didn't work at all unless used with Rails, or non-Rails support was an after-thought. In my opinion that message seems to have hit home, and more libraries are for Ruby, not Rails, such as ShrineRB and the whole rom-rb family.
Hanami's ultimate challenge, I feel, will be developing an acceptably robust ecosystem (https://github.com/davydovanton/awesome-hanami) that choosing it over Rails isn't going hurt more than the benefits of choosing Hanami. This is greatly helped by the ruby community making gems and libs for ruby, not Rails.
However, in my current project while there are quite a few gems that aren't tied to Rails, there are also a number of key gems that are. I either have to roll my own or deal with alternatives that would be more work.
Lastly, on the topic of Rails vs Hanami:
In my view the single biggest issue with Rails right now is that the scope and complexity of web applications has grown over the years. Most people are developing medium-large projects with Rails, at least relative to the size of projects Rails was initially designed for, and Rails doesn't really accommodate this. Rails engines are an awkward solution to this problem, but that is the direction Rails pushes you. If you start using engine or namespaces heavily in a rails application you quickly run into friction. You can google and find many articles about how different teams have structured their "modular monoliths". None were easy paths.
Thanks for your article. It's really helpful to hear about the technologies that have been used in actual projects/production environments. I'd love to hear more about what diminished your excitement with ElementUI vs iView
https://edgedb.com/docs/datamodel/scalars/json#type::std::js...