(Actually, that could be one equal sign, or maybe three, depending on how this works out).

Yesterday, key developers of both Merb and Rails announced that the two popular web frameworks for Ruby will be merging.

This decision comes as a shock to must Ruby web developers, given the history and philosophy of the two frameworks.  Rails has been described as a monolithic, instant web application generator that likes default configurations.  It’s very easy to create a fully functional web application, but not so easy to slim it down or to use other than the default stack.  Plugins for Rails often break between versions because there is no clearly defined API.

Merb was largely created as a reaction against those issues — preferring a modular approach with a lightweight core, agnostic of object-relational mapper (ORM) and JavaScript libraries, and having a well-documented API for extensions.

According to the announcements, the Rails team has finally seen the Merb light.  Rails 3.0 will incorporate multiple features of Merb:

• An option to generate a Rails app with only minimum core support.  This means making the Rails code more modular.
• Performance improvements taken directly from Merb code.
• An easier way to use other than the defaults for ORM, JavaScript libraries, templating, and testing framework.
• A well-documented API for plugins, with a test suite for that API.

Merb will also be evolving towards that same codebase, with the plan that Merb 2.0 will be Rails 3.0.  Both teams plan to devote a lot of effort towards making migration of existing apps as easy as possible.

Combining these frameworks will not be a trivial task, but I’m thinking it may prove even more difficult to combine the personalities on the two teams.  Has DHH really converted to the Merb way, or will there be further conflict between the two approaches?  Not that that’s a bad thing, but how easily will those conflicts be resolved?