Rails has Two Default Stacks

Same here. In aggregate, I must have spent at least a two full days getting therubyracer and libv8 working in various environments.

As a recent Java refugee, one of the things I find most painful about Rails is its dependence on native code libs. It's really a lot of work to get the dependencies sorted out, especially if you have several platforms to support (say OSX for dev, and multiple Linux flavors for staging/prod).

One thing I learned (the hard way) is to heed the advice that "rvm requirements" offers. If you install the libs that it recommends before trying to install your gems, things will go more smoothly. This may sound obvious, but when you're installing Ruby, RVM, Rails, Apache, etc, it's easy to overlook the instructions.

Consider "Rails for Zombies"[0].

[0] I teach/tutor Rails programming, and my students have found this resource particularly helpful.

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.

"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.

Micheal's Rails Tutorial was my first step in to Rails. I took Micheal's suggestion in the tutorial and spent a few days getting the basics of Ruby.

What Micheal focuses on is teaching you a few things he considers essential to the Rails ecosystem - git, Heroku and RSpec ( He mention the Test::Unit alternative too). I have learnt a lot from his tutorial and this is where I point others new to Rails to go to.

Also, it is better to get acquainted with git while working on a (dummy) project than trying its commands in a vacuum where one doesn't understand its power.