The most effective martial artists specialize in their discipline, but are not afraid to cross-train in others. Bruce Lee—arguably the most famous and influential martial artist of the past century—trained first in Tai Chi Chuan, then Gung Fu, and boxing, as well as learning western fencing. The insight taken from so many disciplines led him to create the Jeet Kune Do form of combat.
Programmers are not all that different. Cross-training in other languages and frameworks can only improve one’s overall mastery of the craft. When it comes to Ruby frameworks, the two most popular choices are Ruby on Rails and Merb. They’re often seen as being contenders, but this truly isn’t a zero-sum game; learning both is a very sensible move. They both enable you to write web applications in Ruby, and are somewhat similar, so learning one after you know the other shouldn’t be very challenging. In the many cases people learn Merb after they’ve had some experience with Rails, but either way, acquiring a solid grasp of both frameworks provides developers with extra flexibility. Often people who learn both, will end up mostly just using one or another, depending on their individual preferences. But it’s worth knowing them so as to be able to write both CRUD-style applications that fall within Rails’ solution space, and more complex, edge cases where Rails’ opinions will end up contending with yours.
Among the reasons to give Merb a chance, is its focus on performance, a smaller memory footprint and an extreme level of modularity, which enables you to pick and choose which components you’d like to use.
Merb is not as mature as Rails, of course, but it has reached version 1.0.x and with it developers can have greater confidence in a more stabilized API. Now is perhaps the best moment to get involved and learn more about this rising framework. Not surprisingly though, Merb finds itself in a similar spot to the one that Rails was in a couple of years ago (in terms of weakness of documentation when it comes to getting started). Thankfully, this point is being taken seriously and there’s been some major progress in terms of improving the documentation for Merb. Below are some useful links to get you started with Merb.
Merb has an official API documentation, a wiki, a google group, and a community site called Merbunity for news, projects and tutorials. The irc.freenode.net #merb channel is also a useful and welcoming spot. Furthermore, there is a Peepcode PDF draft called Meet Merb. If you want something even more substantial, on the book front there are several titles coming out in the near future. These include Merb in Action, The Merb Way, Beginning Merb and Merb: What You Need To Know. There is also an open source Merb book, whose development is led by Matt Aimonetti. It’s a work in progress, but probably a very good starting point, which just happens to have the added bonus of being free. And if your interested in Merb, don’t miss InfoQ’s interview with Yehuda Katz, who’s Merb’s lead developer and one of the sharpest guys we have in the Ruby community.
Finally, if you are a professional developer who wants to quickly progress with Merb and bring their skills to the next level, do not miss your chance to attend a three day intensive course on Merb, which is being offered by Yehuda and Matt in Phoenix, AZ between January 19 and 21 (2009). Registration has been open for two days already and 20 out of the 30 available spots have already been snapped up. The remaining seats won’t last more than a day or two, so if you are interested, don’t delay (sign up now and you’ll also benefit from an early registration price).
2009 is almost here, so why not take the opportunity to learn Merb this year?
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
“CRUD-style applications that fall within Rails’ solution space, and more complex, edge cases were Rails’ opinions will end up contending with yours”
Honestly, that sounds like baseless marketing chitchat. I’d LOVE to see some practical example/scenario exhibiting that.
Same for memory usage/speed. If your framework’s speed/memory usage is a concern for your app, you should reevaluate your selection of platform/language. Unless of course, your application is called ‘Hello World Master Of the Universe’.
It’s a shame that a bunch of people are spending all their time/energy copy/pasting Rails from scratch instead of working towards a common goal. Oh well.
“Honestly, that sounds like baseless marketing chitchat.”
Well there’s yer problem!
You should actually check Merb out, dig around the source, try creating an app. Even a cursory exploration of Merb’s structure will disabuse you of the notion that the merb team is simply “spending all their time/energy copy/pasting Rails”.
Further more the advances that Merb has made are trickling back into Rails, so as ungrateful as you may be, Merb’s rising tide is lifting all boats.
Don’t mean to brag, but I’m pretty sure I know merb’s source code a lot better than you’d think. In fact, that’s what makes me “strongly dislike” this whole nonsense surrounding it with all the FUD. And it has me convinced that those who think it’s different from Rails, don’t basically have a clue about a thing they say.
Rails is great. Merb seems cool too and I’m learning more about it little by little. But, yes, Merb has (admittedly) taken a lot of ideas from Rails. It also has some good ideas of its own that Rails may be able to learn from. What I’m saying is that having > 1 Ruby web framework is an overall win for us Ruby developers. Competition and choice drive innovation.
Another interesting ruby framework is waves (http://rubywaves.com/). It imposes less opinion than rails or merb which are fairly similar when it comes to the overall philosophy.
@pratik
I know someone that works on a high traffic rails site (actually a service layer and a site, two separate rails apps) and they customized the hell out of rails to improve the speed of the service side. They’ve recently been trying out merb and out of the box merb is as fast as their heavily customized rails code and much faster than the default rails. Like I said, this is a service so you can’t do the usual rails trick of caching html to avoid going through the rails stack.
Pratik,
So when DHH did it for years it was all good?
Pratik, wtf is with all the hate?
They’re both MVC Ruby Web Frameworks. No shit, there’s going to be similarities.
Are you at least willing to admit that the plugin setup for each framework are built entirely differently? Mind you i haven’t been keeping up recently on whats in Rails Edge, but so far as i am aware Merb’s router is still more powerful than Rails’s.
This is not to say that Rails isn’t capable of doing a bunch of the stuff that Merb currently does, but the simple fact that Rails doesn’t do it -before- Merb, means that you have to give Merb at least some credit.
I also appreciate the fact that the Merb crew are engaging both the Ruby implementers and the RubyGems maintainers to improve stuff everyone in the whole Ruby ecosystem (And that’s not to say that people in the Rails world don’t [yay phusion & REE], but the Merb gang are tackling stuff that other people aren’t).
“Don’t mean to brag,” well then don’t. 😛 So it turns out you’re familiar w/ the merb source, that still doesn’t explain the haterade. It especially doesn’t enumerate your claims as to how Merb ~= Rails (maybe a blog post on it would be nice, preferably sans ad hominem).
What sorts of applications would be an immediate “win” for merb vs rails? In other words, what would satisfy the blank here to make the sentence true? “My application is/does/needs to _________________. Ah yes, merb’s a better fit than rails for that.”
Merb did take a lot of cues from rails, it was created because Katz wanted a rails-like framework with a better API and a more modular design. A merb-gen’ed ap will look eerily similar to rails app, and the default parts that come with merb do behave a lot like rails, but you can replace them, and that’s the difference.
Merb isn’t a rails competitor, it’s a new framework and it does things its own way, they’re both good and ultimately it’s up to you to choose what you like better, or what’s better suited to the application you are writing.
The last thing the ruby comunity at large needs right now is animosity over silly web frameworks, we’re not rails or merb developers, we’re ruby developers, choose what you like and move on with your day.
Nice article. I just spoke at Merb Day at Atlanta, though the topic my partner and I spoke on were about Merb + CouchDB, and less about getting started.
I like your use of cross-training, and I always have a blast when I spar with my friends in a different lineage. I do want to point out two things. The first is minor — Bruce Lee didn’t train in Tai Chi … the image of him trying to learn it with frustration painted on his face makes me want to laugh. The art he first learned is Wing Chuan, and he didn’t stick around in it long enough to master it.
The second is the idea of “transfer of learning”. This doesn’t just apply from one martial art to a different martial art, or from one programming framework to another. This applies between training in martial art and programming as well, or between any two seemingly unrelated skills. For example, playing weiqi (Go) and enterprise architecture.
I think I get what Pratik is saying — Rails and Merb are both very similar. I don’t use one or the other; I’m using Rails in a current consulting gig, and I plan on using Merb for my next startup idea just as I’ve written a complete app in Merb earlier this year. Rails can learn a lot more from Merb than the other way around; the Merb folks were consciously trying for a new, better Rails written from scratch. The codebase is much cleaner, though Merb still has a lot of polishing to go through. Cross-training between Rails and Merb is like cross-training between boxing and kick-boxing; one’s more focused, the other is more versatile. Both are played in the ring, and there’s not a huge amount of difference (compared to cross-training in whacking things with swords, or playing chess). I disagree with Pratik’s comment wishing that everyone is working towards a common goal.
After seeing Katz’s presentation on Merb 2.0 on Merb Day, the direction that Merb is going, the result will probably wildly differ from Rails as it currently stand. They’ll be able to go down that road because their codebase allows for it, and because their ideology allows for it. However, it is promises right now; we’ll see when we get there.
Pratik: Merb is certainly a worthy venture even if it would only have been about rewriting Rails from scratch. Rails got a lot of things right, but some things are less pleasant (e.g. how rendering/redirecting works – DoubleRenderError and all that) and could be implemented nicer in Merb without all that legacy to consider.
Really, if Merb will grow up to be a better-implemented, more modular Rails, that’d be great for most of us.
Pratik, whats with all the hate man?
Personally I figure the “common goal” is to display ruby (not rails nor merbs) potential to the rest of the programming community. Its ruby in general that should be getting the spotlight.
And look at Matz for instance, he’s not so small minded to just think nothing of Python and Perl…
“Stewart: Why should someone already familiar with Perl or Python switch to Ruby?
Matz: Why should you switch to Ruby? If you are happy with Perl or Python, you don’t have to. But if you do feel there must be a better language, Ruby may be your language of choice. Learning a new language is harmless. It gives you new ideas and insights. You don’t have to switch, just learn and try it. You may find yourself comfortable enough with Ruby to decide to switch to it.”
So if learning a new language is harmless, can’t learning a new framework be harmless as well? Who knows, you might just see something from a different perspective.
Of course I know who you are, http://rubyonrails.com/core, and hell you were my roomate’s mentor for Google Summer of Code. But geez, man, can’t you guys ease up on the hate?
We are very interested in the development of merb.
We’ve worked with rails and will be providing a hosted merb stack for developers.
Hmm, i have been getting that feeling towards the end of this year: that Merb is something i should at least understand a bit about, and know how it differs from Rails. Unfortunately, though, i just don’t like the name. Merb. I think that’s the main thing putting me off!
Pratik, are you doing anything besides trolling on merb blog posts lately? Seriously, everytime I read some merb “news” in the past few days, there’s you in the comments being angry at how evil merb is and what not.
For those interested, there’s an introductory 2 week online course “Introduction to Merb” starting 10th Jan. 2009 here –
http://rubylearning.org/
@Patrik:
“And it has me convinced that those who think it’s different from Rails, don’t basically have a clue about a thing they say.”
That’s a bit harsh. Merb has more understandable code, consumes less memory, and encourages more innovation in its non-core components. These strike me as differences worth strong consideration.
Rails is still a better choice for many people, but failing to recognize and learn from what Merb does differently is a mistake.
“If your framework’s speed/memory usage is a concern for your app, you should reevaluate your selection of platform/language.”
I don’t understand this response. Are you saying that developer’s *shouldn’t* have a look at another framework which uses the same platform and language?
“It’s a shame that a bunch of people are spending all their time/energy copy/pasting Rails from scratch instead of working towards a common goal.”
I’m not sure if you realize how condescending this statement is. It’s especially unfortunate considering Ezra, who created merb, has done so much for the Rails community and for Rails itself.
In any case, I personally am glad that “a bunch of people” are spending their time/energy on Merb. Regardless of the disputed resource usage of the two frameworks, I have found merb to be more pleasant to use in many ways, and I’m enjoying learning it. I also find the source code much more accessible. The community also reminds me of the Rails community 3 years ago, with a higher concentration of knowledgeable people.
I think I understand your frustration at what you see as FUD directed at Rails, and I bet it’s easy to take that personally considering you’re on the core team. But to me, at least, it looks really bad to respond to Antonio’s good-spirited post with such condescension, and to malign large groups of people with statements like “And it has me convinced that those who think it’s different from Rails, don’t basically have a clue about a thing they say.” I think both communities would benefit from more constructive dialogue than that.
I seem to remember Rails being an opinionated framework. If you don’t agree with the opinion of the framework, you can either fight the opinions built into the framework or use a different framework.
Nice post.
IMO, the API docs is the best reference there is.
Wow, lots of stupidity in this thread.
Let me qualify this by saying I’ve been following Merb longer than Yehuda (i.e., he did not write it as someone stated). I know Merb pretty freaking well, and have been familiar with it ever since it was a little Pastie.
Reading this thread sounds like you’ve been indoctrinated by the FoxNews of the Ruby world. Have any of you actually hit any of the edge cases that Rails wouldn’t satisfy? Have you built an app big enough that Rails “scalability issues” and “speed problems” actually appear? I’d wager every one of you except perhaps 2 of you can not answer positively to that. Not even Yehuda.
That’s the ironic thing about Merb. The marketing says that it’s faster, better, awesome, etc., and for small web services, it is by far. Merb-core is freaking awesome. But it sucks as a full-stack framework. Why? Because (a) it’s not built as a full stack so now we have all these issues with dependencies, version mismatches, and instability of components, and (b) it’s built in an academic environment. Yehuda isn’t out there building hardcore web apps every day. He’s sitting at Engine Yard hacking on Merb and Rubinius. That’s an enviable position to be in, but not one that I’d expect to yield battle hardened experience with a tool meant for building web apps.
Rails is really far from perfect, but a lot of the things it does, it does because they learned lessons as they built apps *using the tool* and extracted functionality from them. Merb can’t say it has that heritage.
Oh sure you can come back with “Well, Merb isn’t a full stack!” That’s true, but how many web apps *don’t* use a full stack at some point? Not many, and that assertion is just one of many convenient talking points created by the Merb team to justify this stupid animosity (and don’t act like they’re saints; take a little jaunt in #merb-hacking sometime to hear a bunch of jaded guys with a chip on their shoulder).
Look, I use Merb every day in a number of apps. I like it. But this whole argument is just stupidity I’d expect out of 10 year old little girls, not mature adults who understand how to operate in a community.
@Jeremy Have any of you actually hit any of the edge cases that PHP wouldn’t satisfy? The answer is most likely yes, so why don’t you just ditch Rails and go back to PHP?
@Pratik Instead of putting so much effort into Rails why not help out the Perl/mod_perl community instead? I’m sure you could get more rubyisms into Perl if you really try hard.
@Jeremy Engine Yard works on many real world web applications so does every other contributor to Merb. The work be done is hardly “academic”.
@antonio thanks for the post. I’ve personally found that exposing oneself to many different ideas is a very productive thing to do as a programmer even if I don’t intend to use the technology in question. I’ve personally gotten ideas from Rails (of course!), Mack, Waves, Nitro, Django, Perl, and even (gasp) Java.
Without getting into it, of *course* Merb has a lot of similarities with Rails. Virtually all of us on the Merb core team learned Ruby through Rails and really liked what we saw. To us, Merb is just the further evolution of the ideas that made Rails so great, with some tweaks where we thought improvements were warranted.
We’ve been working on further improvements (and I’ve talked at some length about some of them), but the core ideas of Rails (convention over configuration, DRY, separation of concerns) will almost certainly remain with Merb for some time to come.
Wow Pratik – you really are sinking to an all time low.
So here’s some advice: stop trying so hard to be the first post on anything that praises Merb.
Not only is it getting annoying, it reeks of the tactics of a FUDracker. To be brutally honest, your actions are the kind of behavior that I would hope gets one (at least nominally) dumped off of the Rails core team. Ha, but that’s not going to happen, is it Pratik? Why? Hm.. you should just come clean and say it: this is all part of some ill conceived two-fronted attack you and DHH are mounting against Merb. You spread the FUD directly wherever Merb lives, and DHH, without ever saying the word “Merb” itself, lays it on thick on the Rails turf.
Well, I’ll tell you what, that makes me sick. I mean seriously, HTF do you expect people like you and DHH to lead a community “toward one common goal” if that’s the kind of behavior you find acceptable. Anyway, grow up and get a clue: Merb and its emphasis on being a good Ruby citizen is what we as a community need, not the sham of a monoculture you’re trying to lock us all into.
Peace.
Almost every Merb related posting on popular blogs in the last couple of months has had at least one Rails core contributor responding, usually a bit over-aggressively, and I think that only serves to bring more attention to Merb. I mean, just look at the number of responses to an article that is probably 10 hours old.
Rails is a fantastic framework, but it would be a really bad thing for Ruby if it remained the only strong choice for a web frameworks. Monocultures are bad. Having no competition is bad.
Bringing attention to things like memory usage, threading, speed, code quality, core complexity and modularity is a good thing. Whether or not Merb satisfies these areas better than Rails is besides the point. If there are faster and more efficient ways of doing things we should be discussing them. If one framework has a good idea, we should be borrowing them, and then trying to top them.
If I want to try to write a faster/better/simpler framework, templating language, or ORM, who are you to say my efforts are misguided? I’m learning something and contributing back to the community. Eventually the best ideas will bubble up and everyone will benefit. Infighting does not benefit anyone.
@Carl PHP’s edge case for me was its syntax. 😛 The reasons I hate PHP are the reasons I love Ruby/Rails/Merb/Sinatra.
Hrmmm, seems to me if you want to ‘cross-train’ and you already use Rails that you’d want to look at something other than Merb. Merb is basically a ‘componentized’ clone of Rails. Hell, you can even use ActiveRecord as your Merb ORM layer if you wish.
That’s not to say there is no value in Merb. If you feel that you really do need to customize your framework (ex: you don’t use an ORM and are annoyed that Rails includes one), then give Merb a shot. But if you want to truely cross-train, look elsewhere (I suggest Seaside, Django and Catalyst, ASP.Net MVC if you’re a masochist).
> Have any of you actually hit any of the edge cases that Rails wouldn’t satisfy? Have you built an app big enough that Rails “scalability issues” and “speed problems” actually appear?
Yes. Yes. However we built a custom framework to solve the issues.
Obviously page + fragment caching gets us a long way for most apps. However, there are some problems where its not a good fit.
Regardless of the performance + scalability challenges, its good to have another framework that has a different set of assumptions and goals from Rails. It only makes things better.
Pratik’s behavior is Normal and is described as ‘The endowment effect’ –
Humans (and recently discovered in chimpanzees) think of something
as more valuable once they own it.
As a core member of Rails, Pratik has invested a lot in Rails and therefore values
Rails more than other frameworks, even if objectively they might be better.
It might seems irrational, but it was (and in some cases it still is) essential for our survival:
“Giving up something that could help with survival or reproduction
may have been so risky that it wasn’t worth doing even if there was
the potential for something better.”
Here is an interesting read about it –
http://www.livescience.com/animals/071008-chimp-endowment.html
Guys, a lot of this is not productive conversation.
Each person is entitled to their own opinion about what they like, or dislike, or the best way they think something should be accomplished.
People are not entitled to make aspersions and assumptions about the motives of others.
Let’s stick to the evidence, and the reasons we like things, not calling people idiots or n00bs.
Pratik is still trolling w/o backing up his claims. You guys are just carrying the trolling forward into full on flaming. Unless he actually puts forward his case, people should just keep calling him on it.
MrNeighborly, yer not helping. Software developers are opinionated people. The difference between between trolling and constructive (but perhaps strident) criticism, is that constructive criticism is something you can actually address.
Whoa. Thanks for the love guys. What a nice example of http://www.penny-arcade.com/comic/2004/03/19 for those anonymous comments.
I said “marketing chitchat” because this post/blog is sponsored by EY, who happens to own copyrights of Merb.
Let me repeat the first thing I said :
“I’d LOVE to see some practical example/scenario exhibiting that.”
How about, show me some code ? Only thing wrt that I’ve seen here is ORM. That’s a stupid example because if you don’t want to use AR with Rails, all you need to is config.frameworks -= [:active_record]. This is exactly the kinda of problems I try to address. Make an informed choice. Don’t buy the marketing crap.
Henrik : That’s mainly because Rails is a true MVC framework and merb fakes the V in C ( very good example of premature optimization ). Both approaches have pro/cons. So yeah, whichever one works for you.
As far as the copy/pasting is concerned, here’s a proof of their plagiarism. And I say “plagiarism” because they don’t respect the MIT licesnse, which is a real shame and against the spirit of OSS :
* merb-core
– annotation_extract.rb ( copied from Railties source_annotation_extractor.rb )
– code_statistics.rb ( copied from Railties code_statistics.rb )
* extlib
– blank.rb ( copied from AS blank.rb )
– mash.rb ( copied from AS indifferent_access.rb )
Of course these are just some quick/dirty examples. Which even your grandma can verify by doing char-by-char comparison.
Anyways, I didn’t mean to spawn a flamewar. Just tired of pepople saying things like “more complex, edge cases were Rails’ opinions will end up contending with yours” without actually giving some concrete code examples/use cases. It may be true, but as Ted put it “Let’s stick to the evidence”.
> “more complex, edge cases were Rails’ opinions will end up contending with yours”
Its difficult for me to recall the exact situations, but it happens more often than I would like. Maybe I should keep a journal of everytime I get frustrated with Rails.
Here are a few examples that come to mind that get my emotions stirred up:
1. Making plugins for Rails is hard because things change from version to version. I spent over a day getting Erector compatible with Rails 2.2, while maintaining backward compatibility. ActionPack (specifically the coupling between ActionView & ActionController) was driving me nuts. Its way too complex for (IMO) no good reason. Don’t get me started on the routing code (I frequently have issues with named routes).
2. Ok, so I can contribute a patch to Rails, which does make sense. Unfortunately, I have had bad luck submitting patches in the past. Basically, they have been ignored for a while and became stale. I could go through the effort of pimping my patch, but its a lot of work.
3. AR is great for the request/response scenario. However, if you need to maintain in-memory state, problems arise. The lack of an Identity map forces me to call reload all over the place. You simply cannot rely on having only one copy of a single object, which increases chattiness and removes the option to store state within the models (if you want to and when do you want to store state within the models is another discussion). The lack of an Identity map layer also, IMO, contributed to the rise of overmocking of AR objects.
4. AR is very chatty with the database. This can cause issues for apps that need to maintain state within the process and cannot rely on page/fragment caching, which I admit is not the common case. However, when I ran into this situation, AR was not sufficient.
5. A cavalier attitude for people’s problems that are not the problems of the Rails core team members. I understand the rationale for not baking in something into a framework just to support some edge case, however, there are things that can be done to make a framework easier to extend. A solid public, overridable, and rarely-changing api is a good step.
6. Rails assumes that you use Mocha and has a dependency on Mocha. This would be ok if Mocha didn’t add methods to Object. I don’t use Mocha, I use RR.
Point 5 is very interesting. There are a number of plugin developers who just sort of react to whatever changes happen in Rails. I’m not sure why, but there is not a whole lot of communication outside of a certain circle of people.
When I encounter a problem, I usually try to solve it, and if it seems like (IMO) it was a problem created by Rails, I’ll just roll my eyes and move on. This is not the best way to go about it. I’ll try to be more disciplined and report these sort of issues in the future. I’ll make more time to create patches to Rails core everytime I make a monkey-patch that I think would be useful in general.
@pratik thank you for bringing those license issues to my attention. I have added the required MIT license to the two tools you pointed out, and have added the license to extlib, to cover blank and mash (which have diverged some from the original Rails implementations, but enough of the original code is still present).
In the future, I would appreciate if you would raise any licensing oversight in private before making public accusations. Licensing accusations are serious business and making a statement like you did in public implies that you have already attempted to solve the problem in private with no luck.
Thanks again for bringing the issues to my attention.
Dudes, these are both open-source projects.
Who the fuck cares if Merb is very Rails-like? If it really is easier to slim down, and if it really does have a more consistent API, well, I’m all for that, I’m willing to judge it on its merits.
If in the meanwhile they do something better than you, why, you suck that commit right in and everyone is better off, and everything’s just unicorns and rainbows. You’re already changing everything around when you feel like it, and AR is openly derided as a naive implementation, so why not try to improve? Competition is *awesome* that way.
It totally sucks to lose social status because you no longer get to monkey patch Array whenever you feel like it and tell everyone to go suck it, but in the meanwhile it’d be great if everyone (er, Pratik) were to grow thicker skins and stopped being such insecure twats.
At least I like to think we’re all adults here.
@Ted Uh, that’s exactly my point.
Perhaps you misread or I poorly expressed what I was saying there. Neither of them are perfect at all, and everything I’ve seen from most people have been stupid totally useless microbenchmarks (“Hey hello world renders REAL FAST.”) or just political/emotional crap that doesn’t matter. Constructive criticism is cool, and both Merb and Rails are evidence of that. But creating some sort of war using hand waving and broad aspersions about “scaling” and “speed” and “flexibility” just to have a little controversy is immature.
@Good Sumeritan Ironic that you’d say that Pratik is the one who has a lot invested in Rails when Engine Yard (and by proxy its employees) have lots of time and, more importantly, $$$ (a much more tangible resource than mere entitlement) wrapped up in Merb. Let’s be even handed here. Not to say that Pratik doesn’t have such an investment, but turning a blind eye to the investment from both doesn’t help the conversation.
@Brian I have run into the same issues you describe in the past (9 doc patches lay in wait in Trac for some 8 months before they got attention :)), but fortunately it seems that the core team is a bit more accessible these days and so I haven’t seen that again.
As for plugins, I’d be interested to see what’s broken outside of what I’d consider to be the normal progression of a framework (i.e., overriding existing behavior that changes, which will happen in any framework most likely). I’m *really* interested in watching Merb’s attempt at a stable API, but I fear it may come back to bite them eventually if they take it too far. 🙁
> I said “marketing chitchat” because this post/blog is sponsored by EY, who happens to own copyrights of Merb.
Your implication is mistaken, Pratik. The fact that Engine Yard sponsors my site, simply means that they get to have a banner at the top of the page and a single review of their services if they want. They have never asked me to post, and my opinions cannot be bought. I always call the shots as I see them and this means posting what I think, even if displeases a sponsor, or heck, even my employer, IBM.
More to the actual point, my post essentially consisted of two messages: 1) It’s worth learning both Rails and Merb; 2) Here’s a bunch of links you can use to get started with Merb.
Out of the whole post, the comments have been focused on the words “more complex, edge cases where Rails’ opinions will end up contending with yours”. For years we have been saying that Rails is opinionated software. Are we now denying that? For years, we’ve been OK with the idea that Rails is not the solution to every web development problem, but rather that it’s a great life saver for a large percentage of applications. I believe those assertion are still true and that isn’t the framework’s fault, but rather a design choice.
Now, we can argue whether Merb is the answer for those edge cases or not. The answer in my opinion is “it depends”. Here are a few things to consider:
– Merb, like Rails, is not the answer to every web development problem out there, but being more modular than Rails, it carries all the advantages and disadvantages of this architectural choice. It makes it easier to choose, depending on your requirements, which components are going to constitute your stack (e.g. DataMapper);
– Before ActiveRecord became thread safe, Merb offered a thread safe stack;
– Merb handles simultaneous heavy operations (e.g. multiple file upload) very well.
– Rails’ code has improved a lot in terms of performance, but Merb is still smaller and from what I can see faster, with a smaller memory footprint. Now, you rightfully mentioned that benchmarking Hello World doesn’t prove anything. Early next year I’ll try to run more interesting benchmarks against Merb and Rails to see how they compare for a simple, but “realistic” application.
I believe it’s in the interest of the Ruby community to have more than one established and widely adopted framework. Let people try out more frameworks, and decide to use whatever they like. Please also note that no one is dissing Rails here. I love Rails, it’s the framework I use the most – heck, I’m even writing a book about it. What I’m saying here is that even if you consider Merb to be a fork of Rails, there is no reason to hate the project. Innovation derives from a free exchange of ideas and the ability to experiment with new projects. That’s part of the reason why Dave Thomas encouraged people to fork Ruby. If a clone of Ruby is innovative, Ruby itself will benefit from it. In other words, Merb and Rails can learn from each other, if the two camps are willing to work together and not against one another.
Finally, you made a big accusation about licensing violations. Have you brought this to the attention of the Merb core team? And if so, what did they reply with? Casually mentioning it in a blog comment is probably not the best way to go about resolving possible license violations. I realize that you used it as a means of making a point, but I wouldn’t be surprised if this was just some old code whose license has accidentally been left out. If an acknowledgement and/or the credits are missing from some files, I’m sure this would be promptly rectified, if you let them know.
Edit: Yehuda already replied and corrected the issue.
http://ramaze.net/home#other-frameworks
It’s been a big world of Ruby Web tools for some time now. Even when Rails was first released we had Cerise, IOWA, and Nitro. There were fast, scalable, thread-safe options years ago.
All things considered, debating Rails v. Merb comes off like arguing Coke v. Coke Zero Cherry when you can be drinking ice water or champagne or moonshine or a dozen other choices.
There are a *lot* of cool thing going on in Ruby Wed dev; please don’t waste energy debating minutia. Go build stuff.
So what would you say is the cognac of Ruby web frameworks? because that’s what I want.
@R. Elliot Mason
Waves is definitely the cognac. Leave MVC behind, embrace Resource Driven Development, Code Ruby & Nothing Else!
Actually, we do use a very small DSL for our resource mappings, but other than that we make very few changes.