InfoQ

News

Merb Will Be Merged Into Rails 3.0

Posted by Werner Schuster on Dec 23, 2008 06:15 PM

Community
Ruby
Topics
Performance & Scalability ,
Ruby on Rails
Tags
Rails Plugins ,
Ruby on Rails ,
Rails ,
Merb

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?

Great idea with great humility by Kent Fenwick Posted Dec 24, 2008 11:45 AM
Re: Great idea with great humility by Ivan Lazarte Posted Dec 31, 2008 1:37 PM
  1. Back to top

    Great idea with great humility

    Dec 24, 2008 11:45 AM by Kent Fenwick

    I think its great that the battle of the Ruby Web Frameworks will end in a synergy combining the best of both worlds. The Rails Core Team and Merb Core Team were able to check their egos at the door and make decisions that would benefit the entire community. This is why I love Ruby. It seems to foster this kind of innovation. Thank you

  2. Back to top

    Re: Great idea with great humility

    Dec 31, 2008 1:37 PM by Ivan Lazarte

    I think it's more a survival tactic for the Ruby web dev community. Tiobe confirms decreasing interest in Ruby: http://www.tiobe.com/index.php/content/paperinfo/tpci/.

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.