
Why Hanami will never unseat Rails - mparramon
https://boffinism.com/why-hanami-will-never-unseat-rails/
======
martingordon
I've been doing Rails development for ~10 years and maybe it's just a sign
that I'm getting older, but for me the biggest problem isn't Rails, it's Ruby.

In the past year or so I've done a lot of more modern JS development (with
Babel and Flow) and toyed around with Elixir and ReasonML. Ruby hasn't seen
much change in the past couple of years (granted it's much more mature than
Elixir/Reason) and while it was a boon to developer productivity and happiness
compared to the languages of the time, I think we've probably found a better
balance in type systems these days than Ruby and the like did at the time.

Maybe it's just legacy codebases, but manually reasoning about types is huge
time sink and are one of our leading causes of production errors. Explicit
typing also informs better design (I've seen many a Ruby method have return
type of `String | Array | nil`). Unit tests help, but why outsource that to
tests and guard statements (where you have to check every type) when a
computer can do that for you?

~~~
jfaucett
> I've been doing Rails development for ~10 years...

I'm a long time Rails dev as well. IMHO the main problem with the Ruby
ecosystem is that the libraries haven't moved on into the current day and age.
I find myself building more and more projects in something like Java or Python
because those ecosystems have the firepower of the ML, AI, data processing
libraries. And while I'd still say Rails is the best for building pure web and
rest API stuff, Java and Python have gained a lot of ground and when all your
real app power is in Python or Java a lot of times its not worth wrapping your
core apps in another runtime just to provide a rest interface.

Any other rails / ruby devs experiencing this?

~~~
3pt14159
I hesitate to even say that I'm a Rails guy anymore because I've modified it
for my own purposes so heavily that it's fundamentally a different thing[0]
but I'm also a data scientist and when I need data science I just use python.
It's so much easier to just have python / cython / numba and Rails share
databases and just communicate through that when needed. For the stuff that
can't communicate through the DB I can either fork off traffic to python in
nginx or communicate through something that unix provides (pipes, ports,
files, 0mq, whatever).

Ruby / Rails is so much more productive for me. No other language nails so
many features as well as Ruby. Blocks are great, the meta-programming is
natural and easy to debug, c-extensions are easy, and I generally like the
balance it strikes with types. Couple quibbles here and there, to be sure, but
usually the DB acts as my type enforcer and the high degree of test coverage
covers the rest. Plus whenever I think something is risky I just throw in an
explicit type coercion or exception, but it is rare.

I find people generally fall into one of three categories: Documentation
enthusiasts, type enthusiasts, or test enthusiasts. Because I prefer human
readable code I prefer meta-programming and because I prefer meta-programming
I prefer tests over types or documentation. Though I don't pretend it's
drawback-free, it is the environment that makes me happiest.

I think my next major thing will be to modify ruby itself because there are
things that are missing that I feel could make it even better, but I'm trying
to figure out if I can get away with just doing it in a really powerful gem.

[0] Designing for billions of writes per day, JSON API 1.1 + auto linking and
pagination, dead simple defaults for controllers, lots of extra methods for
better code legibility, etc. I've been thinking of extracting it all out into
its own thing but I don't want to deal with the headaches of communicating
breaking API changes.

------
meesterdude
> but whatever the volume individually, collectively it adds up to a lot of
> negativity

Nope. Plenty more people love rails and contribute improvements to it than
loath it and bash it.

> the building blocks of a Rails application scale really, really badly as a
> codebase grows

uh - i slide a slider in heroku. Others add machines behind a load balancer.
Shopify does 18000/reqs/sec on rails. The "rails doesn't scale" argument died
years ago.

> You find yourself longing for POROs, hating the complexities of ActiveRecord
> callbacks when dealing with subclasses of models, cursing the way instance
> variables you set on a base controller somewhere end up being referenced
> inside view templates

No, I don't. these are all things I like about rails.

> the bitter taste in the mouth that prolonged Rails exposure leads to.

can definitely sense the bitterness...

