Not sure I agree that there are two default stacks. There is one default stack (what you get from “rails new”), and there is the “custom stack” (which is obviously different everywhere you go). The “service layer” he describes, in particular, is not part of a default stack because it’s going to be implemented totally differently by everyone.
I’ve used HAML/PostgreSQL/RSpec/Cucumber on all my projects for the past couple of years – it does feel like a default for me, with or without DCI/service layer/etc. There is definitely a big minority of folks like myself who have done the traditional Rails stack, felt the pain, and worked with/learned from others to come up with a suitable alternative. Steve raises some really good points about forcing these choices on others who haven’t experienced that pain firsthand, though.
I guess I don’t work on a lot of apps, I work on one really big one at work (erb, mysql, rspec, sass) and a personal project (erb, postgres, test::unit, sass). Any new projects that I begin I would definitely want to use erb/postgres/rspec/sass for.
At work we have some service layer, but I don’t really know if it’s “DCI”. I guess I need to learn more about what that’s all about.
I’m teaching Rails to some fellow students at my university this year, a sort of unofficial student-run course thing, and some of these points have definitely rung true for me. I’m not a fan of a lot of things the 37Signals stack does, but on the other hand I don’t want to spend our entire first workshop setting up the project, the workshops are voluntary and having the first one be so dull is a surefire way to cause loss of interest early on.
Does 37signals really never use a service layer? I guess Basecamp and their apps aren’t extremely complicated so they would need that, but I still found it was a great way of clearly defining which parts of the app do what things.
What are the steps to getting started with the other stack?
I usually fork one from the RailsApps project or use their excellent rails-composer tool. See: