Key ideas taken from Merb into Rails 3

Merb is a lightweight and modular framework that is designed to give users more flexibility and better performance than Rails. Like Ruby on Rails, Merb is an MVC framework. Unlike Rails, Merb is ORM-agnostic, JavaScript library agnostic, and template language agnostic, preferring plugins that add in support for a particular feature rather than trying to produce a monolithic library with everything in the core. The core code in Merb is kept simple and well organised meaning it’s easier to understand, maintain, extend and lightweight.

On 23rd Decemember, 2008 announcement was done that Merb is Rails and Rails is Merb, i.e., Merbs 2 is Rails 3. Merb and Rails are joining forces and merging the two code bases for Rails-3.0

For Merb
This does not mean that Merb folks will not be left out in the cold. They will continue to support bug and security fixes for the merb 1.0.x line. And will provide a clear upgrade path to Rails 3.0 for merb apps.

For Rails
There are many key ideas that Merb team will bring into Rails 3. Some of them are:

• Modularity – 

Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. It will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts.

• Performance optimizations – 

Rails 3 will get all the performance attention that the Merb guys are known for. Rails 3 will benefit from the performance optimizations that the Merb developers have made to some of the components that are shared between the two frameworks.

• Rigorous API – 

Another critical characteristic of Merb is the strong API stability guarantee, which will make the extensibility of the framework more robust. 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.

• Framework agnosticism -

Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, Rails have a default, but it shouldn’t have any form of discrimination against alternatives.

• Rails core  -

Rails will make it easy to start with a “core” version of Rails (like Merb’s core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Think “rails myapp—core” (and “rails myapp—flat”).