> Whereas for Rails, the all-consuming vision of what the framework should be
> requires them to put in, amongst all the goodness, the bad stuff that causes
> people so much grief in the end.

No idea what this "bad stuff" is.

The author isn't a rails developer, and that's fine. But that doesn't mean
rails is broken, or wrong, or bad; despite contrary portrayals. It just mean
Rails isn't for them. They make it sound like it's some monster to work with
and grow - it's the exact opposite. It's streamlined to be easy to grow and
work on; which makes working on it enjoyable.

Nothing in ruby will unseat rails for web frameworks; short of rails stopping
development. And personally, I am yet to see a more effective and enjoyable
framework; nothing really comes close with the speed and power rails provides;
where one developer can deliver their product to all platforms, reusing much
of the same views and controllers, delivering changes instantly; it still
amazes me.

~~~
vertex-four
I've been watching my partner try and build a web app "the Rails way" for the
past couple of weeks. The result has been huge amounts of pain any time
slightly not-off-the-shelf functionality is desired, especially when Devise or
email is involved.

It's supposedly great, otoh, if you're working on a CRUD app with minimal
requirements, you're not that big into TDD, or if all the complex stuff in
your app actually lives on another service that you can talk to over e.g.
RabbitMQ that isn't tied down by Rails.

~~~
dchuk
Can you give real examples? I've always heard this complaint about Rails but
have also built a few large apps in it and never felt these problems myself.

~~~
vertex-four
A couple of specific issues include that email to multiple users is difficult
to get right - googling for it results in a number of weird hacks, with Rails
providing nothing itself, and the most obvious mechanism involving a lot of
logic in your controllers - and Devise's invitations stuff is very inflexible,
making a number of assumptions about what data should be stored (invitation
timestamps being the major one). Given that a goal of this specific app is to
store as little data as possible, that's unacceptable, and resulted in a fair
bit of monkeypatching.

And that seems to be the core of it - monkeypatching things or depending on
implementation details seems to be the norm when trying to get Rails and its
supporting ecosystem to do something other than what it does by default, and
that's difficult to maintain over the long term. And if you can't depend on
Rails and co being flexible enough to do what you want, you might as well
build on a less-opinionated framework from the start and skip the step of
trying to bend Rails into shape.

~~~
meesterdude
> if you can't depend on Rails and co being flexible enough to do what you
> want, you might as well build on a less-opinionated framework from the start
> and skip the step of trying to bend Rails into shape.

Sending email is one of the things rails does out of the box. ActionMailer is
builtin. I myself use mailgun as the provider - it took me 5 minutes going.
But there are plenty of ways to do it for what your needs are.

Rails has an opinion on how to do things, but you can do your own thing too.
Those opinions it comes with let you ship better code faster, and allow you to
focus on the real problems of your project.

But rails, in my 8 years of working every day with it across a multitude of
projects, has never been not flexible enough.

~~~
vertex-four
> Sending email is one of the things rails does out of the box. ActionMailer
> is builtin.

Yep. ActionMailer is great at sending email... to one person. Where the logic
goes in Rails for sending email to multiple people, nobody has a good answer.

------
spuiszis
As a Ruby/Rails dev, the OP makes a good, directionally correct point: "I
don’t believe that simply being better than Rails is enough to displace
Rails."

