Hello Merb

Merb is getting merged into Ruby on Rails. Together they will become Rails 3, as announced by David Heinemeier Hansson here and Yehuda Katz here.

I wish I could claim to have been playing with Merb for a while and have some real insight into the framework, but to be honest, I haven’t. I still think this a very interesting news, though, and in my opinion this can only be good news for the Rails community. Already, the brilliant Merb guys are optimizing and improving Rails, for instance this 8% speed boost in using respond_to.

So, how can we expect the the merge to affect the Rails framework we know and love? Let’s peek into the possibilities of combining these two frameworks.

One change that seems certain, is changes to the routing system. “Plans are already underway to port the Merb router over to Rails. At the very least, you will have the option to use the Merb DSL syntax instead of the Rails hash-based syntax. We’ll see which one becomes the default.” Katz says. David explains how Merb concepts for rendering resources in different formats will be used in Rails 3, but with more intuitive or “Rails-like” naming.

Another change which is likely to make it into Rails 3 is slices, as indicated by Katz in a response to his own announcement. Slices are “similar to what Rails-Engines promise, except merb-slices are built into the framework” as Ezra Zygmuntowicz explains. This is exiting news! I’ve always been interested gaining leverage by having reusable application slices, and I’ve actively built and used both Rails Engines and Radiant extensions. Engines has previously been frowned upon by leading figures in the Rails community, but it has been improved to work in a quite clean and easy-to-understand manner since the release of Rails 2.0, and are in fact compared to Merb slices here. Radiant extensions are obviously only for Radiant CMS-based websites, but the diversity of these extensions illustrates the potential of getting support for real full-stack application slices into the Rails core. A project like Adva CMS also illustrates how it is possible to build high quality reusable application slices for the common good.

A third change I hope to see as a result of the merge is controller-based mailers and partials. ActionMailer has always been a bit of an ugly stepchild in the Rails framework, and the positioning of a Mailer as a sort-of model, but with templates, doesn’t seem logic to me. Merb has an AbstractController class that both mailers and partials (called parts in Merb) inherit from, which allows for a more intuitive control in rendering mails and parts.

I was curious to find out how the Merb community has reacted to this decision. The Rails community doesn’t seem to be overly concerned. Perhaps it’s because the merge of Merb and Rails are called “Rails 3″. Not “Merb 2″, not “MerbRails” – the names clearly signals that the merge will be done on Rails’ terms. While it has become popular in the Rails community to dissociate one self with David Heinemeier Hansson, I still think people sees him as a good security for not letting the Rails principles go in the merge.

I browsed through the more than 100 comments to Yehuda Katzs announcement of the merge, and while about half of the commenters simply expresses their happiness and agreement with the decision, the objections of the other half falls roughly into three categories: Technical, personal and economic.

The technical concerns are of course fully expected, and some of the more interesting are:

  • “Does merging a lightweight framework into a bloated framework make the bloated framework any lighter?”
  • “I really hope that merb will be able to continue it’s ‘no-magic’ attitude and bring that to rails without compromises”
  • “I would have liked to see merb go further on its own just to push the envelope further”
  • “How many planned advancements are being put on hold while Rails catches up?”

The personal objections is about one very visible person: David Heinemeier Hansson. I hold no grudge against David, so I shall only repeat one of the more curious comments in this category: “The big problem, as always with Rails, is DHH: a vainglorious, two-faced prima donna with a massive and fragile ego. He’s good, but not nearly as unique and amazing as he thinks he is. I went to Merb to get away from DHH. Ugh.” If many people in the Merb community feels like this guy, I understand if they are concerned that David will simply steamroller the philosophy of Merb. David has been fast to address these concerns, but the question is if just saying everyone should work on what the care about is enough.

The economic perspective of the merge is where things gets interesting. Rails is trademarked by David and synonymous with 37signals, while Merb is very closely linked to EngineYard. Two commenters really nail it down:

  • “How has the ‘Opinionated Software’ philosophy of “Fuck You (DHH)” Rails become aligned with the ‘open’ and democratic philosophy of Merb? Is this some kind of preemptive marketing in advance of a joint investment in both Engine Yard and 37 Signals by a common investor?”
  • “My suspicion turns to the fact that almost every Merb core team member is owned by Engine Yard. Something doesn’t smell right.”

It’ll be interesting to follow not just the architectural design choices made on the technical front during the merge process, but also how this will change the positioning of 37signals and EngineYard, and if the two companies are really warming up to some kind of close relationship.

The timeline for a first peek at Rails 3 – the union of Merb and Rails – is said to be RailsConf 2009 – 4 months from now.

2 thoughts on “Hello Merb

  1. this is excellent news, for a while i’ve been having to choose between lean Merb or powerful Rails, now I get them all in one package.

    great stuff, and awesome blog; well done.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>