I spent 4 years using Rails as a teaching language both inside and outside a 
local University. We stopped telling students that scaffolding even existed 
after two semesters. It wash't that, as you might except, we had a problem with 
generating code instead of doing work by hand. Instead we saw that encountering 
scaffolding as an early Rails concept led many students to develop a totally 
bonkers mental model about the framework and web applications. Scaffolding set 
them up to fail.

My general feeling after seeing it in action:
  
A: You're not doing a beginner any favors. This holds true for a number of 
other things that I'd love to see demonstrated long-form in the guides before 
the shortcuts are introduced. `resource`-style routes and form helpers are 
awesome time/LOC-savers when you know what they're doing. When you don't, 
they're dark and mysterious magic words that you dare not examine too closely.

When we teach student the Rails-style REST pattern conceptually, show them how 
to connect routes, controllers, and models themselves, then show them the handy 
time-savers provided by the framework they perform better and appreciate the 
niceties more.


B: the advantages of Rails in 2012 aren't the same as the advantages of Rails 
in 2005. In 2005 relatively few people writing web apps separated concerns into 
different types of objects, followed any particular organization pattern, wrote 
tests, or any of the the practices that made Rails seem like such a breath of 
fresh air. Now basically every app framework – regardless of language – follows 
these as best practices.  Routing, MVC, tests, are all important to highlight 
but they're par for the course.  Scaffolding may have had some use in 2005 – it 
showed you how to properly write Rails before there was a body of well-written 
apps to examine – but there are better solutions to this problem now.

The advantages in Rails today have to do with large, enthusiastic (although 
sometimes overly curt) developer community, the ecosystem of well written and 
tested Rails-compatible libraries, the collection of good instructional 
material both in the project itself (Guides) and from 3rd parties, and the fact 
that Rails is still one of the places were smart people are experimenting with 
different (hopefully better) ways of making applications.  

These are the things I'd miss if I was working with other tools and I think 
it's what we should focus on highlighting and improving.

- @trek

On Thursday, March 8, 2012 at 1:39 PM, Steve Klabnik wrote:  
> Every time I use that generator, I always regret it. It's just so
> easy, so tempting...
>  
> That said, it's something that Rails has had since the beginning of
> time, and was an original selling point.
>  
> That said, you could _still_ do the fifteen minute blog video, you'd
> just run three commands instead of one.
>  
> It would _also_ probably cause another internet shitstorm. I can see
> zillions of blog posts now. There's no such thing as bad press...
>  
> A big 4.0 release means a time to rethink old sacred cows.
>  
> Changing the guide would help new people, but removing it entirely
> would be better.
>  
> I like it. :)
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.



-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to