WTH is happening to Rails? I'll tell you.

But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.

1. jQuery quickly replaced prototype for most projects via the jrails gem. This just reflects the underlying reality. 2. Coffeescript as the default was a bad idea. This would make more sense in say a year from now. 3. Rails 3 active record w/ ARel is HUGELY better. I used to have to pull out find_by_sql every so often, haven't needed it yet in rails 3. 4. Bundler solves a whole raft of annoying dependency issues in rails 2. I can't tell you how many hours I lost to dealing with weird issues with vendored gems.

Bringing rails2 apps to rails 3 is going to suck for you. I'd argue that one of the prices for the elegance of rails is that you need to spend more time constantly upgrading it.

However, the advantage of this price is that you have a framework that has been consistently lead of the pack in terms of productivity and simplicity.

I think rails developers blindly upgrade their apps, just because they want to be on the hottest new technology. I know I am drawn by the glitter of rails 3.1 beta. But everyone should really weigh the business decision of upgrading; what do you really truly gain by being on the latest rails for all your apps? Sometimes the technical debt you take on by maintaining an old framework is less than the effort you have to spend to upgrade, especially for sunsetting apps.

The problem is that the state of the art changes. The reason Rails is still relevant is because the core team is committed to improvement, even at the expense of API stability and legacy support. That's definitely a valid concern for someone supporting apps on a shoestring, but on the other hand it makes Rails more suitable for someone who wants to stay on the cutting edge. You simply can't have it both ways...

> We were all prototype a few years ago, now it jquery ...

You mean __7__ years ago when they chose it as the default? Rails was the first framework with Ajax support built-in, and it was done poorly because nobody understood how it should really work at the time.

> we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails

It's easy to argue that CoffeeScript shouldn't be a default, but then it's even easier to just turn it off. Shouldn't be a point of major contention, but I can see how people don't like it.

> The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it

Yes, they replaced a hodge-podge of ad-hoc query construction with a relational algebra library that enables dramatically more flexible query construction and lazy loading. Who knows how many broken edge cases were fixed merely by the switch to a proper mathematical basis.

> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

Bundler solves dozens of thorny issues that were intractable in the Rails system. Now Rails is simpler because it doesn't have to have any gem activation code, it's handled by a separate library that can solve your gem management problems for your non-Rails projects as well. You may not have run into any of these issues, but I assure you there were real and Bundler is a big step in the right direction.

> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

Yeah but what are the implications of that? You want Microsoft-style legacy support from Apple? They ain't gonna give it to you, because that lack of legacy support is what enables them to move forward at the pace they do. This has definitely impacted the type of projects I feel comfortable delivering in Rails (ie. no low-budget small client sites), but for an actively developed app it makes Rails a more attractive place to be.

As long as something is backwards compatible, I don't see the problem. That is the natural progression of a rapidly evolving industry like tech, there is always something new. I don't see how introducing coffeescript as an option makes a problem for anyone. I agree there shouldnt be change for changes sake, but often through trial and error we discover a more efficient way of doing things. If rails doesn't evolve, it will be replaced by frameworks like Django, CakePHP that do.

Yikes, unfortunately this knocks rails off of my to-try list. I've got a non-web application with an unusual, but by no means bad, schema. I've found it makes a good measuring stick for frameworks/tools. I have nothing against doing things in the way of a particular framework, but I have existing code to bring to the party too, if something isn't going to play nice I ignore it. I can't live with building something that exists in isolation. Its either not going to work with what I have, or hold me back when I want to build on top of it with something else.

  class Account < ActiveRecord::Base
    set_table_name "tbl_accts"
    has_many :posts, :class_name => "Post", :foreign_key => "postid"
  end

  class Post < ActiveRecord::Base
    set_table_name "tbl_posts"
    belongs_to :account, :class_name => "Account", :foreign_key => "postid"
  end

  #Account.first.posts.create(:title => "test", :body => "test")

> Conventions over configuration is nice but it requires some stability.

if you were to compare this with an agnostic framework with drop-in, you have to set everything. with rails, you just gonna say "oh, this isn't default so i have to explicitly set this".. or "oh, this is no longer default so i have to set this".. it's just a convention.. if you want to use rails in an unconventional way, by all means do it, you just have to know more about its internals if you intend to do this -- this makes sense when you think about it(you don't want to be hacking hard on a piece of software you don't really understand, you're going to want to know what you're doing so that you have a good idea when some unexpected problem arises).

>Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.

if you did that and decided there's really nothing out there that can solve your problem, they you can just implement it however you want, rails is very configurable, but really, you're just limited to what ruby can do..

>So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.

i'm sorry, did the article speak to you this way? are you a girl where you might be giving meaning to what's actually being said?

This says it all for me. Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.

Its the nature of the software beast that upgrading a large and complex application to a new version of the language or framework is difficult and maybe prohibitively difficult. Once something is written and it works it often times stays as is... sometimes for decades.

Rails is very opinionated about the things it handles and how it does them, but I've never had a problem rolling my own solutions and integrating them in. Not every model has to inherit from ActiveRecord, arbitrary code runs just fine in lib/ What's the problem?

With less opinionated software, changes actually rarely break you since it typically requires opt-in/code change to pick up the new capabilities.

Here's configuring the middleware: http://guides.rubyonrails.org/rails_on_rack.html

Here's a stackoverflow question on how to disable ActiveRecord: http://stackoverflow.com/questions/2212709/remove-activereco...

Have you seen ActiveModel? It gives a common interface for orms to interface with so swapping out ActiveRecord doesn't break half of the view helpers.

Rails 3 is far, far easier to extend and modify than 2.3 was.

Still working in Sinatra does give you that fun feeling of old Rails.