Rails has two default stacks
Railsā greatest strength is āConvention over Configuration.ā Basically, Rails makes a ton of default choices for you about how things should be named, where they should go, and other things. This is why working with Rails is so productive for an experienced developer: just follow the Golden Path and everything comes together quickly. Itās second greatest strength is its āfull stackā nature: Rails includes everything that you need to get going. It does not attempt to be āminimalā in any way. Put these two things together, and a Rails app makes lots of assumptions about everything in your app.
But what happens when a significant number of people donāt use those defaults?
First, letās talk about the actual default stack. Since Rails is omakase, Iām going to call this the āOmakase Stack.ā Roughly, this stack contains:
- ERB for view templates
- MySQL for databases
- MiniTest for testing
- Fat Models, Skinny Controllers
There has been a āsecond default stackā brewing for a while now. Iām going to call this the āPrime stackā. This stackās approximate choices are:
- Haml for view templates
- PostgreSQL for databases
- Rspec/Cucumber for testing
- Skinny models, controllers, and a service layer
This is great! As David says:
That doesnāt mean patrons canāt express exceptions. Substitutions are allowed, within reason. So you donāt like test/unit? No problem, bring your own rspec. Donāt care for CoffeeScript as a dessert? Delete a single line from your Gemfile.
A considerable minority uses a stack like this. Itās important that the Prime Stack isnāt exact: you might not use Cucumber at all, for example, or maybe you donāt have a service layer. The important part, though, is that this is the new default you build preferences off of: a big group of people assumes that you donāt use MiniTest, you use Rspec, and the choice is Cukes or Capybara. This creates the āsecondary defaultā effect.
Dual Stack Ecology
So whereās the beef? Well, before I get into it, I want to make one thing explicit: I am not taking a position on which stack, if any, is ābetter.ā Iām not interested, at least in this post, at placing them into any kind of order. Thatās for another time. What I want to talk about here is about the effect that a second default stack has on the overall Rails ecosystem.
Looking at history, the Prime Stack was born from the Omakase Stack. A certain group of people noticed that they were changing a significant amount of the stack most of the time, and so the Prime Stack came into existence. Since this is a historical progression, many blog posts got written describing the delta: take āWaiting for a Factory Girlā, for example.
Here at thoughtbot, weāve had it with fixtures.
But wait! Then, years later, you get a discussion on how factories are bad. My own āWhy I donāt like factory_girlā is an example:
So thatās what it really boils down to: the convenience of factories has set Rails testing strategies and software design back two years.
Maybe a bit strongly worded. Anyway, the people who have created the Prime Stack also happen to be those who are vocal, blog a lot, and speak at a lot of conferences. Everybody loves a polemic. If I submitted a talk to RailsConf called āWhy Fixtures are :metal:ā this year, people would assume that I was being sarcastic. People always assume that things are slowly getting better: If the original advice was āuse fixturesā and the new advice is āuse Factoriesā and the newest advice is āuse neitherā⦠thereās no way that the āright answerā is āuse fixtures,ā right? Isnāt that so 2007?
For those of us whoāve been around Rails for a long time, this discussion is good, and interesting. I was able to search for that Factory Girl post by memory, because I remember reading it when it was posted. Iāve written tons of Rails apps in the past 6ish years, and formed my own opinions on what tools I want to use due to that experience.
But what about someone starting Rails today?
Beginners lose out
Someone told me earlier today that āStarting Rails today is like starting to watch a soap opera in the 7th season.ā Like most witty statements, thereās both truth and falsehood here. But, as a newcomer, how do you pick between the Omakase Stack and the Prime Stack?
This is the crux of the matter for me. If today, you tweeted that you were building a Rails app with fixtures, people would tell you to Stop It. I saw it happen this morning. This is again, because a very vocal minority of Rails developers use the Prime Stack, and are really passionate about their choice over the Omakase Stack. Thatās great.
The problem is this: it puts a pretty heavy burden on a new developer: they have to learn the Omakase Stack and the delta. At the moment when someone is new, and barely knows anything, we throw them into making more choices. This is the moment when theyāre least likely to be able to properly evaluate which option they need to choose. Itās not just āYouāre new to Ruby, now learn Rails,ā itās now āYouāre new to Ruby, now learn Rails, and RSpec, and Cucumber, and use this advanced modeling technique that we agree Rails discourages. Oh, and your only help is all these blog posts. Have fun!ā
As I said at the beginning of this post, Convention over Configuration is Railsā greatest strength. So when a new person starts, the first thing we do is tell them to do a bunch of configuration. Any reasonable developer could easily ask āIf these options really are so superior, why do I have to include them? And which do I choose? Iām drowning!ā
Helping People Build Better Apps
We all want to write better, more maintainable apps. And many people (including me) are trying to push the state of the art forward in this regard. But weāre leaving the majority in the dust. Rather than trying to push the boundaries by choosing new techniques, maybe we should be helping people get better at existing ones, too. Because we need both approaches. Thereās already so much to learn when building a Rails application, adding more gems and techniques to the pile just isnāt going to help.
Once those beginners become intermediate, then they can figure out how new techniques solve the particular pains that they feel while going with the default flow. But skipping straight to the tool that solves my pain without feeling that pain the first place doesnāt help, it just confuses.
Letās keep pushing those boundaries, but letās not require someone to catch up on a few hundred episodes before they can understand whatās going on.
If you read this post previously, the āOmakase Stackā was called the ā37signals stack,ā but David has pointed out that even if he didnāt work with 37signals, heād use this stack, so calling it that would be wrong. Iāve since changed the name.