1. 17
  1.  

  2. 18

    This post is very confusing because it doesn’t actually answer the title. But here are the main takeaways:

    • Rails is not dead, it is still very popular and also the best. This is not an opinion. Don’t trust opinions.
    • Okay, maybe the project made some bad decisions
    • Okay, maybe a lot of people left it for other things
    • Other languages are less popular and/or dumb
    • People left the framework because they are lazy
    • Everyone else is a bad programmer and that’s why they use other projects

    This post is meant to be a serious look at the state of RoR, but instead comes out as even more rambling than the other articles the writer criticizes.

    1. 2

      It felt more like a primer on the history of web development in the last 15 years, than to explain why its lazy to badmouth Rails.

    2. 10

      The Java/Microsoft mainstream is gaining new traction. Aesthetics also got diluted. Careful engineering is getting diluted. Social networks ubiquity and the easy path of quick cloud deployment is making people less and less patient. Crafting requires patience. People crave Likes, a new generation of vanity metrics arose.

      This is… baffling. My experience with Rails projects is that they accrue layer after layer of monkey patches, hundreds of ill-advised gem dependencies, excruciatingly slow CI builds, “surprising” bugs when monkey patches conflict with other monkey patches, poorly thought-out method_missing metaprogramming, and model classes that span thousands of lines. Aesthetics? Careful engineering? Crafting? Those are not things I associate with Rails.

      1. 8

        I’ve been building rails apps for around 7 years at different places, and only one codebase I worked on was well factored and approachable. I’d say “good” Rails only happens when you work really hard to design as much of the domain as possible outside the framework.

        1. 3

          I’d say “good” Rails only happens when you work really hard to design as much of the domain as possible outside the framework.

          I agree, but think that is as it should be, and that it is true for most frameworks when building beyond prototype/demo projects or scope-restricted services.

          I have found that framework-based projects, whose teams treat said framework as a scaffold to build within, rather than tools that collaborate with their own domain, are those that wind up a twisted mess. Rails or otherwise (though the larger the framework, the quicker this takes hold). The Ruby language also makes this easy for people who have never seen a mess before, nor introspected on how to avoid it.

          I sometimes suspect that the choice of the term “framework” has something to do with it. If a team was instead introduced to four “libraries” named ActiveRecord, ActionPack, ActionMailer and Rack, I wonder how that would influence their use in a project.

          Stemming from that is my other common thought: the architectural fragility of many long-lived Rails applications is made worse by the way it is taught (especially to beginners). I like Ruby, and most of what makes Rails useful comes from Ruby. However, Ruby never seemed to me a good first language, never mind one to learn from within the faux walls of some framework. Unless you know how Rails is doing what it does via Ruby, it is hard to see the forest for the trees, and to grasp and see how you might plant your own.

          Josh Susser once said something to the effect “there are three eras of building a project in a framework”, and went on to describe four, which I will roughly paraphrase from memory (I tried but could not find the talk it was from):

          1. The framework is a huge productivity multiplier and everything is awesome!
          2. The framework is still helpful, but it’s influencing your architecture too much and you’ve bumped into a few places where it just doesn’t fit.
          3. The framework is actively interfering with your productivity.
          4. The if-you-live-to-see-it fourth era: you dig yourself deeper by building a framework on top of the framework.

          I personally feel there is a “Good Ending” version of the fourth era: You heed the pain felt in the third era, and learn to build with the framework rather than build within it.

          1. 4

            The culture and rhetoric of Rails also works against this. Rails wants to own everything. Building alongside the thing feels wrong, and a lot of people who you hire as Rails developers will argue that it is wrong, and work against you. Ruby doesn’t help very much, either, because there’s no real namespacing and no way to contain the massive monkey-patches like ActiveSupport.

            If you have a lightweight framework, it’s a lot easier to treat it as the presentational layer and not let it infect your business logic. Rails actively works against you.

        2. 3

          Aesthetics? Careful engineering? Crafting? Those are not things I associate with Rails.

          What, you don’t like magic superglobals or using spooky action at a distance to suppress callbacks?

          Remember, kids, it’s not global mutable state if you make it thread-local and wrap it in a constant. Sprinkle liberally.

        3. 4

          I like this article but think it would be better named “A history of RoR” or something.

          1. 3

            The Java/Microsoft mainstream is gaining new traction. Aesthetics also got diluted. Careful engineering is getting diluted. Social networks ubiquity and the easy path of quick cloud deployment is making people less and less patient. Crafting requires patience. People crave Likes, a new generation of vanity metrics arose.

            I certainly wouldn’t classify Ruby as “careful engineering.” 11000-line yacc file? Not exactly screaming “everything was thought out beforehand” to me.

            1. 1

              I feel like I’ve confused Ruby’s grammar before, but I don’t have any examples at hand.

              OTOH, people like, and can usually navigate ambiguous grammars, so as much as I agree with you from a parsing standpoint (there are places where the error state is manually reset…yeah), I don’t know if it is something the user feels the complexity of, despite my expectations that it would.

            2. 1

              Since when Scala is smaller niche language compared to Ruby ?

              1. 1

                Rails is that bad huh?