Rails and Merb Merge

Today is a fairly momentous day in the history of Ruby web frameworks. You will probably find the news I’m about to share with you fairly shocking, but I will attempt to explain the situation.

Before talking tech, and even going into the details of the announcement, I want to assure everyone that the incredible members of the thriving Merb community are top priority, and that this could not have been possible without every one of them.

Merb is an open, ever-changing project, and some of its best ideas have come from not-core regular-Joe community members. It’s gotten where it has because of the community, and the community will get us even further in the future. Your ideas, feedback and even complaints will be 100% welcome in the future, just as they have been in the past. I believe in the tremendous value an open community and just generally open attitude bring to the table, and am counting on those things to continue ushering in the future of Ruby.

On to the news: beginning today, the Merb team will be working with the Rails core team on a joint project. The plan is to merge in the things that made Merb different. This will make it possible to use Rails 3 for the same sorts of use-cases that were compelling for Merb users. Effectively, Merb 2 is Rails 3.

What does that mean exactly?

• Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. We will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts. This is exactly what Merb means when it touts “modularity”.
• We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins. This project will also include the creation of one or more benchmarking applications, so we can more clearly see what optimizations have real-world impact.
• As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release.
• Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
• Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. While ActiveRecord will ship as the default ORM, the plan is to make it drop-dead easy to drop in other ORMs without feature degradation (to the extent possible, of course).
• Rails will continue their recent embrace of Rack, which is a really exciting development in the Ruby community that Merb got in on early and which we believe will improve the state of modular, sharable logic between applications.
• In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

How will we do this?

The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.

In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.

To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.

If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.

Why!?

As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore. Merb has been around for roughly two years now, and we’ve proven out our ideas by use in real-world applications (like Yellow Pages, SproutCore, Powerset, Defensio, etc.). Given this philosophical convergence, it just didn’t seem like there was much to gain by continuing to duplicate effort and spend time and energy fighting each other.

I think it’s important to acknowledge the Merb community for building something super-awesome. I really hope that we’ll all stay in this together, help each other in the coming months and in the transition to Rails 3.

Rails will be putting together a new evangelism team, which will include Matt Aimonetti (Merb core team member and evangelist) and a few other people doing Rails evangelism work. This group will be responsible for, among other things, helping the community get where we’re going. Their job will be to listen to you.

This seems crazy! Has this ever happened before?

Interestingly, yes. A very similar situation confronted the Struts developers several years back. They had built a very popular framework in Struts, but a very active group of developers were really advancing the same ideas in interesting ways in a framework called Webwork. The Webwork developers saw their project as “Struts done right”, just as we believe we’ve improved on the implementation of Rails.

Eventually, the Struts guys and the Webwork guys came to the conclusion that they would be stronger together then apart, and merged the projects. What became Struts 2 was effectively also Webwork 2, but the two communities got together to build something better.

I believe that this merger will get the ideas that gave Merb momentum into the hands of many more people, and that really serves us all. I’m looking forward to the future.

Postscript

• One of the most personally gratifying parts of working on Merb has been working with alternative Ruby implementations to make Merb run well on them. Fairly early, Merb was running faster on JRuby than MRI, and I’m looking forward to bringing a lot of that insight to Rails, and helping to make Rails to be solidly competitive on the performance front with frameworks in “faster” languages.

• The Merb Training is very much still on! We’ve spoken with the majority of the attendees, as well as with our partners at Integrum Technologies and they’re all really excited about the merger. That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. There are still a few seats open, so sign up now if you’d like to join us!