It’s christmas, baby, and do we have a present for you. We’re ending the bickering between Merb and Rails with a this bombshell: Merb is being merged into Rails 3!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

What this will mean in practice is that the Merb team is putting their efforts into bringing all of the key Merb ideas into Rails 3. Yehuda Katz will outright join the Rails core team, Matt Aimonetti will work on a new evangelism team, and Carl Lerche and Daniel Neighman (hassox) will be co-starring the effort to bring all this over. We’ve immortalized the merge with plaque page at rubyonrails.org/merb.

What’s being brought over?
Some of the key ideas that they’ll be taking with them from Merb into Rails 3 are:

• Rails core: Yes, Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty. Rails 3 will make it easy to run just a bare minimum and then allow you to opt in just the stuff you want, if that’s necessary for your particular situation. Think “rails myapp —core” (and “rails myapp —flat”).

• Performance optimizations: Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over. We’ll also bend the architecture in the places where that’s necessary for a big yield. In short, Rails 3 will get all the performance attention that the Merb guys are known for.

• Framework agnosticism: Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives.

• Rigorous API: Too many plugins break when Rails is updated because it’s not clear where they can safely hook into the internals and when they’re monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades.

This is not a big bang rewrite
It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.

I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3. The Merb guys will also be working hard on giving existing Merb users a manageable upgrade path to Rails 3. We’re working with lots of ideas including allowing existing Merb controllers to be mounted alongside new Rails 3 ones. We’ll see how it all plays out, but play out it will.

Also, the Merb guys aren’t just abandoning the existing Merb user base and their applications. They’ll still be doing bug fixes, security fixes, and work on easing the upgrade path to Rails 3. This will all progress in a nice, orderly fashion.

The timeline
Rails 2.3 is just around the corner. We hope to wrap up and release in January. It’s a blockbuster release packed with goodies to the tilt. But as soon as that’s done, all eyes will be on Rails 3.

The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 in Las Vegas. Who knows if we’ll make it, but we’ll certainly have made tons of progress on it by then.

So all of these changes are pretty much effective immediately. We’ve already started the collaboration and we’ll be rolling out a bunch of public initiatives announcing the concrete elements of the work under the Rails 3 milestone very shortly.

No hard feelings, just kumbaja
This is quite a dramatic turn of events. We went from testy relations to coming together in not very long at all. But I’ve been incredibly positively surprised at how well everyone on both sides have been gelling behind the scenes. The more we talk, the more we realize that we want the same things. And in the few cases were we do care about something different, it’s usually complimentary.

I really hope that everyone within both communities will deal with this news as gracefully as the key contributors from both camps. Let’s just wipe the slate clean on anything that has gone before and cherish that we can now move forward in unity instead of as fractions of the same ideas.

Rails 3 is going to kick ass.

Also read what Yehuda wrote about this and Carl Lerche and Ezra and Matt.