Merb + Rails3 = Rarb?

For all those of you who have missed it, today it was announced that Merb will be discontinued and merged into Rails 3 sometime by the end of next year:

http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3

What does this mean for Mack and other alternate frameworks? Well a lot, and nothing, all at the same time. I personally, am not pro the merge. Merb was the biggest the alternative to Rails out there. This has been a problem for us smaller frameworks in that it was hard to get a fold hold into the alternative to Rails marketshare that Merb had a hold on. So with Merb going away, why aren’t happy that Mack has the opportunity to become the big alternative to Rails?

Well, the answer to that question is simple. Innovation and competition. With Merb becoming as big as it was becoming it was forcing Rails to become a better framework. It also made the other alternative frameworks, such as Mack, to be better frameworks as well. Mack has always strived to be a great hybrid of all the frameworks out there. It has strived to provide the best of all those worlds. If all those worlds merge together, what space is left for something like Mack? Mack, and others, could end up being no different than Rarb (Rails + Merb), and then where is the innovation?

If this was the two biggest cable companies or banks merging the government would be screaming monoply. While I’m not saying that, I do feel that this certainly will have an impact on innovation, an impact that only a good healthy competition can bring. Now, please don’t get me wrong, I think Rarb will definitely be innovative. It should be as both Rails and Merb independently have done some amazing things, and I hope that they continue to do so.

So what does the future hold for Mack with this news? Business as usual. Mack will continue to try and be innovative. It will try to make your life a little easier as a developer, and make developing portals and distributed applications easy and fun. Hopefully, Mack will fill the void that will be left by Merb and more people will pick it up as a mature web framework. Hopefully, that will do what Merb once did, force Rails (or rather Rarb), to be more innovative. Hopefully, it will become the alternative that will create another web framework to be innovate to knock it down, and so on…

How do you feel? Are you happy? Are you sad? Are you indifferent? I’d love to hear what you think.

Tags: , , , ,

