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.
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.)
I am a relative newcomer to rails (1 year) and web programming in general. I stumbled across Michael Hartl's excellent tutorial and fell in love with ruby and rails right away, and shortly thereafter developed a deep-rooted hatred (well, strong dislike) of rspec. All of the fun I gained by using ruby was sucked out of me by rspec. Months later I decided to try testunit and in retrospect I wish I hadn't waited so long. After an hour or so of toying with it I knew it was the way forward as I am someone who wants to write test code that is just ruby.
I still recommend Michael's tutorial to anyone new to rails, but a '37 signals' stack version would be great.
I don't like the dsl. While admittedly it is entirely a question of preference, I find it more natural to write some ruby code and then assert(something). As an example, from Hartl's tutorial we have a test dealing with microposts:
subject { @micropost }
it { should respond_to(:content) }
I prefer writing:
assert @micropost.respond_to?(:content)
I haven't looked at rspec in a while and in the rspec example I don't remember how long the subject stays in scope nor would I remember to put braces between 'it' and 'should'. In the testunit example, it's all ruby, there isn't anything more I need to know.
It sounds strange, but even though the rspec example reads more like english, I find the assert more readable. Maybe it has something to do with the braces.
As a beginner, there are so many choices you have to make and so many things you have to learn. Rspec adds another item to that list. I would have preferred to learn to write tests with testunit and fixtures and then be presented with rspec, cucumber, factories, etc., a little later.
Have you used both rspec and testunit or just the former?
That rspec example looks like some sort of misguided language skeuomorphism. "If I name this method 'it' and this one 'should' and this one 'subject', I get something that sort of looks like English if you read it out loud while skipping the symbols! Isn't that neat?"
Well, no, it's a horrible idea, because in English those words would imply a certain syntax tree, while the actual syntax tree in your DSL is completely different, and those words have completely different roles from the ones they have in English. So you have something that superficially looks like English if you take care to arrange it just right, but in fact works in a completely different way from how you know English to work.
It's like having a picture of a sliding knob in your application, except instead of sliding it you're supposed to click it, and it's actually used as a tab switcher. And you put a denim texture on it.
Fair. I can definitely appreciate the DSL argument. Rails has a rickety enough learning curve as it is, and introducing rspec at the outset is certainly debatable.
For what it's worth, I would definitely not consider the rspec syntax in that Hartl snippet to be a particularly legible example. The code provided in another comment is a much better representation of good style, IMHO.
rspec has some redeeming qualities that were luckily ported to minispec, especially the let-syntax. Once you grok how it works, its a very nice way to setup complex test data that has minor differences.
assert, in my opinion, has the distinct advantage of being immediately recognizable as a special thing while should reads kind of informal.
Wouldn't say `let` is so much better than `def setup` as a newcomer. `def setup` is simple and powerful enough and after a while you begin to wonder whether something like `let` exists.
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.
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.
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.
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!
But if you care about Rails uptake, aren't those bad things?
People don't like being confused. People don't like feeling stupid. If their initial impression of a system is "this is confusing" or "this makes me feel stupid," many if not most will simply go look for an alternative that isn't confusing and doesn't make them feel stupid, even if that alternative is inferior in other ways that aren't immediately apparent to the newbie.
I agree with you, which is the reason why I think PHP is still way more popular than Rails. Cut-and-pasting scripts from Google searches is a terrible way to make code, but it works and it's a lot easier.
I agree with DHH that Rails shouldn't be dumbed down (see his Railsconf 2012 talk https://37signals.com/svn/posts/3171-keynote-by-david-from-r...). Cooking with Rails is like cooking with a real oven, not an easy bake where the end product tastes terrible. Somehow new people need to know that Rails is a real framework that can burn you if you're not careful.
I think the fact that the starting point for php is an html page is a big deal. Whether or not its a good thing to replicate that (and things like that) is debatable but its not just about cutting and pasting from Google.
You can write PHP-style "the file is the html page" code in Ruby with .erb files and mod_ruby. It's no harder to set up than PHP (granted though, most people who abuse PHP like that can't/don't do their own server configuration).
I can't think of anyone though that promotes that method of building websites anymore though, even PHP proponents advocate some flavor of web framework. It just happens to be an easy entry point for using PHP, and once a new developer has built some project momentum for the first time, they're reluctant to start over with something new.
Of course, and that starting point encapsulates much that is good (easy to extend HTML by mixing in some code, quick to get started, zero deployment hassles) and bad (easy to mix content and code, easy to start without thinking about the bigger picture or planning your app, easy to make mistakes like exposing your db password to the world because of a permissions issue say) about PHP.
I think the point is that you can ease in to that with PHP - you can be as dynamic or not as you want. Many (many!) people started with PHP just to add a contact form to a site, or make a dynamic copyright date in a footer (or just to do common footers with include()). Rails/Grails/Play/CF/etc assume you want to do a lot more, and force you to do things their way - integrating a tech in to an existing site is really problematic outside of PHP, because most other webdev tech is 'full stack'.
we a should all use flash, it is the most popular, more so the java!
gosh.. im trying to prove you're comparing apples with bananas and now i find out i should be coding in Adobe Flash (tm).
</joke>
anyway.. i believe php is only marginally more popular then rails, for stuff that involves "web app development". that's what rails made is for. php is used a lot for ftp-ing scripts to cheap webhosting, something is done a lot less with rails.
Something like this would be very appropriate for a Rails Guide. We already have an introductory one, an 'intermediate' and 'advanced' one would be helpful.
> 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!
Why is that normal?
I can say with some certainty that when I was deciding between Django and Rails, (and, subsequently Python/Ruby) there was a clear and obvious superior choice. (Hint: not Rails)
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.
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.
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.
> 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.
But MVC, a templating system, and ActiveRecord/ORM are not obstacles to learning Rails, so much as they are the whole point of learning Rails. Rails exists because these design patterns are so powerful and well-established that we all wanted a way to get them "out of the box" instead of having to roll our own implementations of them.
Rails is not a good starting point for beginner web developers who don't understand these software design patterns and aren't interested in learning them. If your goal is to just start making websites, like right now, then clearly something like Sinatra is a better choice.
This breaks down as soon as you have a form, which is basically the next step. While the 'hello world' might be smaller, you outgrow it immediately. Whereas
$ rails new my_app
$ rails g scaffold post title:string body:text
is still easy to copy/paste/type from a screen, and gives you a lot more to start with.
I realize there are differences in opinion, but I started programming seriously about 6 or 7 years ago, and I started with ruby/Rails.
For me the scaffolding generated too much to easily digest. And separating everything into models/controllers/views is fantastic for a production app, but almost incomprehensible for a newbie. Veteren developers still argue about whether something should go in a model/controller or some other layer, how is a newb supposed to handle it?
In addition you can build sinatra apps without even talking about hooking up a database.
If you're trying to jump in on the deep end and build an MVP, rails is probably the way to go. However, if I really wanted to teach someone to understand what they were doing without being intimated, I'd start with sinatra.
If I'm doing a 3 day engagement, we don't mention scaffolds until after they've hand-built all the code. If you're doing a 8-hour introduction, then yes, you need to use the scaffold.
There is no stack for sinatra, but there are certainly stacks on top of sinatra that don't take the Omakase-approach[1]. This has several benefits: they expect users to make decisions early on and to get informed about the components they use. With Rails, you generate a default stack and have to find your way around and then - potentially - have to learn the replacements. The upgrade from "basic" to "prime" is costly and often - just for that reason - is avoided.
This is much to the harm of components that might be a better fit for a project: I still believe that Sequel is a much better ORM for people that care about their SQL database and I frankly find it underused in the Rails world. Outside of Rails, its actually rather common, because it has a lot of merits.
I found teaching Padrino strictly better than teaching Rails (I do both), because you can teach it component by component and the missing "standard" stack is one of the reasons. Its much easier to teach it "the hard way".
[1]: Obvious, shameless plug: http://padrinorb.com , now with more development speed.
I suppose there are different types of beginners to Rails. I can appreciate that I'm not the standard beginner -- I come from a web development background, so certain aspects of learning Rails were frustrating to me because I just wanted to see what was going on under the hood.
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.
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.
> 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.
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.
That says to me that understanding bundler is REALLY important.
If someone understood how bundler worked, there is NO reason therubyracer, twitter-bootstrap-rails, libv8, or any other gem should get in the way of upgrading (say for example) from Rails 3.2.5 to 3.2.11. `bundle update rails`, then check in your new Gemfile.lock
That should change nothing but Rails and rails' own upstream dependencies (not any of the ones you mention). And indeed it did that for me on a bunch of apps. If you're going up a minor or major Rails version, then your other gems (like say twitter-bootstrap-rails, hypothetically) might not be compatible with the new rails version, and you might have some dependency hell.
But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.
> But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.
Right, but it DID happen. Updating the Rails version updated the versions of other gems too. I know what you're saying, but the reality was different.
For someone who has written dozens of applications and has already experienced such pain, why would they head straight back into it instead of starting with the best tools?
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.
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.
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.)
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).
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.
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.
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."
Edit: I don't to sound like a contrarian or prove anyone wrong or something. I'm certainly not the person to do that. I just read some of the comments here that seem to overestimate the distance between the two stacks in the article.
The stacks in the article aren't very different and few of the comments here seem to reflect that.
Erb vs Haml? Not much of a switching cost, especially since they can be used in the same project without sweat. One is HTML with <% %> tags, the other is a less familiar nested syntax to generate markup.
Mysql vs Postgres? For most CRUD, the same Active Record queries pretty much work, and the shortcomings are due to Active Record being underwhelming compared to its alternatives. Someone that cargo cults Mysql vs Postgres probably isn't locking their schema/queries into one or the other because staying close to Active Record doesn't really let you do that.
Minitest vs Rspec? Tests would be annoying to rewrite, but testing layer differences don't really distinguish a Rails app. Especially since you can write almost line for line equivalent code in Minitest and Rspec.
Fat models & skinny controllers vs skinny models&controllers + service layer? Here's the first real difference on the list because it actually changes the design of the system, not some ancillary component.
So,
> How many parts of Rails can you swap out before it stops being Rails?
I think we can stow this question away until there are more divergent, popular alternatives to the default stack which I'm looking forward to in time.
For instance, I think we will start seeing more deliberate functional designs that decouple models from Rails (to make testing not suck, for one). And I wish Active Record alternatives were far more popular in the Rails community.
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...
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.