I usually write here in Brazilian Portuguese but this post is written in English in the hope of getting some useful attention and discussion going on (yes, wishful thinking).
Before we start this, let’s make some things clear. When I criticize Rails there’s two common reactions:
- “OMG, DHH and the Core Team are awesome, they know what’s better for you, stop crying!”
- “Well, stop using Rails and create something better!”
- “You should not criticize the tool that pays your bills!”
- “Yes! Yes! Let’s burn these motherfuckers!”
Let me be totally clear here: Rails is very useful and I like it a lot (although I used to like it way more). Otherwise I would just dismiss it and don’t even bother trying to get some attention to the issues I’ll describe. I respect the work and effort of so many people that keep the framework going fixing bugs and adding features. You should too, it’s not a walk in the park and very few people actually get some time to do this kind of work. A special mention goes to Aaron Patterson (@tenderlove), a guy who relentlessly keeps cleaning up the mess that Rails’ codebase has become while still keeping his humility (sadly, a rare trait in our community).
Some days ago, when talking with a friend, he said “Rails has entered the framework death spiral – it’s now adding features for feature-sake”. I agree. The “Rails is opinionated software” idea is clearly lost as it’s trying to embrace everything and has turned into a playground for some people (not the entire team, to be clear) instead of a framework that shapes the way web applications are created (that paradigm is shifting and meanwhile Rails is messing around with CoffeeScript and SASS).
One example of this “playground theory”? Releasing a piece of crap like the assets pipeline, clearly rushed and so fucked up that it makes me think if it’s the worse thing I ever had to use to build software, occupying a honorable spot besides the Struts framework, ASP and JavaServer Faces.
The main problem, in my humble opinion, is: Rails has turned into bloatware. I see the problem from two angles: as a potential contributor and as a user of the framework.
As a contributor
Rails has so many things included by default now that the code is really big. I tried to understand it some time ago and got quickly frustrated by the massive amount of coupled code and features that distract you from the main workflow of the framework. Yes, I could probably just get some ticket and solve a bug, but I like to understand the whole before going around throwing code like crazy to get some commits in. OSS activists will probably bash me for this, calling me lazy, but it’s the way I work, sorry.
The solution? Well, my suggestion is this: the rails gem should contain only the core, the request processing cycle and hooks for the other parts to hang in (ORMs, template engines, other gems in general). It already has this in some form, a framework called Railties, but all the things that hook into it are still in the same codebase, divided in a few other gems.
The asset pipeline is a main offender here and the easiest example to bring to the surface. This thing should *really* be into its own gem and out of Rails. It could be included in Rails’ default Gemfile, I don’t care, but please do not throw more code into the mess. I won’t even start the discussion about the quality of the pipeline per se, but I digress. If you want the default approach, the one the Core Team chose, just generate a full app and install de default gems. Otherwise we could have a lean application generator that remove all the uneeded dependencies without hacks. Better yet if that one could be the default.
If my memory isn’t failing me, I believe Merb did things this way. Besides lessening the burden on contributors it should force people to write decoupled code, something the Rails Core Team has been improving on for some time now, by the way.
Yes, I know Rails included extra things like ActionMailer and ActiveRecord from the beginning and they’re independent gems. As I said before, I’m fine with default choices, but I also think that Rails’ starting point should be a lean and simple mini-stack that could be easily incremented as the user needs it to be.
As a user
People who are experienced with Rails tend to forget that beginners do exist. Most of the so called “Railers” I know see themselves as a kind of superior being surfing the waves of awesomeness, forgetting that legacy must be supported and new people will try Rails. Funny thing is that the developers that use Rails as a mere tool (what it is) see this issue clearly, while people that see it as a religious cult dismiss it.
The first issue is legacy. Rails completely ignore this (as is common with frameworks in so called “non-enterprise” ecosystems) and makes no effort to support people that work with legacy code. The community itself fails hard at this, as we don’t even talk about that as we should. Think about how rare it is to see a talk about legacy applications on conferences in contrast to the plethora of talks about new features/libraries or how you should be writing your code. We fail hard here.
The second issue is that, as of today, Rails is incredibly hard for beginners to learn and use effectively. It’s slow, has a freaking unbelievable amount of dependencies right of the bat (this can be normal down the road, not by default), it’s cumbersome to set up (don’t you love some gem version hell?), it’s not quick to get up and running anymore. I usually joke that the “15 minutes blog” today should be called “the 1 hour and 30 minutes blog”. That’s not to mention the big disparity between the official literature and documentation (“the DHH way”) and the way real Rails apps are developed.
It’s hard for people who already knows Rails to imagine how it is to begin with the framework today. I’ve seen beginners trying it and it was ugly. Think about how many unrelated things someone has to go through to understand a simple “Hello World” in a default Rails application today.
The Rails framework should really get trimmed down. Non-fundamental trinket should be separated and, maybe, we could have two application generators: a “lean” (maybe just ActionPack and Railties, something like that) one and a “full” one. That way it would be a lot easier to grasp the framework code and contribute while allowing newcomers to taste the goodies gradually, learning instead of being drowned into a lot of concerns that really doesn’t relate to the core of developing a well built application.
EDIT: Yes, the title of the article is harsh and I recognize it does not reflect what I wanted to suggest here. It was wrong and tabloid style. It was chosen out of frustration, which shouldn’t be a reason to do it. The intention of the article is to spark a good discussion, not to be alarmist and accusatory, which the title makes it sound like.