second attempt

In my recent Don’t blame rails post, I talked about my opinion on most of the rails blaming that is happening in the recent past.

It was interesting how much some of the people I consider good software engineers disagreed with me. I am happy that I was finally able to distill the difference in opinions so that I can now share it. In addition to that, I am now able to make a more precise statement on my opinion, than I was in the last blog post.

Skill level

The first important distinction is about the skill level of the complaining person seems to blur into my perception of the statements. I don’t have any issue on discussing the problems rails has, with somebody who really understands the problems and the benefits alternatives have. I am just annoyed by criticism that is based on repeating other people’s statements without own experience or expertise.

Replacing frameworks with frameworks

I guess one thing that seems to make me skeptical is that people criticize rails and its complexity or the implications on the app they build, and still want to switch to phoenix or some framework in any other language. I find it confusing to just swap frameworks as a solution that should address architecture or complexity. I am afraid that one might be destined to experience the problems with the new framework, that one originally had with rails.

Two distinct topics

My last post and the above reflection on it, was mainly about addressing the way people blame and criticize rails in ways, that partly bothered me.

Today I also want to take the time to express my own opinion.

My opinion

I really appreciate what rails did for the web development community. I think it made this part of our industry a better place. (Just thinking of the fact that I had to use PHP before Ruby and Rails)

However don’t like it’s complexity, the missing support for separation of concerns and also the direction rails is heading, even though, I really appreciate the fact the the core members are really doing a great job in simplifying parts of it.

Frameworks and rails’ design choices

I think part of this complexity and the implications is just part of the fact that its a framework. However other parts don’t just fit my imagination of software design. Some examples are:

  • I prefer, having per action abstraction and not one controller with methods per actions, which then might be compensated by having a service/interactor per action.
  • Having a distinction between domain models (entities) and database object mappings (in OO contexts) makes things easier. It’s easy to do manually, but it’s additional boilerplate.
  • The fact that one has to use hooks instead instantiation is a bad thing itself. This is the case with controllers, but also with the way DHH prefers to expose the attributes API, which otherwise would be just great.
  • Having a repository abstractions seems valuable to me, and its one of the parts where I prefer Ecto over AR.

These are just some things that bother me. I guess one can compensate most of it rails, quiet easily, but just don’t like working with it. I guess it just no longer fits my needs and the way I like to write/build software systems. Maybe ActiveRecord does no longer provide the abstractions/API that match the learnings of the last years and current best practices.

My future way

By default I personally would not use rails for new projects. I think I am aiming for simpler and less coupled components to create properly maintainable systems. This also implies I would also prefer libraries over frameworks. This means working on top of rack, WAI, ring and so on seems to be a better fit for the kind of API-only micro services I am creating at the moment.

I guess there will be some use-cases or sets of requirements in the business context that will make rails the proper choice, but unless that is the case, I will go with smaller and simpler solutions.

Another reason is that I would not use Ruby by default anymore, but instead go with Elixir, Clojure or Haskell, depending on the runtime constraints. The reason behind that, is simply my believe in the benefits of functional programming compared to imperative programming (Let’s avoid the ‘definition of OO’ discussion here). And even though ruby offers some functional concepts, its always a pain to go that direction in a language that is not designed to be a functional programming language.

Ruby and Rails are great

However I don’t want to take anything away from Rails or Ruby. They have their benefits and they have made great achievements possible. So Ruby and Rails were solving problems at that time and might haves surpassed that time and need.

UPDATE: As a funny coincident I just saw this talk from Justin searls at rails conf, which also goes into some details about the fact that people are leaving rails from a quiet different angle, that I did not consider so far. Nice to have additional ideas on the topic