Archive

Posts Tagged ‘rails’

The Merbification of Rails

January 12, 2009 5 comments

It’s been a few weeks since the announcement that Rails 3 would be Merb 2.  We had a discussion on our local Phoenix RUG list, my input to which is here.  Then I dug around some more and read the posting by DHH.

This is not a big bang rewrite

So, Rails 3 will be Rails 2 + some unspecified but core stuff from Merb moved over.  And Merb 2 will be … ?  If you’re a rails developer, this is probably not big news in any way, just wait for Rails 3 to be released (or RC status) and figure out what breaks, if you intended to upgrade at all.  However, if you are a Merb developer, or about ready to pick up Merb (like me) this puts you in a pretty bad spot.  Do I learn Merb for all its touted benefits of lean execution and component agnosticism?  Well I could, and then later this year re-learn all over when the API’s change in Rails 3.  The Merb community is saying “come to Merb, it’s like getting a preview of Rails 3″.

That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. – Yehuda Katz

Except that this is not true.  The Merb API will change when it is merged into Rails.  ActiveRecord is remaining as the default ORM layer and I am positive that other Rails elements will persist.  Merb will be Railsified I think as much as Rails will be Merbified.  How do you withstand hundreds (thousands?) of plugin authors shouting at you to not break things.  I don’t even want to imagine the compromises that will be made when all the users catch on to the idea that lots of API’s will be changing.

Unfortunately I think a clean break is the best possible solution.  Merb was started because Ezra claimed it was far easier to rewrite portions of Rails than try to fix the existing code.  Heck, Merb itself was rewritten from scratch recently with no apparent universe imploding effects so they’ve proven it can be done on a large code base.  Yet we have the situation where DHH will not let go of Rails (his code) to make way for what he to some degree is acknowledging as a better solution.  So my grand hopes of a stack that has all the marketing and acceptance of Rails but the clean implementation of Merb deflates daily.  Moreso, my desire to learn Merb drops to almost zero, I might as well stick with Rails since a) I know it and can move much quicker, b) The Merb API is going to change anyway, c) I suspect we’ll end up closer to Rails than to Merb in the end, at least on the surface.

Categories: Development Tags: , ,
Follow

Get every new post delivered to your Inbox.