This is an interesting question that I've considered, since I'm just ramping up on Rails. Still, I have to consider that there are some differences of approach in Merb vs. Rails that I'm curious about.
You'd have to consider whether you:
- might work on an existing Merb app
- might find work in a Merb shop
- want to explore the mindset of the leading Rails competitor (in the Ruby space)
- aren't sold on Rails, and want to explore something else
- have had problems taking Rails further than it wanted to go willingly, and want an alternative.
- want to explore Merb features that will be assimilated into Rails3
If any of those are true, you might find Merb worth a look, even if you routinely use Rails today.
So there's this subtle metonymy in the tech world whenever we use the phrase "to learn something" where it typically it ends up being understood as "to learn how to use something". If that's what you're asking ("Why learn how to use Merb?") then my answer is simple: unless you need to for an existing project, it's probably not worth your time.
However, I'm totally against pigeon holing our usage of the phrase "to learn something", because oftentimes we're also looking for solid inspiration and a chance to acquire wider knowledge. In these cases, Merb is an absolutely amazing piece of software that I whole-heartedly encourage you to learn from in-depth. More specifically, here's why:
* Merb's code is exemplary of best practices in Ruby. If you want to bring your Ruby skills to the next level, digging into Merb is a great way to do so.
* Merb's architecture represents a clean rethinking of the boundaries of previous web frameworks. Studying it will give you insight into important design decisions critical to any properly ambitious web framework.
* Finally, Merb lacks the legacy code of older frameworks, giving you the chance to learn from it without having to make sense of vestigial cruft.
In terms of the book, I was a little more than half-way complete with The Merb Way when the merge was announced. Of course this shook my world, but I still felt strongly about the values and lessons Merb as a framework was teaching the community. Consequently, though I knew the framework would with time see its end, I drastically restructured the book to be more academic and am pleased with the result. The move from practitioners guide to scholarly code autopsy isn't something everyone can appreciate, but hey, if you're keen on learning about an end-of-life'd framework, chances are you're there to learn something that will stick with you.
All this said, Michael also gives some good reasons for interest in Merb, so if yours is among them, definitely take the time to check it out.
If you are using a rototiller, you are doing it wrong. Even on this tiny ad:
Two software engineers solve most of the world's problems in one K&R sized book