I don't get it. One of the best things about Rails is that I don't have to pick and choose my components. I use what everybody else is using and I know that means it's likely to work and be reasonably well documented. Any small gains I might achieve by swapping out one layer of Rails are going to be more than offset by the extra complexity of my unique Merb environment.
DHH's arguments about "opinionated" software seem to have been lost on the Merb crowd.
This is great if you happen to love every design decision the Rails crew has made for you. If not...
I don't think Merb will replace Rails. I think, ultimately, the two appeal to different crowds. Too some extent, I hope people who are happy with Rails stay with Rails. Merb feels like it's more aligned with the Ruby community than the Rails community. If that makes any sense.
You're never going to love every decision made by the designers of any platform. The thing is, you're likely to make just as many missteps on your own. Every once in a while it's worth it to start with a clean slate but I don't think Rails is even close to that point yet.
Sometimes DHH has some extremely stupid opinions. Such as his blog post about how "reusable apps" and "components" are not possible, even though Django is using them with overwhelming success.
I switched to Merb because of Slices. But Datamapper turned out to be an amazing upgrade from ActiveRecord. And I'm starting to love all the other little framework features (defer blocks in routes for example) that just don't exist in Rails.
Actually, merb manages to still keep it rather simple even with the added choice... The different parts integrate well and you can still use the default merb stack if you want security...
I found rails to be really great for developing small applications but I find that any non trivial rails application start to have quite a few hack to get rails to play the way I want
Okay, here's a situation I've run into: I want to create a web frontend to an existing library. Naturally, the existing library already has some nice model-like classes that I'll be working with.
What I'd like to do is take those model-like classes and persist them to the database. It should just be a simple matter of mapping a few instance variables / attributes to database columns right? Well, it turns out this is fairly difficult with ActiveRecord. Firstly, ActiveRecord wants all your models to extend ActiveRecord::Base. But, I already have an existing class and the chances are I don't want to, or can't, change the existing class to extend AR::Base.
So maybe I'll to create an ActiveRecord model that will wrap and delegate to the existing class. Ah, but AR::Base has a huge footprint and uses so much magic that it's downright painful to do delegation. You can't safely use method_missing because AR::Base does, and you're almost guaranteed to have a conflict where AR::Base and your existing class define the same methods anyway.
Here's how DataMapper is different: You're not required to extend any sort of base class. Instead, you mixin a module with a tiny footprint. So, in your web frontend, you can open the existing model-like class, mixin DataMapper::Resource, and map your properties to columns. Because the footprint for DataMapper::Resource is so light, and it doesn't use any magic, it's unlikely we'll break the existing class. Even if we do break it with this approach, we're far more likely to succeed with delegation that we are under ActiveRecord.
So, to bring it back to Merb and Rails, here's the key difference: ActiveRecord might be just fine for most projects. But, maybe DataMapper is sometimes better. Or, maybe another ORM is. In any case, Merb will let me work with whatever library I think is best for my project. Rails give you no choice. You either take the whole stack as is or you don't.
And, that doesn't just apply to the ORM layer. The same can be said for template engines and javascript libraries.
You're right that Rails expects you to take the whole stack and doesn't offer you choice. DHH and I consider that to be a huge advantage but it also means that Rails won't be a good fit for every project.
That said, I don't see anything in Merb that would tempt me away from Rails for new projects.
I made one small demo app in Merb about a month ago -- so, slightly pre-1.0. Overall, it was a good experience and I intend to continue exploring Merb.
A few points:
* Not as much documentation... sometimes it takes a while to find the Merb equivalent of some Railsism. The interfaces for Merb are very similar to Rails, though, so usually just trying the equivalent is enough. The differences I encountered were usually improvements over the Rails approach, IMHO.
* Smaller community. So, fewer plugins, fewer examples, fewer HOWTOs, etc. Hopefully this will change. But if you're uncomfortable developing something without a ton of resources to leverage...
* More flexible. I used Datamapper instead of ActiveRecord, and was very happy to have a choice. I was also very happy with Datamapper itself. I'm not sure Datamapper is mature enough, yet, for large scale projects, but the future is bright.
Overall, I think Merb benefits strongly from the "hindsight is 20/20" adage. It takes the best of Rails and rethinks its shortcomings. Where Rails was more revolutionarly, Merb is evolutionary. I think the improvements are worth the trouble of learning another web framework. I intend to use Merb for any new projects I start.
My demo app is http://ifrotz.org -- not that it's at all enlightening in a Merb vs Rails debate.
In short, yes there are other advantages. If you just want a list, the release announcement is full of goodies. I was really just listing the things I noticed when working on one small app. As to features I haven't used, yet... I'm probably most excited about Merb's slices. Slices are potentially a huge win for code organization and re-use across webapps.
DHH's arguments about "opinionated" software seem to have been lost on the Merb crowd.