"All of the Merb guys are former Rails developers, and they started Merb because they had a number of issues that they cared about," such as performance optimization and agnosticism pertaining to frameworks used with Rails, Hansson says. For example, Rails has used Active Record for object relational mapping, whereas Merb proponents wanted to use DataMapper or Sequel, he adds.
Rails 3 will bring over ideas from Merb, such as framework agnosticism that will gel with Rails' emphasis on strong defaults, Hansson says. Merb's idea of published API for extending Rails with plug-ins also will be part of the mix.
"Right now, Rails has an incredibly bad ecosystem for plug-ins," Hansson says. The plug-ins tend to break when Rails is updated because of the lack of a clear-cut API, he adds. Also being brought over from Merb is routing, for the mapping of browser requests. Merb offers more options in this regard than Rails has, Hansson notes.
Merb focused on parts of the Rails stack that the Rails effort did not, Hansson says. Katz, the maintainer of Merb, says the Merb framework originally was built to solve a problem with asynchronous processing in Rails. "At the time, Rails was a single-threaded application, so using a Rails process to handle, for instance, file uploads was a nonstarter," he says. "Merb was created initially specifically to solve the file upload problem but very rapidly became a sort of rallying point for people who were dissatisfied with Rails for other reasons."
The two-year-old framework has offered spirited competition with Rails, but fundamentally, the two technologies were headed in the same direction, Katz says. (Both Merb and Rails are derived from Ruby, and both are open source projects.) "What happens now is the Merb guys have chosen to basically join into the Rails camp," Hansson reports. "Bringing both teams together will make it easy for us to produce a framework that has the benefit of Rails' maturity and community, with Merb's relentless focus on a defined API, modularity, and performance," Katz adds.
Hansson offers assurances to Merb developers migrating to Rails: "The hope is we're going to do everything we can to make it as easy as possible. You're not going to have to rewrite your entire app," he says. There will be some changes required, but the project expects to offer techniques to make them, Hansson notes.
As Rails and Merb make peace, others may splinter off
Rails consultant Jade Meskill notes he had read brief online commentary criticizing the uncompetitive nature of the merger, which unifies the two frameworks. But Meskill was nonetheless supportive, stressing the unity it provides in the Ruby community. "While competition is definitely valuable, there comes a point especially with this community, with this particular [technology], where it's leading down the destructive path of a huge fracture" between Merb and Rails, says Meskill, president of Integrum Technologies and a co-founder of the Phoenix Rails user group.
"It's just been a really nice community, and this split was starting to create division between the best Ruby minds that we have," Meskill says. He anticipates "great things" resulting from the merger, such as more adoption of Ruby as a development language and Rails as a Web platform.
The merger does provide unity, but someone will likely come along and form yet another similar project, says analyst Al Hilwa, program director for application development software at IDC. "There might be a sort of Merb reloaded," he notes.
One concern developers may have from the Rails-Merb merger is the complexity of the effort. "It's going to be interesting to watch how a rather large, not-so-mean-and-lean framework like Rails is going to offer the modularity" of Merb, Hilwa says.