

Has Rails jumped the shark? - cageface
http://cageface.blogspot.com/2010/02/has-rails-jumped-shark_23.html

======
jpcx01
I ditched rails long ago because it's simplicity was an absolute nightmare
when you actually wanted to build something that wasn't a clone of basecamp.

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.

~~~
jamesbritt
"From my experience so far, Rails3 is a breath of fresh air."

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.

~~~
jpcx01
Yup, tried them all (merb was the one i landed on for core dev work). So far
Rails3 seems much better than all of them.

Community, documentation matter. Also having an active core team. Rails 3
seems like the best of breed web framework for now.

------
mhartl
It's too bad the author doesn't appear to have (virtually) attended the recent
Rails online conference (<http://en.oreilly.com/railswinter10>). I don't think
anyone who did could possibly think that Rails is going to do anything but
totally crush going forward.

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
    

will automagically use RSpec instead of Test::Unit.

~~~
aditya
You can do script/generate rspec_model User with 2.3.5 right now.

~~~
mhartl
Indeed; see

[http://www.railstutorial.org/chapters/modeling-and-
viewing-u...](http://www.railstutorial.org/chapters/modeling-and-viewing-
users-one#sec:database_migrations)

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
    

for RSpec vs.

    
    
      $ script/generate model User
    

for the default Test::Unit. In Rails 3, they will both simply be

    
    
      $ rails generate model User

------
dougp
The only extra "configuration" I have experienced with rails 3 is adding
routes as I used to abuse the default routes. But yes they decoupled a lot of
things but it's not like you have to require them through xml config files
there is no change in set up. It still works as usual in the default
configuration This is just link bait.

------
jeremymcanally
He does realize that Rails required well over half those things in versions
lower than 3, right?

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

------
knuckle_cake
tl;dr: Author has hurdle updating app to Rails 3, so Rails has now jumped the
shark.

~~~
icey
Yeah... I'm not terribly sure why this submission is getting upvotes - having
a hard time installing a beta (and I guess the way Rails is organized?) is
eons away from Rails jumping the shark.

------
tptacek
The author asks whether his metrics (number of gem dependencies, number of
auto-generated file, and length of stack traces) are meaningless. This
commenter has an answer. It is, "yes, those are meaningless metrics".

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.

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

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.

------
jdminhbg
I tweeted a joke earlier today that with Rails3 we have to go from complaining
about Rails being monolithic to complaining that it has too many dependencies.
Right on cue...

~~~
sunkencity
What I like about rails is that I don't have to build my own frankenstack of
ORM, templating system etc. It's all in there, and the things work perfectly
together. If I have special needs for components I don't use Rails, I (mostly)
use compojure instead.

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.

------
jrockway
Sounds like the author should just go back to PHP. No need to worry about
excessive abstraction there.

~~~
cageface
I've been coding Rails apps since 2004. Java before that. Never did the PHP
thing.

