Has Rails jumped the shark?
cageface.blogspot.com
cageface.blogspot.com
From my experience so far, Rails3 is a breath of fresh air. Easy to get up and running, and also easy to extend and replace the pieces you dont want. My current Rails3 app doesnt use any ActionView at all (used my own view system) and its working great so far. This wouldn't have been even remotely possible in Rails 2.3.
I'm curious to know if you've tried any of the dozen or so other Ruby Web frameworks, such as Ramaze, Camping, Sinatra, IOWA, Waves, etc.?
It seems that the things people seem so excited about in Rails 3 have been available since, say, Nitro, four or five years ago.
Community, documentation matter. Also having an active core team. Rails 3 seems like the best of breed web framework for now.
I think the author of this article needs to get out a bit and look around at the rest of the web framework world. Rails building on existing components is Not A Bad Thing, because it means that Rails has taken a decided turn away from being a monolithic framework toward being a set of well-formed but loosely coupled components. Light as a feather, stings like a bee, baby.
Looks like I'll be playing with Rails 3 in the near future.
Rails 3 will still have opinionated defaults; it will just be easy to swap them out for other options. Most newbies will still use the default stack,* but experts (who always insist on customization) will have a much easier time than they currently do.
* Readers of my Ruby on Rails Tutorial book (http://www.railstutorial.org/book) will use RSpec instead of the default Test::Unit. Currently (with Rails 2.3.5) this requires some fiddly configuration but---thanks to the modularity the article's author disparages---RSpec will feel like a default test framework in Rails 3. For example, by configuring Rails 3 to use RSpec, commands like
$ rails generate model User
http://www.railstutorial.org/chapters/modeling-and-viewing-u...
from my book for an example. ;-) But it requires running a special bootstrap script and has a different syntax from the default, i.e.,
$ script/generate rspec_model User
$ script/generate model User
$ rails generate model UserAnd it now generates 30 fewer files?
And the only reason you didn't get nasty backtraces before was that they cleaned the backtrace, which it looks it's not doing for that un-upgraded app?
Some people are such curmudgeons for no good reason.
1. The number of gem dependencies for Rails is an implementation detail, optimized for the benefit of people developing Rails extensions, and barely exposed to Rails developers. 80% of Rails developers couldn't tell you whether a method was defined in activesupport or activerecord, and those are two Rails dependencies that date back to the origin of Rails.
2. Since you don't have to edit any auto-generated file you're not interested in, the number of auto-generated files is irrelevant to you. Since the beginning, Rails has generated files that you're unlikely to care about; for instance, the only benefit I get from "schema.rb" is that I can make impressive printouts from it.
3. You can filter your stack traces, which is what you should do regardless of whether Rails tacks 10 lines to it or 100.
Has Rails jumped the shark? Maybe. I find myself reaching for Sinatra now instead of Rails, and I think the RESTful/Resourceful/multi-format idioms in modern Rails are overkill for most applications. But this article doesn't make a compelling argument about Rails.
Not true. If you're learning the framework, or trying to figure out what's changed, you won't necessarily know which files are relavant and which aren't.
I'm looking forward to the changes in Rails 3, but I'm sure I'm going to like using the default components that are most likely to work happy together.