However, he's off by a bit. It's going to take another framework to not just
be "simply better". This framework will need to be an order of magnitude
better to get me to switch from the amazingly productive Rails ecosystem. The
framework/language marketplace is crowded and you are going to really need to
standout to get any serious adoption to compete. For me, the cost of switching
all new development projects to Hanami seems to out-weight the benefits (this
also assumes Rails is the correct tool for the job of course, which it often
isn't).

That said, a Rails/Hanami/Sinatra framework built on the Crystal language,
which looks almost exactly like Ruby but gives you C performance, appears like
it might be that order-of-magnitude to 100x game-changer that could get me to
switch stacks. [0]

Whether you like him or not, Peter Thiel has some good thoughts when it comes
to innovation and I think this argument perfectly encompasses this
Rails/Hanami discussion:

"As a good rule of thumb, proprietary technology must be at least 10 times
better than its closest substitute in some important dimension to lead to a
real monopolistic advantage. Anything less than an order of magnitude better
will probably be perceived as a marginal improvement and will be hard to sell,
especially in an already crowded market. The clearest way to make a 10x
improvement is to invent something completely new."[1]

[0] [https://crystal-lang.org/](https://crystal-lang.org/) [1] Zero to One -
[http://amzn.to/2GaaMP0](http://amzn.to/2GaaMP0)

~~~
Willamin
I expect to see rails slowly die off over the next decade, with many rails
developers moving to either Elixir-based web framework Phoenix or something
written in Crystal. There are a few web frameworks in Crystal, but none are
fully complete yet. \- [http://kemalcr.com](http://kemalcr.com) \-
[http://luckyframework.org](http://luckyframework.org) \-
[http://amberframework.org](http://amberframework.org)

~~~
briandear
Swift will be more prevalent than Crystal. There are already some serious
frameworks available and you get the additional bonus of being able to write
Mac and iOS with the language as wel.

~~~
bpicolo
The server-side swift ecosystem is incredibly small, and that's by far the
most important thing for adoption.

You're not really going to share backend source with your iOS apps, so there's
nothing to really gain there. Languages are so homogenized these days that
moving between the popular few is pretty simple and requires fairly minimal
rampup.

------
jrochkind1
I think OP makes some good points. And missed an opportunity to another one.

The transition from "infatuation" to "grudging resentment" (recognizing the
fundamental problems with the approach and how they get in your way) is likely
to happen with _any_ platform/framework.

When you the emoter develops more experience with it, and also when _it
becomes more mature_. A less mature framework, problems that get in your way
-- or legit use cases there's no convenient solution for -- can be explained
away as "well, it just hasn't gotten there yet." They're still getting in your
way, but you forgive it. Even when the things that were easy in the last
framework are hard in the new one -- it's just not there yet, and hey, these
_other_ things are easy that used to frustrate me a lot!

But eventually it will be mature, and it will still have problems, including
fundamental ones with it's approach that get in your way, and also always
including (for something mature) "legacy" problems, where most people now
realize some choices could/should have been made differently, but it's too
hard to change now (for backwards compat, and just cause so much code has been
built up).

Leaving the mature thing you have become good at for the new exciting immature
thing (you aren't yet expert enough at to see the flaws in) will provide
temporary relief at best. The grass is always greener.

[This does not neccesarily apply to some things that are _just bad_. Things
that people are using despite the fact that they are _not_ helping them
develop quality software efficiently. Those things should just be left.
Ultimately one would like to believe that a mature solution that helps you
develop software more efficiently will win out in the end -- we know there are
'political', 'marketing', and other considerations that make this not always
true. But I want to draw attention to the fact that _we are not good at
judging_ whether a new _immature_ framework/platform/language/ecosystem we
have little experience with will actually help us develop quality software
more efficiently than the mature thing we are expert with, and know all it's
warts.]

------
pg_bot
I honestly would take a page out of DHH's philosophy and say that's fine. It
makes no sense that every tool/app/business has to dominate the landscape. In
fact that kind of mentality is quite toxic in the long run. Make new stuff,
experiment and see what is out there since popularity does not always
correlate with quality. Do not let other people's versions of success come to
define your own.

------
FanaHOVA
Down in the article:

> Well, the primary answer is that Hanami isn’t trying to unseat Rails.

Exactly. Clickbaity titles are still necessary in 2018 apparently.

I've worked with one of Hanami's maintainers for a while, working on a Rails
app. I have been following the project for a while, it's definitely not a
Rails killer. I'm not sure why these conversations are always brought up. But
hey, at least the "Elixir/Phoenix will kill Rails" discussions have stopped
for a few months.

~~~
sotojuan
> at least the "Elixir/Phoenix will kill Rails" discussions have stopped for a
> few months.

At least until the next Phoenix version is released :-)

------
vinceguidry
I like Rails and see no need for a new basic web framework.

If we want to reinvent something, I'd say a new e-commerce framework is
needed, Spree appears dead in the water and honestly, not that much better
than Magento. Then again, with Magento 3's embrace of a REST API, finally
we'll get to see a services approach.

But if someone wants to make a robust e-comm framework with Hanami, I'd be
happy to evangelize that.

But I think everyone needs to just realize that stacks require massive numbers
of developers to do well, and new ideas are going to rightly struggle to find
traction against the behemoth.

~~~
bigjimmyk3
Spree may be dead, but its successor Solidus
([https://github.com/solidusio/solidus](https://github.com/solidusio/solidus))
is still seeing regular fixes and feature updates.

------
scandox
> Now, here’s the first really controversial point I’m going to make: I don’t
> believe that simply being better than Rails is enough to displace Rails.

Isn't this the totally uncontroversial Principle of Good Enough:
[https://en.wikipedia.org/wiki/Principle_of_good_enough](https://en.wikipedia.org/wiki/Principle_of_good_enough)

?

~~~
acobster
Yeah, I had a similar thought. I think the author was being deliberately
modest, prepping the reader by getting their guard up for a big assertion and
then delivering a relatively unsurprising point.

------
jtth
It's easy to forget that most people are just starting out (by definition;
most people quit or stop), most people just want to make something, and for
that, there's nothing better than rails. I'm in this boat. I just want this
thing I thought of and designed to be real, and now after doing Hardtl's
tutorial and reading/coding for two days, my thing's basic MVP is real. I've
never really done a web app before except for some experiments in Clojure. But
I'm not programming it in clojure, a language I like better than Ruby and know
a lot better than Ruby, because there's no opinionated framework, there are no
models, there's nothing even close to rails and activemodel and all that. I
just want to make the thing. That's what most infant-sized things are: babies.
And to make the baby you make it in rails and deploy it on heroku. If it
sticks, remake it in something else if it really does have scaling problems.
But most things don't succeed, and if they do, they probably won't succeed at
the scale where it matters at all that they were written in rails. (This is a
statistical argument.)

~~~
erokar
Completely agree. I've tried Java/Spring, Python/Django/Flask,
JS/Express/Meteor, Ruby/Rails/Sinatra and Elixir/Phoenix. The only thing I've
seen that might rival Rails in productivity is Meteor, but that is relevant
mostly if you absolutely need an SPA or some kind of realtime support. Apart
from that Rails is the most productive framework, and it's perfect for a solo
developer or a small team -- and that goes for both novice and experienced
developers. I'm currently looking into Elixir/Phoenix –– and I think it has
the potential to become as productive as Rails, but so far the ecosystem is
much smaller.

~~~
jtth
Yeah. Perhaps this is a good metric of ecosystem and developer productivity,
and would make for a good extensive blog post: how long does it take to
implement users, with password resets and security and everything being just
so? With rails, it's, what, an early afternoon with devise and some associated
gems? What else has that? Again, not perfect, not tailored, but most people
don't wear tailored clothes, and don't need tailored clothes, either. I'll be
happy if I get one paying user in a few months when I'm ready to show this
thing off. (Edit: I just watched a meteor tutorial doing exactly this and now
I feel a pull to remake everything. Jeez.)

------
jonstokes
My experience is that people who come to feel about Rails the way he describes
in the intro (I went through this exact progression, myself) end up moving on
to another stack entirely, typically either Elixir or JS.

My personal shift has been to JS, because you do can everything from front-end
to AWS to postgres (via plv8) with it -- it covers the whole stack. And with
the advent of ES6, it's just not that bad as a language. It's not great, but
it's not the misery it once was, either.

As the author says, Rails is great for starting out. It's great for starting
projects, and it's great for starting as a web developer. But I know first-
hand the pain of growing and scaling a monolithic Rails app that he speaks of,
and for projects that I start from scratch I no longer use it.

------
kochandy
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](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](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.

Hanami's first win is in addressing this problem.
[http://hanamirb.org/guides/1.1/projects/selectively-boot-
app...](http://hanamirb.org/guides/1.1/projects/selectively-boot-apps/)

