Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

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 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.


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 proved 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.


  • 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!

Tags: ,

178 Responses to “Rails and Merb Merge”

@sonicpond as has been stated a number of times (including on DHH’s blog), monkey patching as the public API is going, going, gooooone!

Do you think for a second I would have been involved in an endeavor that represented the opposite of everything I’ve been talking about for a year now? Hell’s no!

Re-read DHH’s post. We’re all on the same page!

That’s almost exactly what I would love to see. Something written down where rail 3 would be merb underneath the hood and Rails above some layer.

Keep rails database layer for ActiveRecord, ajax layer, and a lot of the plugins. Maybe the dependency loading.

Keep merb’s slices, routing, merb’s template and rest functionality, and add merb’s DataMapper layer.

Get rid of the rest of the weirdness in rails. anything magical needs to go. But DHH seems to love his magic and I think that’s one very big difference that is being overlooked. Defaults are one thing but defaults that weave themselves in the code are another thing all together.

I’m more for diversity, the philosophy and culture of the merb community was sufficiently different then the rails community.

But it appears Rails has come around to seeing the perspective (anti monkey patching, public API, etc) And that’s great. But i can’t help but think about the developer using merb in their apps today, what are they getting from rails? Easily portable plugins?

Although I’m sympathetic to the elimination of redundancies in the two projects, I think it’s better to share code then to homogenize the merb community into rails. Not that rails folks are lepers, but again, diversity.

This has all been said already, I just hope the arguments against are sufficiently loud that people remember those who were not ok this.

Please prove the naysayers wrong and make a better rails that does not reek of code stink.

as I see it, it will be lot harder to get some idea/s into merb2/rails3, merb will be no more, and yes, I can see how rails can benefit from this, but I cannot see how this will help merb (and community).

what other framework will be there to compete with? competition is the horsepower of all development.

I hope there will be actively developed fork of merb before merge.

well. i was planning to change to merb because rails is bloated … just hope the ´modularity´ brought to rails3 will enable us to make it lighter and faster … not to confuse us

So all the remarks concerning competition, there is rarely a statement about merb without one, stand now corrected.

You sacrifice your integrity to make Rails a better framework and for the good of the ruby community. Sounds noble, hope it’s worth it.

Thanks Yehuda. I’ll check out those MEAP chapters. Count me in on Rails 3.

I’m sure you and Ezra anticipated the backlash from this… and I’m equally sure that if you’re not satisfied with the reality of R3 that you’ll lead the charge on the new awesomeness.


It is truly Rails Core team’s honor to have you!

Rails developers seem to be very happy about this. But I have sucessfully worked with Merb for sometime now, I’m not sure if this is actually good news…

So what are developers to do in the interim? Develop on Rails? Develop on Merb?

I’ve read in many places that there is “a clear path” for the Rails 3/Merb 2, yet I still haven’t seen a single UNIFIED timeline and/or planned transition document that lays out what you can or can’t expect and best practices…

I think this is partially what fuels all of the fear of this transition (and justifiably so). Is there really a single unified front on this transition, and if so, where do we go (URL?) to follow this process? I mean look, this really affects people in a serious, tangible, financial way. You’d think that some sort of master plan document would have been discussed and released with this sort of announcement (or am I missing something)?

I’m worried that the Merb philosophy will get lost but then again, we can always fork Merb if Rails 3 seems turns out to be a disaster.

Win-win. It proves that Merb is of the highest technical quality, and that Rails and Merb has a great future together.


this is obviously a huge mistake, not to keep merb as a separate project. Rails could embrace a fork of merb. This would be obvious. Then merb core developers would opt on one or another (or both) development.

Remember: Rails needs more merb, than the opposite.

One day rails core team will say: Rails 4 is dumping merb for another awsome stack creation. And merb was destroyed in the process, along the way.

Web2.0 will be remembered for *easy*_dumping_of_the_community.

It’s still time to fix buggy decisions. This decision would not pass a Test.

Please, keep merb project flowing independently.
I know quite some firms that went from Rails to merb. We are now assumed like merbivores with proud.

I support the journey. Are we there yet?

One suggestion I’ve been thinking about is to make the router into an easily replaceable plug-in, if you will. I can imagine all kinds of reasons to have special purpose and feature routers.

Maybe this plug-in idea could be for the whole product. Every core part of Rails would be a plug-in. Rails then would be defined as a structure frame. This would allow a totally distributed and failsafe runtime architecture. It would allow all the core modules to be replaced for any purpose.