15 Responses to “Merb + Rails3 = Rarb?”

  1. Carl Lerche Says:

    I hardly believe that there is no more competition. There are WAY more frameworks out there than the ruby ones. Believing that the web development ecosystem is limited to just ruby seems somewhat closed minded.

  2. Paul Barry Says:

    If you are looking to compare this to a corporate merger, I would say this is like XM and Sirius. Those 2 were both offering almost the exact same thing, so it seems like merging create a monopoly. But as Carl said, what Rails is competing against is frameworks in other languages, such as Django, PHP, etc. Bringing Rails and Merb together makes Ruby more competitive against other languages.

  3. Shane Says:

    I’d be happier if Rails3 was a Rails ‘stack’ built on Merb. I switched to Merb to get away from the aliased method chains, monkey patches and squiggle code thats so typical of Rails and related libraries.

    Time will tell if Yehuda can whip DHH and co. into shape but this can only be good for alternatives like Mack.

  4. remi Says:

    +1 to what Shane said

    “I’d be happier if Rails3 was a Rails ’stack’ built on Merb”

    I really, really hope the Merb core team knows what they’re doing with this merger. Atleast I know that the Merb guys are hardcore opinionated (in a good way) and they’re unlikely to support a project that won’t be *better* than Merb.

    The Merb core team would *not* have agreed to this if they didn’t strongly believe they could make Rails 3 better than Merb 2 would’ve been. Keep in mind how much effort these guys have put into Merb! They would *not* drop the project without some really seriously confidence that this would be better.

  5. Mark Bates Says:

    I agree that there are way more frameworks out there than Ruby ones, I don’t think anyone is arguing that. And I also agree that we, as a community, should always look outside of our own language for inspiration, despite what DHH said at RailsConf 08. We have to look at everything, and not just what’s immediately around us.

    With that said, if I were using Java I would use Struts, because I real like it as a framework in Java, if I was using python it would be Django, and so on… But, I like to use Ruby, and so don’t lots of people, so I think we should have choice in the language we like to use, just like there’s choices in those other languages.

    What I’m afraid of is that the smaller Ruby frameworks will find it difficult to go against Rarb with it’s near total market share. This has already happened with frameworks like Halcyon.

    Like I said there are parts of me that are excited about it, because I work in a Rails shop during the day, and it would be great to use DataMapper, jQuery, rspec, etc… in a really easy way as first class citizens. It would be wonderful to have a more powerful router, etc… so that part of me is excited about this.

    What I’m concerned about is that it might make it more difficult for those who think different, and think things can be done in a better way to flourish in this new world. It hasn’t been easy up to this point, I assure you, but people have been interested to find new alternatives to Rails. That may want to leave Rails, might, *might*, dwindle, making motivation on the side of alternative framework developers difficult to muster up.

    On the plus side Mack is routinely mentioned in the list of alternative frameworks, and this could very well help to promote it up that list and fill the void that will be left by Merb.

    So again, I hope Rarb is good, I hope it’s innovative. I also hope that people who decide to use it, use it for the right reasons, because it fills the needs of the application they’re trying to develop, and not use it because it’s the big guy on the block. I also hope that alternative developers use this as a time to promote themselves as a great alternative.

    I hope that helps to clarify my position. :)

  6. Justin Says:

    After reading this article I’m definitely going to look into Mack more.

    Of course, if Yehuda and friends manages to do this Rails will definitely be awesome again. But until then, Rails is only what I do at work. Any Ruby frameworking I’ll need off hours will need to be filled by another framework, as I’m just tired of the terrible mess those Ruby retards brought to the language. The only thing Rails was initially good at was a purpose, not a code base. The code was gimmicky and reminds me of what some people write when they just need to get it working.

    If this is the big refactor, as Merb had pushing up to 1.0 then so be it. Rails needs that in order to stay viable. At least Ez seems to feel that way about this.

    Otherwise, its time to look at Mack again! :)

  7. Dan Kubb Says:

    I’ve been asserting in private discussions with some of the Merb core people that the pieces of Merb and Rails that can be used by all frameworks should be pushed up into the Rack layer. It doesn’t make sense for every framework to have to implement sessions, routing, exception notifications, etc when the functionality is so similar. Push the commodity pieces into Rack and let every framework share the common pieces. Yehuda, Carl and Ezra have agreed that this is a good idea, so hopefully we’ll see this merger result in it being easier for alternative frameworks built on Rack.

  8. Matt Aimonetti Says:

    Great post Mark. As you know, the merb core team always values plurality and competition.

    We addressed this very issue when we discussed the possibility to merge with Rails. I agree that merb had a positive effect on rails and vice versa. It also drove the other frameworks which pushed us further.
    The problem we faced was simple: do we want to keep competition just for the sake of it? Rails clearly told us: we want what you have and we would love you to work with us. So the options were:
    - tell them to go to hell and let them try redo what we already did and know how to do.
    - accept to work with them and make rails a better framework.

    Option 1 would maintain the competition, but now you have 2 groups of people trying to do the same thing and being better at different aspects. The community gets confused and communication breaks.

    Option 2: will loose the merb vs rails competition, but we double the amount of people working on rails and make it better.

    We went with option 2, knowing that within the rails/merb team we will disagree and learn from each other. I hope you will keep us on our toes and the rest of the community will push us to be even better.

    I wish you the best and hope we’ll get ot work together on some rack related stuff!

    - Matt

  9. Diego Scataglini Says:

    I personally think that there is plenty room for other framework. Lately I played with sinatra and loved it. A while ago I played with ramaze. (haven’t tried mack but will)
    I can definitely see the application of other smaller or differently oriented frameworks like waves. (although waves is not really a web framework)

  10. Tim Says:

    I guess it comes down to who has the final say. I would think the teams would be well served in dividing areas of responsibility. Let the merb team handle the stuff thats close to the metal, and let the rails team work on the rails specific stack and features.

    Personally I worry that DataMapper may be the red-headed stepchild in this merger, but I hope I am wrong. I do think that merging the two teams will be good for the ruby community in the long run, and rails will greatly benefit as a result of these two teams combining.

    I think the ideal merger would leave the merb team enhancing merb core, and making the merb framework stronger with a focus of just being a framework for building web frameworks. rails would be a layer on top of merb in the style of merb-more.

    I guess I would prefer if the rails guys decided to adopt the merb-core and build rails on top of it. It sounds like that is what might be happening, and if so, I don’t see why anyone would be unhappy about the merger…

  11. Mark Bates Says:

    I love the idea of some of the Rarb stuff, particularly the stuff that comes from Merb, being made into separate Rack middleware pieces. That would be great. It would nice for alternative frameworks to say, “Yeah, I want to use the Rarb router” or “I don’t like that router, I’ll build my own.” That type of thing I think will be great for the community, and it’s something that I really look forward to seeing what happens.

    I also agree that if they slap some Rails things on top of Merb that would be great, however, I feel that it’s going to be ripping out sections of Rails with Merb, which will result in a hybrid of old Rails code and new Merb code. That would be uncool.

    Ultimately I think we can all agree that there are good parts to the merger, and bad parts to the merger. The key really comes down to how it gets pulled off by the core teams, the communities acceptance of Rarb, and the desire of ‘alternative’ developers to keep fighting the good fight.

    Also, I should clarify that when I say ‘alternative’ I don’t just mean web frameworks, I also mean ORMs (DataMapper, Sequel, etc…), testing (RSpec, Shoulda, etc…), and so forth.

    Let’s all keep up the innovation that the Ruby community is known for. Let’s all keep each other on our toes, and let’s build the best software we can.

  12. goffry Says:

    Please shed light with new logo. Doesn’t this guy right?
    http://tinyurl.com/9suvo6

  13. Sean McCleary Says:

    I am very excited about this merge. I have been torn to the point of delaying new projects because I could not decide if I wanted to use Rails or Merb. If this merge can bring the best of both frameworks together as it promises, my framework decisions will be much easier.

  14. Sam Smoot Says:

    @Dan re: Rack

    A generic third-party Sessions library would be great.

    I’d rather not see any of that stuff polluting Rack though. Rack is just fine as is IMO.

  15. ibrahim saraçoğlu Says:

    Thank you for this informative read, I really appreciate sharing this great post. Keep up your work.