Previous on this blog alluded to my misgivings about the big merge between Rails and Merb. I liked the trimmed-down, uncomplicated API of Merb. I knew what it was going to do and how to make non-standard things happen. Well it looks like Rails 3 is getting some of that mojo.

A post by Yahuda Katz about some of the upcoming features of Rails 3 is making me feel much better.

Some of the most promising things are not really Rails/Merb specific. The new bundler for example will be a boon to anyone interested in actually deploying an app cleanly.

Section 3 of the article got an audible cheer from me. Rails respond_to blocks are just unnecessary. Porting over Merb's display method in the form of respond_with is a huge leap forward for Rails users and a must have feature for those of us who will be making the Merb to Rails 3 migration. But it get better:

What we do is move the idiomatic logic into a new object called a Responder. By default, we use the Responder that ships with Rails, but you can use your own subclass the same way you would set a controller-wide (or application-wide) layout. That way, you can package up your own RESTful idioms into objects and use those.

(emphasis mine)

I can already see a use cases for this.

Basing controllers on a rack application is another another bit the looks to make the transition easier:

In Rails 3, ActionController::Base is built on top of ActionController::Metal, a stripped down version of ActionController with support for simple Rack semantics. We then include a series of modules to add support for things like callbacks, rendering, layouts, helpers, and on and on. This means that it’s easy for you to start with ActionController::Metal and pull in just the features you want, paying just the performance cost you want.

We even implemented deprecated 2.3 features as a module that gets mixed in to ActionController::Base. If you aren’t using any deprecated features, you can simply stop including the module and get some performance back. You also know that you’re not using any features you shouldn’t be.

(emphasis mine)

A fairly extensive post to the Merb mailing list on June 28th details the transiting plan for Merb applications including the ones at EnginYard. This post make it appear that merb will get a compatibility layer as well

If you look at Merb, it's mostly an analogue to Railties and ActionPack. ActiveRecord, ActiveSupport and ActiveResource have no analogue in Merb. As a result, a transition from Merb to Rails mostly involves a clear path from merb-core to ActionPack. Specifically, Merb controllers need to both live side-by-side with Rails controllers (this means the router needs to be able to dispatch to them, for instance), and it needs to be possible to reimplement Merb's controllers in terms of a stripped down version of Rails' controllers. In current master, that means writing a Merb::Controller that inherits from ActionController::Http [now called ActionController::Metal], an extremely simple, fast version of Rails controllers with opt-in components.

I, like one of the commenters in the post, am now looking forward to seeing a beta release "real soon now."