Hacker News new | comments | show | ask | jobs | submit login
Matt Aimonetti: Why on earth would you ignore Merb? (rubylearning.com)
22 points by ropiku 3320 days ago | hide | past | web | favorite | 18 comments

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

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.

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.

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.

I wasn't implying anything about Merb community, just pointing out that switching to a new development platform can bring surprises from quite unexpected angles.

I have been interacting with the merb community for over a year and have never had a negative experience interacting with anyone (google groups, IRC, etc). I really can't speak for the Rails community. I dumped Rails for tech reasons not community ones. And don't worry about the "ruby assholes", good talent with the right attitude is available. I know quite a few if you need some recommendations.

Very true.

One thing that has stung me about Rails is the conceit; if you have a requirement that runs against the grain, Rails developers seem to have no problem in saying "that's stupid; you shouldn't want that."

I understand your sentiment, but you can override a lot of things in rails. On the whole 80/20 percent thing, your 20 percent might going against the grain of the core ideas of rails, but you still can get around it. If rails isn't a fit for your project/product I don't think you should force it.

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."

- Matt

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.

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

"... 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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact