

Rails Went Off The Rails - petercooper
http://gilesbowkett.blogspot.com/2012/02/rails-went-off-rails-why-im-rebuilding.html

======
erichocean
What a great read. I dropped Rails five years ago, and hadn't really caught up
on what happened with it (just heard the rumors).

Reading about the whole Merb/Rails 3 debacle was a huge _deja vu_ experience.
I come from the SproutCore world, and somehow we ended up with the author of
Merb running our project (despite NO previous experience with either
SproutCore or application frameworks in general).

Anyway, long story short, I think this quote about sums up what happened with
SproutCore:

> Going back to the larger issue, Rails definitely went off the rails.
> Cleaner, more modular APIs are an important goal, but they're way less
> important than speedy development, a modern feature set -- why is Rails not
> staying up to date with HTML5 the way it did with Ajax? -- and, above all
> else, programmer happiness. The Merb integration rewrite was a giant, time-
> wasting threadjack with only a few small payoffs, and DHH, who wrote two
> whole books about why you should turn down feature requests, should have
> nixed the whole thing.

I'm still not sure that SproutCore will recover from the damage, which has
been extensive (unlike Rails, which actually _did_ release Rails 3,
"SproutCore 2" has been completely abandoned, and the changes made to
SproutCore 1 to support SproutCore 2 have caused huge problems).

------
ajsharp
Glad you published this Giles. I really think you hit the nail on the head in
your criticism of rails, and not necessarily ruby. I think some of the
framework decisions in the 3.0 release were kind "abstraction for
abstraction's sake" moves. In other areas, I think the framework has pushed
beyond what the language is capable of handling in a reasonable manner, from a
performance perspective (I'm talking about development efficiency performance,
not production performance).

No doubt, these features were implemented with good solid principles in mind.
But, imo, at this point in Rails' lifecycle as a framework (something that has
been in public release for 5+ years) performance (both production and in
development) should have held more weight in the decision-making process than
doing things for what appeared to be because they were the "right" things to
do.

For one, the startup time of the framework is just, atrocious. If it takes me
15-30 seconds to boot up the framework (and on my quad core dual processor 8gb
ram MBP running a small-to-medium-sized project, it does) just to run one
test, that is just plain ridiculous. A lot of that time is spent loading the
large dependency graph of gems with which most new rails apps these days are
packaged. I _think_ this trend -- rigorous packaging open source library code
as a first-class dependency, instead of writing it yourself, or snapshotting
that actual code in your SCM -- is a good thing. But I think the performance
characteristics of the ruby language, _and_ of the ruby community, make trying
to cram 150+ gems into the load path and then require all of them, serially,
in a single thread, unacceptably slow for modern web development.

I will say that I think the situation has improved quite a bit more recently,
and the focus seems to be honing in more on development performance, but it
might be a tad too late for me. I'm focused more on building api's than I am
building "web apps". For that, sinatra is just a much simpler, faster and
elegant stack IMHO.

------
pkulak
I think a Sinata + Sequel app is still a pretty damn fine way to go. Ruby is
still a great language, and I still like it better than JS, just not Rails.

------
ramblerman
Not sure if I agree with everything stated here, but a great read.

I've been moving backwards through some of the posts, really liked this :
[http://gilesbowkett.blogspot.com/2012/02/secrets-of-
supersta...](http://gilesbowkett.blogspot.com/2012/02/secrets-of-superstar-
programmer.html)

------
cicloid
Somehow sad, but, any good developer handles some extra tools besides Ruby, at
least the developer happiness culture is mainstream.

Let's see how much it takes to get screw all over again.

------
heretohelp
Independent of the community and boundary pushing aspects of Node.js, I don't
recommend it to people because it commends an incredibly irritating pattern of
programming.

I get the impression that Dahl knew ahead of time that he was working with
some serious limitations with event-driven programming such as it is on V8.
He's a smart guy, he had to have known how much cleaner things like Erlang
are.

At the same time, we have a bunch of zealots who've never done any event-
driven programming on C, Lisp/Scheme (CPS), or on Erlang who think it's the
best thing since sliced bread because it's FAST.

I'd argue that the main advantage of Rails wasn't "speed" and I don't think it
ever was.

Rails' main advantage was making the _human_ fast. Node.js reeks of misguided
pre-optimization to me. It doesn't make building a product any faster.

Could just as easily build a web app with CoffeeScript + BackBone + Flask
(python), or Clojure, or Ruby, or whatever.

The single-page app paradigm needs to be pushed in terms of integration and
productivty in order to get adopted. The backend involved is almost
immaterial, it's just a JSON API conceptually.

So why are we pretending Node.js is somehow a successor to Rails when it
doesn't actually improve on anything in terms of product or performance?

~~~
iamgilesbowkett
Because it's more fun.

~~~
heretohelp
That's what I write Clojure for, and end up with something faster and cleaner
anyway. I even get to use Netty if I want.

It's a bit misguided to make it a matter of taste anyway. There's nothing to
_discuss_ if you're making a decision on the basis of "fun". If you don't have
rational reasons for making the judgment call, then you don't have anything of
substance to actually share _about_ the stack.

~~~
dmix
Completely agree.

And I know Javascript way better than Clojure.

But building an app with Clojure feels like I'm writing high quality code.

Writing Node feels hacky and I get an uneasy feeling with it for some reason.
I've never liked nodes callback-driven async approach to development.

This post summarizes my feelings towards Node better than I can:
<http://dosync.posterous.com/22397098>

