
Rails has Two Default Stacks - steveklabnik
http://words.steveklabnik.com/rails-has-two-default-stacks
======
milesf
Using Steve's definitions from the article, the tutorial I usually point
people to is Michael Hartl's Rails Tutorial <http://ruby.railstutorial.org/>
which uses the "Prime" stack. I believe I read somewhere that Michael was
going to come out with a "37 signals" stack version as well.

One message I'd like people to understand when they're starting out with Rails
is that it really is confusing, and that being confused and maybe even feeling
stupid is normal! I remember hearing people talk about how easy developing
Rails applications was back in 2006, but what I didn't know was it was easy
relative to other web frameworks at the time. It's still hard.

By analogy, if you're an intermediate skiier and you visit a well-groomed
mountain with great, powdery snow you could say "this mountain is easy to ski
on". But if you're just learning to ski, and you follow everyone else up the
lift to the top of a blue run, it's a terrifying experience trying to get down
the slope without breaking your neck. To add insult to injury, it's
discouraging to see everyone else gliding down the slope while you're
shimmying down on your butt because when you try to stand you lose control, go
way too fast, then crash. New skiiers need bunny hills, then green runs, then
blue runs.

I still don't think there's an established "bunny hill" and "green run" track
for learning Rails. Sure would like to help someone create one.

~~~
sergiotapia
I disagree that using Rails Tutorial as a beginner resource is the way to go.

In fact, I used that as my first resource for learning Rails! Here are some
problems I found with it:

1\. It teaches you Git along with Rails. Who cares about source control at
this point? Remember: This is for a newcomer to Rails that just wants to learn
how to create websites using rails; don't confuse me even more.

2\. It teaches you how to deploy to Heroku. Again, don't care at this point.

3\. It teaches you how to deploy your code to Github. Once again, NEEDLESS
INFORMATION AT THIS POINT! :P

4\. Unit testing; Ugh, I'm 100 pages in and I barely have a grasp of what I'm
doing, and I'm STILL barely 1 controller with 2 actions in.

\---

There are other alternatives that I think are better for a newbie.

I will concede that Michael's tutorial IS GOOD, but just not good for someone
brand new to ruby and rails. I find myself re-reading Rails Tutorial and The
Pragprog Agile Rails book every couple of weeks, discovering new things I
missed.

 __That's __the way to learn, keep reviewing things.

~~~
milesf
Interesting. I might be persuaded to recommend something else. What
alternatives do you think are better?

~~~
sergiotapia
I haven't found a good starting point. The two main contenders I've read in
non sequential order:

1\. Micheal Heartl's Rails Tutorial. 2\. Pragmatic Programmers Bookshelf -
Agile Rails 3.2 (4th Edition)

Both are a good start but delve far too much into unit testing with the
horrific RSpec. When you're learning something new, you don't want to muddle
with learning a DSL on top of things.

------
natural219
How do these two options stack up to just not using Rails and using something
like Sinatra instead for beginners? When I started with Rails, I spent 2 days
figuring out the standard web framework functions / workflow, and then I gave
up. When I picked up Sinatra, the pieces were small enough that I could learn
them individually, master them, and learn how they were put together. Then,
when I came back to Rails, I had a better understanding of the underlying
technology and I was able to be much more productive.

Just my two cents.

~~~
steveklabnik
With Sinatra you have absolutely no guidance as to what's good and what's not:
there's no stack at all.

I, too, am a bottom-up learner, but most people (in my professional
experience) are not. Look at the success of Rails Girls, for example:
beginners get waaay more excited and engaged by Getting Something Up There
than they do learning the intricate details of HTTP.

~~~
learc83
>beginners get waaay more excited and engaged by Getting Something Up There

Yes! That's why...

    
    
        require sinatra
        
        get '/hi' do
          "Hello World!"
        end
    

...is so amazing for newcomers.

Even the file structure of rails is a bit too much for begineers. Everything
in one file is so much simpler for trivial beginner "get excited" apps.

Introducing someone to rails, they have to learn MVC, a templating system, an
ORM, and more.

~~~
benatkin
It's amazing for newcomers who like elegant code that can't be shipped. I'm
that way. Or, rather, I was, and I look back on that time fondly.

Other people who get into web development aren't impressed by such things, and
would rather see something like rails or WordPress which is shippable right
away and then can be built on top of.

Some programmers, especially the kind to hang around on HN, would rather not
work with people who don't understand the entire system they use. I often hear
people say they wouldn't touch WordPress with a 10-foot pole. They are
avoiding a huge part of the web development industry. This is a valid choice,
but some people don't even realize they're making this choice, and I wish they
would realize it so they could make sure that it's really what they want.

