We've taught hundreds of beginners new to Rails, and we've found that beginners want to learn about all the alternatives - it's like they have to survey the entire landscape before starting. No matter if we're teaching TestUnit or Rspec, someone will ask about the alternative. It's so easy to get side-tracked into evaluating alternatives and just get overwhelmed with the options.
What we've found works is this:
1. Beginners need a curated stack by someone they trust. "Here, this is the stack to learn from; stop wasting time evaluating and get started."
2. Learn about the people, personalities, and community that make the tools. Understand the reasons for their creation; keep up with the conversations.
#1 from above gets beginners unstuck, while #2 will allow them to slowly evaluate different pieces of the stack over time. It's important to understand the "why", not only the "how".
For our courses, we use a mix of the two stacks. For our intro to Rails course, we use: erb, sqlite in dev and postgres in production, fat models and skinny controllers. For our intermediate course, we use haml, rspec, postgres. And finally, for our advanced course, we use "outside in" BDD with Cucumber and introduce the concept of service layers.
We've found this to be a great approach to introducing newbies to the "37 Signal stack" and growing them into the "Prime stack". The goal is to let them figure out their own preferred stack over time, and be productive no matter which stack is in front of them.
> 1. Beginners need a curated stack by someone they trust. "Here, this is the stack to learn from; stop wasting time evaluating and get started."
That's supposed to be what Rails itself IS, right? Isn't that the point of it being "opinionated", it's supposed to BE the curated stack from someone you trust.
If it's failing, that's a problem.
It certainly is frustrating when you're trying to get the actual Rails stack to work and can't figure out why it seems so hard and someone tells you "Oh yeah, despite the Rails documentation telling you to do it that way, nobody actually does it that way."
This is a huge problem, and it's even worse because of the great point Klabnick makes about the vocal maybe-minority. When somebody says "nobody actually does it that way", they may mean that nobody who writes blog posts actually does it that way. It's very difficult to tell the difference between things nobody is doing and things nobody is bothering to talk about doing.
Personally, I find the default Rails stack is completely fine for everything I need. I'd not even heard of half of these options in the "alternative stacks" in TFA and the comments here until today. OK, I'd heard of HAML and the other unit testing frameworks, but that's it.
I don't think there's really a big issue here. People could just as easily get distracted by all the different npms in node.js, or the different technologies in the enterprise Java world.
My point is that it doesn't matter much which stack you pick. The default stack is not failing. The fail is being overwhelmed by choice, when it doesn't matter in the beginning. What matters most is having a good teacher, who choses a stack for you to learn with.
Once you develop your own taste, then you can refine the specifics. But don't get stuck with analysis paralysis in the beginning.
When I learned Rails, I was also learning Ruby. (This was 6 months ago.) (As a matter of fact I was learning what programming really was...)
Learning MiniTest/Test::Unit first I would say is a much better approach because you get to focus on the language, which is at the end of the day, the reason Rails is so special.
I read somewhere that someone decided to teach Rspec because it had "less" metaprogramming than a Test::Unit definition.
But in retrospect, it may have been really easy to begin grokking metaprogramming if we had explained that naming something:
class UserTest < TestUnit::TestCase
would end up looking for the User class because of the way it was written. (I believe Rspec does something like this as well but because it deviates from Ruby...it's harder to explain.)
What we've found works is this:
1. Beginners need a curated stack by someone they trust. "Here, this is the stack to learn from; stop wasting time evaluating and get started."
2. Learn about the people, personalities, and community that make the tools. Understand the reasons for their creation; keep up with the conversations.
#1 from above gets beginners unstuck, while #2 will allow them to slowly evaluate different pieces of the stack over time. It's important to understand the "why", not only the "how".
For our courses, we use a mix of the two stacks. For our intro to Rails course, we use: erb, sqlite in dev and postgres in production, fat models and skinny controllers. For our intermediate course, we use haml, rspec, postgres. And finally, for our advanced course, we use "outside in" BDD with Cucumber and introduce the concept of service layers.
We've found this to be a great approach to introducing newbies to the "37 Signal stack" and growing them into the "Prime stack". The goal is to let them figure out their own preferred stack over time, and be productive no matter which stack is in front of them.