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.<p>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.<p>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?
> but whatever the volume individually, collectively it adds up to a lot of negativity<p>Nope. Plenty more people love rails and contribute improvements to it than loath it and bash it.<p>> the building blocks of a Rails application scale really, really badly as a codebase grows<p>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.<p>> 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<p>No, I don't. these are all things I like about rails.<p>> the bitter taste in the mouth that prolonged Rails exposure leads to.<p>can definitely sense the bitterness...<p>> 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.<p>No idea what this "bad stuff" is.<p>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.<p>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.
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."<p>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).<p>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]<p>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:<p>"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]<p>[0] <a href="https://crystal-lang.org/" rel="nofollow">https://crystal-lang.org/</a>
[1] Zero to One - <a href="http://amzn.to/2GaaMP0" rel="nofollow">http://amzn.to/2GaaMP0</a>
I think OP makes some good points. And missed an opportunity to another one.<p>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.<p>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!<p>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).<p>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.<p>[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 <i>we are not good at judging</i> whether a new <i>immature</i> 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.]
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.
Down in the article:<p>> Well, the primary answer is that Hanami isn’t trying to unseat Rails.<p>Exactly. Clickbaity titles are still necessary in 2018 apparently.<p>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.
I like Rails and see no need for a new basic web framework.<p>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.<p>But if someone wants to make a robust e-comm framework with Hanami, I'd be happy to evangelize that.<p>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.
> 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.<p>Isn't this the totally uncontroversial Principle of Good Enough: <a href="https://en.wikipedia.org/wiki/Principle_of_good_enough" rel="nofollow">https://en.wikipedia.org/wiki/Principle_of_good_enough</a><p>?
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.)
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.<p>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.<p>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.
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.<p>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 <a href="https://github.com/ossboard-org/ossboard" rel="nofollow">https://github.com/ossboard-org/ossboard</a>. Which is still a relatively simple app compared to what I tend to work on/with.<p>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.<p>Hanami's ultimate challenge, I feel, will be developing an acceptably robust ecosystem (<a href="https://github.com/davydovanton/awesome-hanami" rel="nofollow">https://github.com/davydovanton/awesome-hanami</a>) 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.<p>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.<p>Lastly, on the topic of Rails vs Hanami:<p>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.<p>Hanami's first win is in addressing this problem. <a href="http://hanamirb.org/guides/1.1/projects/selectively-boot-apps/" rel="nofollow">http://hanamirb.org/guides/1.1/projects/selectively-boot-app...</a>