Home > Development > The Merbification of Rails

The Merbification of Rails

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.

About these ads
Categories: Development Tags: , ,
  1. January 13, 2009 at 1:59 am

    Few things:

    1. re: the Merb API will change.
    It will change, and that was planned even before the the merge. 2.0 was scheduled to break the API, it won’t be a big deal tho.

    2. re “we’ll end up closer to Rails than to Merb in the end, at least on the surface.” That’s correct, in surface it will look more like Rails, unless you want to drop down to another stack or rails-core and go for the opt-in option.

    Overall, I think you have a pretty good view of what will happen. However I don’t think learning merb now is a waste of time since all the concepts will be in rails3 and even tho the API will change a little bit, if you are a good developer that shouldn’t be a big issue ;)

    Yehuda and myself will be in Phoenix next week, I believe there is hackfest/ruby meeting organized a gangplank, feel free to stop by and chat with us.

    I’d be interested in knowing a bit more about your worries regarding the merge.

    - Matt

  2. Tomas
    January 13, 2009 at 2:33 am

    DHH will not “let go” of Rails? You’re complaining that DHH won’t disband Rails and quit coding on it?

  3. dkoontz
    January 13, 2009 at 12:30 pm

    Matt: But what value is there in learning an API that is just going to change in 6 months? There are a few new concepts, sure, but they don’t strike me as stuff I haven’t learned just watching videos and reading tutorials about Merb. If there was a nailing down of the new API at some point I would happily learn and use Merb with that API knowing that when Rails 3 hit I would have very little changing to do.

    I’ll be at the Rails group meeting, it was announced at the RUG last night to a big crowd so hopefully you’ll get a nice big turnout.

  4. dkoontz
    January 13, 2009 at 12:33 pm

    Tomas: I’m saying, if Merb is a cleaner code base, as seems to be recognized by a lot of the Ruby community, why merge Merb into rails instead of taking the few things in Rails that are missing and put them into Merb? It’s not a naming issue since the end product will be called “Rails 3″ and it’s not a license issue since there’s going to be merging anyway, so that basically leaves personality as the cause. I’m saying that the more fit code base should win and become the new base. Why force the Merb team to port the router to Rails when (paraphrasing heavily here) the Merb router is clearly better and was written in the first place because the Rails version was hard to work with and was too much work to be worth fixing?

  5. dkoontz
    January 20, 2009 at 7:34 pm

    Update:

    From the (Jan 20, 2009) Phoenix Rails User Group (http://phxrails.com) meeting.

    Yehuda just said it was his decision after looking over the Rails code base that refactoring Rails was easier than putting missing features into Merb. Interesting…

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: