Big news in the world of Ruby web frameworks: Merb and Rails will be merged. Merb, started by Ezra Zygmuntowicz, who explains the change
So our two teams started talking to see if we could put our differences aside and come together for the common good. We've laid out a roadmap of what and how to integrate merb' best features into rails-3.0. I think we have a great plan that will make Rails the best framework in existence. It will be a blend of the best things we have discovered while working on merb, while keeping the Rails aesthetic people have grown to love.
You can expect to get a kick ass, fast, memory efficient version of rails(merb) this spring!
David Heinemeier Hansson, the crator of Rails, explains the future of Rails will look like with Rails 2.3 which will be followed by Rails 3.0
Rails 2.3 is just around the corner. We hope to wrap up and release in January. It's a blockbuster release packed with goodies to the tilt. But as soon as that's done, all eyes will be on Rails 3.
InfoQ recently featured an interview with Yehuda Katz where he explains many of the concepts that are now being merged into Rails. The specific changes that will merge Merb into Rails 3 are explained in David's announcement, as well as in the announcement by Merb's Yehuda Katz, such as the public API:
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.
David also explains the reasons behind this:
Rigorous API: Too many plugins break when Rails is updated because it's not clear where they can safely hook into the internals and when they're monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn't break. They'll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won't break willy-nilly with upgrades.
Rails 3 will also inherit Merb's focus on modularity, a topic that was hotly debated recently in the Merb and Rails communities. In short, rails-core will be created, which reflects merb-core, a minimal version of the web framework, as Yehuda explains:
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.
David explains that Rails 3 will continue to offer default subsystems, but also work well with alternative systems:
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, we'll have a default, but we shouldn't have any form of discrimination against alternatives.
Further changes will bring Merb's performance to Rails 3.
A big questions now is of course: what about developers using Merb? Yehuda explains:
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.
Ezra also adds that EngineYard, who's been sponsoring Merb for a long time, has an interest in a smooth transition:
And we will provide a clear upgrade path to Rails 3.0 for merb apps. We still have quite a few merb apps running internally at [EngineYard] and will want an upgrade path for our own apps as well.
The Merbist blog also has some information about the merge.
What do you think of the merge?