The big difference here is that when Rails came out it solved a real problem. Every other popular web technology at the time was much, much harder to use and slower to develop in. Since then it's acquired some inevitable complexity but most of that was in response to somebody's need for a feature. Merb will accumulate the same complexity if it's successful.
To me this just sounds like Common Lisp vs Scheme all over again.
I just don't get the appeal of Merb at all. Rails was such a relief after a few years of roll-your-own--web-stack Java. Why would I want to go back to dealing with all the little incompatibilities and bugs that creep in once you start mixing and matching pieces to build your own stack?
@kuniklo merb is designed to be modular and to get its pieces working together smoothly. However, this is a harder problem that having one well defined stack.
merb isn't for all, and if you are happy with the framework you use, you should stick to it. However, if you happen to have to fight with it to make it do things it was not designed to do, then you might want to look at merb.
Also, note that merb also comes in a full stack version that you can customize if you wish to.
So again, in this article, I was not trying to convince people to give up on what they use, but instead offering an alternative for people who are looking for something else.
As Matz said: "We have several post-Rails frameworks, which is very good, and I believe in diversity."
The fact that there is a full-stack version available doesn't mitigate the fact that the multitudes of custom stacks out there are going to mean two bad things:
1. The default full stack will be a lot less thoroughly documented, tested and debugged because a lot fewer people are using it.
2. The chances that I can just jump in and start hacking productively on somebody else's Merb app are slim because it's likely I'm not familiar with some of the components you're using.
I still don't understand at all why I'd want to use Merb. What problem are you trying to solve here? Being slightly better than Rails in a few respects isn't even close to good enough to compensate for the lack of documentation, code maturity, available programming expertise, public success stories etc that Rails has going for it.
In terms of marketing (well, if you care about that), I think you need something a little bit more compelling than 'designed to be modular'. Show people what modular might mean in terms of lean, fast and low memory requirements. Demonstrate some projects that would have just been using 5% of Rails that can take advantage of how slim Merb is. That kind of thing, I guess.
Agreed that diversity is a good thing, but the article asks why wouldn't I, when I am asking, why would I?
It doesn't help that today, adding more RAM costs very little, and that the new VM in Ruby 1.9 runs my Rails apps 3x to 5x faster, so I have very little reason to look outside Rails.
"... start mixing and matching pieces to build your own stack?"
Perhaps because the pieces are sort of like Legos; they're designed to be mixed and matched with known results.
I prefer Ramaze, because it's more like Play-doh to Merb's Legos (sort of; I realize that's an over-generalization), but Merb is not some random collection of libraries. It is (I think) more like Rails with deliberate decoupling of components.
the default stack is all most people will need. you can go from there to slim it down or replace pieces. merb is mostly a turn-key full stack like rails in terms of instant productivity.
Perhaps you have a 100% ajax "client", and don't need AR, or just need simple AR, merb would be ok and save some overhead you get with rails for the 80% of it you will never use. Thats my take anyway.
It would be nice to see some progress made on the interpreter but I think it's to Ruby's credit that the language design hasn't changed that much in the last several years. A lot of the activity on the Python side has been fixing things that weren't well thought through in the first place.
Honestly, I'd say the opposite is true. The more the language design changes, the more implementor time is going towards servicing the changes and not squeezing the fat out of the implementation.
That being said, the two often occur together because changes are exciting and attract effort.
I don't see how that follows at all. If the biggest issues with Ruby are performance and memory management how does changing the language spec help fix that? If anything a stable language spec should help nail down the bugs in the engine.
Is a great console music player.