1. 34
  1.  

  2. 13

    I don’t agree. I’ve been using Rails for 10+ years (at least 8 with some confidence), and am still actively using it on a daily basis on one project. I’ve sometimes used the standard conventions, other times I’ve modified (or rather extended) them pretty extensively. Clearly Rails has got a lot of things going for it, and many of the shiny novelties that have been touted as better alternatives weren’t. Still, I think Rails has big shortcomings and articles like this one fail to imagine how, or even that, they could be improved upon.

    The main argument presented here seems to be:

    With Rails, you don’t have to make any of the decisions above.

    The author doesn’t try to argue that Rails makes good decisions, only that it’s great that we don’t have to make them ourselves.

    The second and final point is:

    Rails Helps Maintainability

    The argument being that libraries tend to be maintained over long periods of time, which is true in many cases, and I agree that the ecosystem is Rails’ very strongest point. (This is mostly true for hands-on, everyday things like “connect to Stripe” or “upload to S3”. Other ecosystems are better at other things.)

    Then the author comes back to the point about strong conventions which he claims help “fewer parts of an app to get crufty as time goes by”. I don’t agree. I think Rails’ conventions actively encourage bad practices, which harms maintainability and indeed leads to a crufty codebase.

    These problems stem first from ActiveRecord which is a weak abstraction and almost invariably leads newcomers down the wrong path, after which they must learn a whole lot of “best practices” to implement decent database access pattern. Secondly, Rails does nothing to encourage users to isolate domain logic and keep it sanely structured. (An unstructured collection of service classes is a small but insufficient step towards rectifying this problem.) The result is that, after a short honeymoon of “getting up and running in no time”, it becomes harder to focus on the app domain and “the problems [we] need to solve”, because the domain logic tends to be spread out all over the place.

    These arguments have been rehashed for almost as long as Rails has been around. There’s nothing remotely new in what I just wrote. People’s tastes and experiences vary. I’m reluctant to say there is no objectively assessable dimension to this issue, but on the whole we’ll do best to agree to disagree.

    1. 7

      I’m with you. Although I will concede that most businesses fail, and Rails does allow small teams to move quickly toward usable features for customers. Perhaps marginally improving the company’s chances of success.

      The problems all come with success and larger teams. The monster ActiveRecord models containing business logic, without domain boundaries. The fact that dynamically typed Ruby underlies it all. The lack of established modularity patterns … These all culminate, making for inefficient, large teams after the honeymoon years of startupdom are over. All those readymade, but poor Rails decisions that made starting up a success really come back to bite you.

      1. 4

        What do you prefer these days?

        1. 2

          I am not a subOP, but I have moved from Rails to Phoenix and never looked back.

        2. 2

          I’m interested to hear which frameworks solve those problems for you!

          1. 4

            For me Phoenix with Elixir solve most of these problems. It is still mostly opinionated, but with ease you can change that behaviours, it encourages proper separation of the application logic, it uses repo-pattern instead of the ActiveRecord, etc. Of course, it is less popular, so finding hires is a little bit harder, but if you look within community (which author is strongly suggesting) then there should be no problem with finding people.

            1. 1

              I love Phoenix too! I need more experience with it, but as far as I’m concerned that was a great answer to my question 😄 Cheers!

            2. 1

              The two main problems I pointed out were AR being a weak abstraction and Rails not doing enough to encourage domain logic to be written in an isolated and structured manner.

              For the first problem, my conclusion is that database abstractions are not worth the trouble. There are several that are better than AR, but SQL databases are actually pretty hard to abstract over, at least if you want to full advantage of what they can do. Instead, treat the database as your framework. (And by “database”, I mostly mean Postgres.) This approach to writing applications is still pretty common in large enterprises (from what I gather) and “modern” devs like to make fun of it, but I think it’s more relevant than ever. If you put PostgREST or PostGraphile on top of that to expose a REST/GraphQL API, this setup fits right into a modern stack.

              For the second problem, I think domain-driven design goes in the right direction (although it’s been obfuscated by being lumped together with particular technologies and bloated architectures, not least microservices). I see DDD as an offshoot of the bigger field of (abstract) data modeling or concept modeling, which was to a big extent ruined by heavy UML standards, consultants, frameworks… But I think it’s essential, and I would measure a language or framework by how clearly and directly it lets you express the domain model. (Domain Modeling Made Functional is one approach to this.) Yes Rails tries to make some things more “declarative”, which is good, but again, it has little to offer when a system grows more complex.

              I would use Erlang/Elixir (or Gleam!) if I ever had to create a system of the kind that the BEAM was meant for, but not for a regular CRUDdy web app.

              So the short answer is: Postgres, because it helps me focus on and express the domain model!

              (@squarism this was in answer to your question too. More concretely, my preferred current stack is PostGraphile + Elm.)

          2. 9

            Yes! I think it’s also the best framework for small teams. We launched Transistor in 2018 as a two-person team, and we’ve been able to maintain our size through all the growth we’ve experienced since then.

            The benefit of Rails is that when we do need to hire a contractor, we have lots of friends in the community (who we trust) that we can call.

            1. 6

              I totally agree.

              I’ve been doing rails for years now, and it’s still just so powerful.

              I’ve spent the last day or two thinking about doing a FastAPI project, but I keep on finding new decisions I’ll have to make, like what ORM to use and how to get migrations working. I don’t want to have to think about all that, I want to create a website!

              Has anyone here gone from rails to FastAPI? I would be very interested in hearing your take.

              1. 2

                Not used FastAPI specifically, but did have to write a simple API recently. Basically two JSON endpoints with a case statement behind one based on a parameter being sent in.

                Spent the best part of a morning trying to get it rolling with Sinatra, small app means small framework is appropriate tool? Realised I was going in circles trying to test it. Generated a slimmed down rails api app, had the whole thing complete with end to end tests in under two hours. chefs kiss

                1. 2

                  Haha!

                  Yeah sadly the testing is always a huge part. Like, the framework might be tiny but if I can’t write tests easily then it’s going to slow me down loads. Back to rails.

                  1. 1

                    What would be the advantage of a framework as oposed to a simple http server library and a json serializer call? It takes 5 minutes to put together.

                    1. 2

                      Not having to make decisions and glue things together. Familiarity with the framework and where things sit, other tooling just plugging in. Basically this article it turned out 😉

                      Edit: This was an application for a product launch at work, that has to work correctly or it has a massive impact on customer experience. Testing was non-optional, and for all it’s a trivial app being confident it does what we think we’re testing was important. I also have to hand it over to a team to maintain, and our other applications are using rails, so convention/patterns we use elsewhere being the same here makes jumping between the apps less jarring too.

                2. 4

                  Rails has a lot of advantages, especially for smaller teams. It’s a incredibly powerful and fast way to standup a web app.

                  However, in my experience, once the size of the tech department grows you can definitely experience pain. Call back hell, return type mismatches, etc.

                  These problems seem to really arise when the app gets too big for individuals to keep in their head.

                  That said it’s still the first framework I go to for side projects that are web apps.

                  1. 8

                    Your woes make you the exact target audience for his new book: Sustainable Web Development with Ruby on Rails. No, I am not affiliated, but I did work with him at Stitch Fix, and he knows what he’s talking about and has done it. I haven’t read the book, though I want to, and feel I’ve already been a part of success at this.

                    1. 6

                      (For anyone who is confused, “he” and “him” in the parent comment refers to the author of this blog post, who also wrote that book.)

                      That book looks pretty useful. The 50-page sample PDF is worth reading even if you can’t afford the whole book. From the sample chapter “Business Logic (Does Not Go in Active Records)”, I learned how and why to create a service layer in a Rails app. And from the sample chapter “Jobs”, I learned that Active Job may not be worth its complexity in apps (as opposed to in libraries), and learned of some bugs to avoid when writing jobs: actions may happen twice due to retries after partial failure, and relevant code may be skipped due to data changes between job retries.