~~~
epochwolf
> Some programmers, especially the kind to hang around on HN, would rather not
> work with people who don't understand the entire system they use.

There's a reason for this. I've worked with people that don't understand how
things work and don't really want to learn. These people cause enormous
amounts of damage in any system that contains architecture beyond php in the
webroot and algorithms beyond brute force.

You let one of those people on a large production database, it's game over.
They will run queries that miss all the indexes. They will remove constraints
because they don't understand why they exist. They will use flat files in
place of a database because the database is scary and then not understand why
stuff goes missing in the multi-server production environment.

These people are a liability in a project beyond small scale. They are the
same people whose wordpress blogs are repeatedly hacked.

------
qrush
This is one of the strongest arguments I've seen for simply starting with the
"default" stack. Move to other stuff when you feel the pain. If you're
teaching or just starting off with Rails, don't use the "Prime" stack stuff
until you really need it.

~~~
steveklabnik
One of the things that got me thinking about this was the recent security
issues. I was helping people on Skype upgrade their apps, because they were
new, and they got into Gem Version Hell. Only pulling in fancy gems when you
need it helps when you _really_ need to upgrade, and you're not stuck figuring
out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example,
obviously, it could be any combination of gems) all refuse to get on board.

If you're using the default stack, the number of dependencies you have drops
quite a bit.

~~~
fendale
> twitter-bootstrap-rails, therubyracer, and libv8

Those three gems recently caused me a world of pain. I've been in and out of
Rails development since the 1.x versions (more hobby projects than
professional development), and once getting going was as simple as 'gem
install rails'. Getting the asset pipeline to work changed that totally - I
get the advantages of the asset pipeline, and once you get it working and all
your gem dependencies sorted it is fine, but it took me a while to get there.

~~~
steveklabnik
I don't even use therubyracer at all any more, personally. It's not generally
neccesary; just {brew,apt-get} install nodejs and be done with it.

------
nnq
_This is quite different form the Python frameworks ecosystem_ : here most
"beginners" already know Python, or at least they already know how to program
having experience in something like Java, C# or C++. And because they already
have this knowledge, they usually ending up doing things "their own way", or
they already know what each piece is supposed to do before starting to play
with a framework that has all the pieces in it.

And "being explicit" rather than "convention over configuration" really helps
people make their own choices. When people bump into the limits of Django's
ORM, for example they quickly replace it with SQL Alchemy, when they do
something in Flask, they already know what the pieces they are putting
together do.

Rails culture seems very "top down", i.e. people start learning and doing
things by learning the stack as a whole and then about the options for
individual components. This leads to "elegant solutions", but tons of pains
for beginners that need to "swallow it whole".

I don't know which way is better, but I've always been attracted to the Python
ecosystem because I like learning things "bottom up", e.g. playing with all
the different pieces and then assemble them into a whole once I'm confident I
understand them.

------
nicholassmith
For the people who've ended up on the delta/Prime stack it's because they've
already _done_ the 37Signals stack, found where it works and where it doesn't,
learnt their lessons and found something that works better for them. The
problem is when they espouse it as the One True Rails Stack it muddies the
waters for newbies, and people who've been building quite happily with the
defaults and just need some more information.

Your choice of stack is great, and it's great you're passionate about it but
if you start acting like a giant dick about it you're actually dissuading
people from getting more involved, and that's not a good thing.

------
chipotle_coyote
Interesting observations. I tried to get back into Rails last year with
version 3.1/3.2 after being "away" since sometime when it was still at version
1, and while I've been somewhat successful at it, the choices -- not just
between the stacks but between the myriad of different "standard" gems -- can
be somewhat paralyzing. Do I use a a Twitter Bootstrap gem that will be easier
to manage but might be less customizable than using "pure" Bootstrap? If I
switch from ERB to Haml, do I worry about generator gems? Do I want to use
Devise for authorization or just use the built-in has_secure_password? Do we
love factories now, or hate them? I'm building a CMS-ish sort of thing and
it'd be nice to have an automatic admin system like Django does. RailsAdmin or
ActiveAdmin? Wait, these _expect_ that I'm using Devise, unless I change
something somewhere? Argh.

All of this is pretty simple _once you have preferences established,_ but
figuring out those preferences can be enough to drive you back to something
that, well, has less choices. (Like the aforementioned Django, although it has
its own issues with setup and documentation.)

------
endlessvoid94
Having overseen ~100 beginners, who didn't know how to code, evolve into rails
developers, I can faithfully say the following:

1) Beginners need to listen to one person's opinion and trust them

2) Learning about the people and community around your tools is paramount.

#2 will allow them to advance past whichever stack #1 places them.

