Rails Went Off The Rails

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

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.

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.

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

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.

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?