This Week in Rails 3.0
Posted by Mike Gunderloy February 05, 2009 @ 11:38 AM
Now that Rails 2.3 has hit the release candidate phase, some of the development effort is turning to Rails 3.0. With that activity heating up, it’s time to start keeping you all informed as to happenings on the 3.0 version of the Rails source. I’ll still be posting separate “This Week in Edge Rails” information focused on Rails 2.3, so you can keep straight which changes are ready now and which still lie in the relatively distant future.
The Vision
The Rails 3 vision is based on the announcement that was made in December: we’re bringing in the key ideas from Merb to Rails, including:
- A more modular Rails core, so you can run applications with less than the full Rails stack
- Performance optimizations
- Framework agnosticism with sensible defaults
- A tested and documented API for extensions
Rails 3 promises to substantially advance the state of the art in Ruby web frameworks, while still providing migration paths from Rails 2.x and Merb 1.x.
The Source Code
The Rails 3.0 branch in the main Rails project on GitHub is the place to be to see what’s going on:
git clone git://github.com/rails/rails.git
git checkout 3-0-unstable
As the branch name might tell you, this is still a fairly experimental place to be: you probably don’t want to roll this out for production applications just yet. But it is tested code (and it’s using continuous integration to stay that way), and it already includes substantial changes from Rails 2.x thanks to the efforts of Yehuda Katz, Joshua Peek, and others. The changes so far are focused on cleaning up and improving Rails internals, rather than on adding new features.
Action Dispatch
Action Dispatch is a new Rails component which lives in Action Pack (along with Action Controller and Action View). Action Dispatch is responsible for all the processing involved with dispatching requests: request and response handling, HTTP status codes, file uploads, URL and parameter parsing, session storage, and so on.
Action View Reorganization
There are substantial changes in the Action View internals. The overall goal was to clean up a bunch of special cases and extra hooks that had built up over the years, and to leave all callers into Action View using a single unified entry point. The code cleanup has been coupled with some rearrangement of the Action View source to make it easier to find bits of functionality. This was a substantial effort; if you’re interested in a detailed look at the refactoring, you can read up on it at Yehuda’s blog
Callback Optimizations
A new method of handling callbacks removes the need for iterating through the callback list at runtime, and provides a substantial speed improvement in this area of the code. Though this is a micro-optimization that may not have much effect by itself, the hope is that by carefully optimizing as many hot spots as possible we can get a visible overall speedup in page creation and delivery – which, after all, is the point of a web framework.
What’s Next?
Obviously, there’s a long distance between where we are today and the Rails 3.0 vision. We’re fortunate to have an excellent team of core programmers devoting substantial time to making that journey. The interim goal is still to have a beta version of Rails 3.0 out in time for RailsConf in May. You can help in the same ways as with earlier versions of Rails: download the source, start testing it with your applications, and submit your own ideas and patches to the Rails Lighthouse. Rails has been a joint effort of thousands of developers over the years, and Rails 3.0 will be no different in that regard.
The first post of an interesting serie… good! Thank you guys!
Go Mike!
Another superb piece of blogature! Keep this up and you’ll be looking at the Pulitzer!
That git checkout won’t work, right? I had to do:
git checkout—track -b 3-0-unstable origin/3-0-unstable
I’m asking mostly in case there is a nicer way to use branches as you have, without all this tracking..
Very Good information indeed.
I have a question:- Are you compromising with the quality of Rails 3.0, just to support providing migration paths from Rails 2.x etc…?
If it is so…. don’t kill Rails 3.0
Let Rails 3.0 grow from scratch as best as it can.
Let old Rails projects end with Rails 2.3 only. Developers can convert manually if required.
In response to SoftMind’s comment:
If you decide to go the “from scratch way” then please don’t jump from 2.3 to 3.0, but provide a migration path in the form of 2.4, 2.5 towards 3.0, just like python did (python 2.5, 2.6 -> 3.0).
In real life, there are not only “old” and “new” Rails apps. The biggest and most important portion of apps are the ones that are existing and evolving (unfinished and/or continuously updated). Everybody that is currently working on a rails app right now is in this state.
Please don’t let me convert our 40k lines RoR project manually!!! That will just cause us to rewrite it in a more mature framework instead.
@Bas van Klinkenberg,
From what i understand, there would no Rails 2.4, 2.5 etc…
May 2009 will start with Rails 3.0 beta.
Rails 3.0 will evolve in a different manner and sooner or later Rails 2.3 will vanish. (e.g php 4 )
You may still continue with Rails 2.3 if required, but shall be missing a lot, if you’d stick to old Rails, without 4 advantages mentioned in the blog above.
Peter – Whoops, you’re right about git! I’d forgotten that I’d already set up the tracking branch, many moons ago. Thanks for the correction.
The details of the migration paths have yet to be worked out, but the core team has committed to making migration as easy as possible. Whether this takes the form of further 2.x releases, or special scripts, or a migration application…at this point, we need to wait and see.
Even I agree with softmind, we should rather follow the way python or drupal follows about backward compatibility—I’m more inclined to python way i.e. breaking compatibility at once in major releases only while drupal is compatibility agnostic (it breaks it in every release) and that’s why it’s, technically, one of the best piece of software out there.
Well, we have to break it at one point or another if we don’t want to compromise with the quality of software. We should make Rails 3.0 the best piece of software that we can, and it should not be less than best just because of this or that (backward compatibility)—if we really want rails to live long though I think merb merger has already made its life a little longer.
What I can propose: 1. while developing rails 3, we should not think of any compatibility—our focus should be to make it the very best we can. 2. Once rails 3 is ready, we should plan out the easiest possible way to migrate from 2.x to 3, whatever be it.
But what I’m thinking is, will Rails 3 be using features exclusively from ruby 1.9, which could add in performance improvements. What I mean is though it’s ruby 1.9 compatible from 2.2 on, but will rails 3 be only compatible with 1.9+ because by the time it will be released most of the libraries/gems will be 1.9 compatible, hopefully.
@ Ashish Surana,
Thanks Ashish. You have explained much better than i can.
I totally agree with all your points.
Rails 3.0 is not going to break backwards compatibility just for the heck of it. The vast majority of the improvements we want to make will be perfectly easy to introduce in a backwards compatible manor.
Sure, there will probably be a few spots that will be incompatible. There will be some plugins that needs to be updated. But Rails 3.0 is not a “start over from scratch” release.
As long as we’re getting the intended improvements, it should be fine. And, if the same is achieved keeping the backward compatibility, it’s icing on the cake.
It’s taken me a while to begin to fully digest how momentous the integration of Rails+Merb really will be…
ActionDispatch? Whoa. Yes please.
Agnostic to JS frameworks, theoretically meaning I could use Dojo instead of Proto+Scripta? Hallelujah!
Two merry bands of kick-arse devs cranking on one uber-framework instead of dueling banjos??? Holy crappola!
In the oft bickering and ridiculously multi-branched world of open source I think it’s absolutely applaudable that these two teams have set aside any differences they may have had and realized the collective long-term benefit of banding together… (geez, I sound like i’m rooting for bipartisan politics in Congress – gack). I’m going to guess that in years to come people will look back and say this was one hell of a momentous occasion. I also sincerely hope that upon seeing how amazingly kick-arse the fruits of this effort are that many other dueling factions in the open-source world band together to drive more all-inclusive, modular, performant tools rather than maintaining their own nineteen different variants of the same solution, each with very specific and subtle nuances and benefits.
<insert here applause>From those of us relying on your work & brains to crank our own apps & empires, A VERY HEARTY THANKS!