A site architecture, for example, could be designed using Amazon Web Services virtual servers creating execution nodes on demand with distributed Rails loosely-coupled plug-in parts running and communicating as needed.

A Rails site would then be dynamically part-wise scalable to any size as needed. It would be a swarms of plug-ins working to achieve site goals.

Notice a tightly coupled version on a single machine could still be very fast.

As a follow up related to the everything is a plug-in idea. As more plug-ins are created more people have a direct interest in Rails/Merb. This is a uber network effect creating a huge support community.

maybe you should try pay attention to this:

Merge will not be good for the merb community.
In medium/long term will kill merb’s core ideas. for sure.

So… I’ve been on the Rails for a year and a half. I have been toying with the idea of trying Merb for a while. Here are the things about Rails that pain me today:

1) AR doesn’t get it. From the view of program, an object is an object is an object. If certain classes have “hibernate” and “revive” methods, fine. This has huge implications for complex objects.

2) AR doesn’t get it. Migrations are a great idea, but this is really source code on the schema PLUS data issues.

3) AR doesn’t get it. Relational databases have been around longer than I have (I’m 42), and are REALLY good at what they do. Reducing them to a data store is hugely inefficient. We need a full interface to be able to interact with their capabilities.

4) alias_method_chain is a weak link. We need an easy way to figure out what the alias chain for a given method is. (@@chained_methods[:method] << :alias anyone?)

5) alias_method_chain is a weak link. It is impossible to figure out what actually happens when I call a method (think AR::B#save) from the documentation. The document generator should (minimally) make note of the chaining & leave hints.

6) There is no delicate way to put this. The code reeks. Whenever I have had to trace my way into the stack, I have uncovered scary code smells. It disturbs me that core members have allowed this code to go in, and I think that a cultural shift is needed. This goes double for ActiveScaffold, so I hope that the admin interface that keeps being mentioned here is good.

Don’t get me wrong. Rails gets a lot right. The devil is in the details, though, (think alias_method_chain) and details is where I see Rails as REALLY weak. If you guys can fix the culture, this can be really, really good.

I am very encouraged by this merger.

I congratulate both teams : merb and rails.

great news for ROR community..

I think we will have real winner in Rails 3 which can outshine others Python, PHP & Java for big apps (it is not like ROR2 is not good enough)

I don’t get it. If Rails 3 is Merb 2 and vive versa, what sense does it make to use Merb after releasing Rails 3? If there will be no difference then there will be no sense to have Merb AND Rails…

This really makes sense. If only the myriad Linux distributions would pool resources. There is only one Windows, and look who is by far the biggest OS on the planet. Ex unitate vires – out of unity, strength.

А комментарии тут реально интересные. Будем следить за комментариями и далее ;)

Darn it. That sucks. Being eaten by the man is no fun.

Anyone want to keep the Merb tree going on our own?

Wow, great news! Good job guys!

Я практически никогда не сомневался в Вашем интеллектуальном уровне, но поймите, не все такие как Вы. :)

So should someone just getting started learn Merb or Rails at this point?

I’d like to congratulate Merb team for backstabbing it’s philosophy, community and all business models that where built around it.

Hi! The original post was written on December 23rd, 2008. So, could anyone tell when will Rails 3 be definitely released? As a novice (I studied a little rails 2.3 some months ago), at this time I’m quite hang, since it doesn’t make sense to me both study Merb or Rails 2.3, and I damned to wait for rails 3.

Would be eager to know when Rails 3.0 – with the cool Merb features will be released.
Any ideas – the current status of 3.0 and planned release date?

This is a gamble. There is no risk for the rails people. Only the Merb people stand to lose themselves in this. Objectively, it seems that having (merb) people that are dedicated to writing clean code dive into rails will be quite good. If they are allowed to make real contributions on a continuing basis without losing that edge that made merb great, it could be a huge success. Now rails takes input from outsiders, so it is unlikely that they will start ignoring anyone with something good to contribute, and that goes double for the merb people. That means that the likelihood of this going right is large and the likelihood of it swallowing and killing the merb people is small.

As this represents a chance to do something huge with many ways to succeed and few ways to fail, I agree with the merb people that it is worth a shot.

My $0.02

Is there any idea yet when rails 3 will be released?

Leave a Reply