There are, of course, other caveats. For example, when a beginner finds an
answer to their question on stack overflow, but the example code uses HAML
instead of ERB, they need to have a foundation deep enough that allows them to
at least recognize the code without feeling lost (or use those "lost" moments
as opportunities to educated them about that feeling, which is rather normal
for a beginner in anything).

Etc.

------
programminggeek
What would help Rails the most is probably some example projects. They could
be anything ranging from simple twitter clones to maybe full on e-commerce
stores or something. Build them using the "golden path" and maybe someone else
could build the same thing using the "prime" stack.

When I started the Obvious architecture, writing an example app made it
concrete and makes it a lot easier to explain particular details or structures
to people wanting to learn.

People love examples.

~~~
somlor
These example Rails app tutorials look promising:
<http://railsapps.github.com>

I'm still working through Michael Hartl's tutorial, but plan to work through
each of these afterwards.

------
blissofbeing
I seriously wonder why people still use haml over slim. Slim imho is the best
templating language around. It should replace haml in this so called 'prime'
stack.

~~~
tesmar2
Actually, having used HAML for a while, I got really annoyed with it and
switched back to HTML. I like the prime stack + plain old ERB.

------
smacktoward
_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
37signals Stack and the Prime Stack?_

How many parts of Rails can you swap out before it stops being Rails?

Maybe the simplest solution here would be to call the Prime Stack something
different. Even "Rails Prime" would work. Just some nomenclature that says to
people "hey, just so you know, what I'm going to talk about here is different
than what 37signals is talking about."

~~~
qrush
> How many parts of Rails can you swap out before it stops being Rails?

Rails is meant to be modular, it just doesn't stop being Rails.

~~~
antidaily
Actually the answer was 7.

~~~
untothebreach
I was going to guess 42

