litany against fear

coding with spice ¤ by nick quaranto

RailsConf 2009 Rails 3 Step off of the Golden Path

published 06 May 2009

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Matt Aimonetti. There’s a lot of talk about “the merge” but not many know why or what happened. Going through the history, starting from the principles behind Ruby, and the process of how Rails came about. The big principles behind Rails: Convention over Configuration, Don’t Repeat Yourself.

At some point there was a schism from Rails, and this was Merb. Merb was focused on performance and agnosticism. Lots of drama as time went on and plenty of tension. They finally sat down and talked, and they had the same goals but just had different perspectives.

What’s in store for Rails 3:

Improved performance. Merb was a speed demon, it’s time to bring that into Rails.
Increased modularity. Bringing this to the next level.
Agnosticism in general throughout the framework.
Public API, ensure that plugins won’t break.
Mountable apps with Rack

The Rails 3 default stack: ActiveRecord, Prototype, ERB, Test::Unit. No huge changes for end users. Instead of one “Rails Way” there’s going to be many “Rails Ways”. A big difference is that Rails 3 will be less opinionated. Not all apps are going to be the same, and this just recognizes it.

When should you step off the default stack? According to Matt, he believes that it’s a question of taste along with the requirements given to you.

Will be able to pick and choose the JavaScript engine you want. For templating engines, it’s not that big of a change since there’s really only 2 choices. The more difficult choice will be the ORM. It will be possible to seamlessly swap between the various ORMs available. One of these is DataMapper, which has a lot of great benefits that ActiveRecord doesn’t. It’s uses lazy loading along with a smarter way of dealing with potential N+1 select problems that plagues ActiveRecord. Some other neat features: ways to move/migrate from older column names, and a really nice way to define complex queries with Query::Path. Tons of adapters too.

Other adapters such as Sequel or Hibernate will work. Plenty of non-RDBMS systems being considered as well. CouchDB, Redis, Tokyo Cabinet, etc will hopefully be easy to build adapters for.

Create your own Rails: define your own file structure, your own router DSL, and even your own ways to deal with requests. The goal is that the audience for Rails will expand even further, and perhaps grow into places that we can’t even see now.