

Matt Aimonetti: Why on earth would you ignore Merb? - ropiku
http://rubylearning.com/blog/2008/12/18/matt-aimonetti-why-on-earth-would-you-ignore-merb/

======
old-gregg
... because it's impossible to find a Merb programmer? Sure Rails beats the
shit out of ASP.NET but good Rails programmers are rare, expensive and have
_very_ cocky attitudes. It has been a major, major problem for us, to a point
where I've started thinking that doing a project in ASP.NET can actually be
cheaper and more _pleasant_ experience.

With Merb, I am afraid this issue will be even more pronounced. Merb isn't as
widespread, and seems to be technically solid. This, I suspect, will only give
these Ruby assholes more reasons to bring all that elitist crap to the party.

~~~
qhoxie
That's a lot of poor speculation. If you explore Merb and its community more,
you will see that the elitism is pretty much non-existent. Merb is extremely
new, so of course it does not have as many developers as more mature
frameworks. When Rails came out of the gates, you could have said the exact
same thing.

~~~
kuniklo
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.

~~~
qhoxie
_Merb will accumulate the same complexity if it's successful._

Not likely. Merb will accumulate plugins. Rails had most of its complexity, or
at least signs of it, from the beginning.

------
kuniklo
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?

~~~
mattetti
@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."

\- Matt

~~~
Andys
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.

~~~
ezmobius
ruby 1.9 does not run rails apps 3-5x faster. More like maybe 10-20% and
slower on some things.

------
jpcx01
Merb's appeal to me is stability. A public framework API means plugins will
stay working after upgrades. With slices, you'll be able to build up reusable
components that will _stay_ functional.

If you code Rails, try getting your 1 year old code run today. 99% chance is
it will be broken by default. The goal on Merb is to maintain a stable,
defined API so the code your write for it wont break down the line.

After coding Rails for 2 years, this is very appealing to me. There are lots
of other benefits/drawbacks of Merb, but a stable API is what sold me on it.