------
benatkin
This is such a clean mental model that I was skeptical. I started scrutinizing
it and found myself thinking about how it omits some deployment choices. I
realized that this is a good thing, because the development and deployment
choices have one big difference: development choices require rewriting when
you change them. [http://benatkin.com/2013/01/14/steve-klabnik-on-rails-
stacks...](http://benatkin.com/2013/01/14/steve-klabnik-on-rails-stacks/)

Thanks for this article, Steve.

~~~
steveklabnik
> This is such a clean mental model that I was skeptical.

This is a great compliment, thank you.

I mostly left deployment out because that's not part of Rails' domain: Rack
lets us not care about that when building things.

~~~
benatkin
I think it was a good choice to include PostgreSQL even though you can make an
app DB-agnostic with rails. It's one of the defining differences between the
stacks. I would really like to switch to PostgreSQL on a project I'm working
on for future development even though MySQL is working fine now, and this
makes me feel more confident about bringing it up to my team.

------
davidroetzel
I could not agree more. The defaults are there for a reason. There are
brilliant people out there building awesome software with those defaults.

When teaching rails, I always tell people to get familiar with the defaults
first then try the alternatives and make an informed decision to switch (if at
all necessary).

------
pjungwir
Coming from a web development background with experience using MVC in Java and
Python, I found Michael's Rails Tutorial was basically all I needed to get
started, even though I only came to Rails around the time of 3.0. I'm
personally really happy to have skipped over ERB entirely and gone straight to
HAML. But if I were teaching a web dev newbie, I might use ERB, since it still
looks like HTML. Better to keep a few things familiar while someone is
learning.

Perhaps Michael's book fills this space, but there may be an opportunity to
write an e-book on the Prime Stack, or at least fill in some things the Rails
Tutorial leaves out.

------
schiang
As a fairly new programmer (< 1 year), I think the best thing for a beginner
to do is to just pick a route and go with it. At the end of the day, both
stack are going to have a lot of similarities. It all comes down to personal
preference which will be determined after some time.

I started learning testing using rspec. Now I'm starting a new job where they
use test unit for testing. The transition has not been too difficult because
the difference between the two are too crazy.

If you pick one route and learn the basics, you shouldn't have too much
trouble switching over to the other.

------
tferris
This is a good post showing me once again how Rails evolved. I am also using
rather the so called prime stack and I am wondering that the prime stack is
not the default stack. For me it's total obvious to use HAML over ERB and
Postgres over MySQL and I don't get why these choices aren't recommended by
being default. Even CoffeeScript which has a wide acceptance and adoption is
something where no clear opinion arose if it should be in the default stack or
not. It offers many benefits but can bring also some heavy implications to
your web app (I don't want to start a discussion about CoffeeScript here).

However, I think that Rails is not a good start for beginners in web
development. On the one hand it's guiding you very well through its strick
conventions and teaching you very good structuring your app (MVC- and OO-wise)
but on the other hand all those abstractions and magic make you dumber.
Without a big framework like Rails you try to think yourself how to solve a
problem like getting the data from A to B. With Rails instead you just have to
follow the respective Rails convention and voila you are ready to go. Finally,
you learn Rails design patterns and best practices (or conventions) without
understanding why you are doing this. And since the default stack is by far
not the recommended stack makes it even worse. Because the newbie is in the
beginning too afraid to leave the default track. Giving him the option "to
just remove one line" to get to his preferred stack is the wrong answer
because if there's a default stack people in particular the beginners assume
that this must be the right way to do stuff and spent too much time fiddling
around with ERB, MySQL, CoffeeScript, etc. Instead it would be better to offer
a modular approach like Express, Sinatra, Web.py. I know that I can have the
same modularity with Rails too but a beginner gets another message and Rails
also wasn't meant being a full stack framework where -- we remember --
"convention is always over configuration" and thus also over modularity.

And even for advanced programmers I believe that Rails' time is over: the
monolithic approach is so 2005 and I realize nowadays that I just want to
start quickly something without an ORM, Coffee, etc. and decide later if I add
those amenities.

Maybe we are facing a new generation of web development where full stack
frameworks have no space anymore and David should rethink his Rails approach.

~~~
jshen
"all those abstractions and magic make you dumber"

It was the opposite for me. I had been doing java and php web dev for a few
years before rails was created. The first time I used rails (before the 1.0
release), all those abstractions were a revelation. I realized, oh, I've never
seen software structured this well before, and it immediately expanded my
understanding of how code should be structured.

"the monolithic approach is so 2005 and I realize nowadays that I just want to
start quickly something without an ORM, Coffee, etc. and decide later if I add
those amenities"

Software isn't fashion. First, in rails you can start quickly and not use an
ORM or coffee. I've written a whole lot of web apps in ruby over the years.
Many in rails and many in sinatra. In my experience, most of the times I used
sinatra I eventually wished I had just used rails because I nearly always
wanted many of the rails features over time and putting all the pieces
together myself was not the best use of my time. There has only been one case
where a rails app I wrote should have been a sinatra app.

~~~
tferris
Regarding your first point: but you weren't a beginner anymore when you
discovered Rails. You knew before how to control a raw DB without an ORM, you
understood the basic structure or components of a webapp. And I still believe
that those abstractions are also for a pro too heavy, hiding too much away,
making web apps unnecessary complex.

"First, in rails you can start quickly and not use an ORM or coffee."

But a beginner can't and even for advanced people I wouldn't call the rampup
time for a Rails app "quickly" anymore, those times are gone for a long time.

"I used sinatra I eventually wished I had just used rails"

Maybe you should give Express/Node a try -- the ecosystem paired with Node's
modularity makes me much faster than with Rails and maybe you realize how slow
you have been Rails, before.

------
nirvdrum
The prime stack is going to have some real problems as Rails 4 goes threadsafe
by default, as haml isn't threadsafe. I guess this won't be a problem for
those on process-based servers, but it's going to be an issue for those
embracing multi-threaded app servers.

~~~
mike_herrera
> ...haml isn't threadsafe.

Could you elaborate on this, please?

~~~
nirvdrum
It appears to swap out $stderr with a StringIO and StringIO isn't threadsafe
and then doesn't wrap it in a lock. It's been tripping up people in the #jruby
channel.

This is a gist from one earlier today:
<https://gist.github.com/be34c0a5666db0c83629>

------
angryasian
the rails community loves to introduce a dsl for every aspect. I couldn't
agree more in that, for a newcomer to learn ruby, and the rails framework.. in
some stacks they now have to learn haml, sass, coffeescript, and rspec.

~~~
sergiotapia
Probably why I haven't delved into RSpec yet.

"it should send message to owner and shave whiskers from monkey. also, make my
a latte."

That DSL seems like a _bit_ much and I don't feel comfortable letting it do
black magic things behings my back.

------
stevewilhelm
Which stack is better for more complex user interfaces?

We have a dashboard app that must integrate data from several models into a
single display that allow users manipulate the parameters to each specific
model independently.

------
bstar77
The vast majority of rails positions out there seem to prefer the Prime stack.
If I'm looking to make a career out of working in rails, then that's what I'm
going to start with.

------
mrgreenfur
Sounds a lot like ramaze or sinatra where you can BYO ORM, testing, layout,
etc...

------
TheSmoke
my rails stack:

\- erb for view templates \- postgresql for database \- rspec/cucumber for
testing \- skinny models, controllers, and a service layer

~~~
danso
Out of curiosity, why do you like rspec over minitest/minispec?

