Comments on: Learn Merb

By: ab5tract

ab5tract — Mon, 12 Jan 2009 00:24:32 +0000

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

By: Quer aprender Merb? | Ruby Brasil

Quer aprender Merb? | Ruby Brasil — Fri, 19 Dec 2008 09:23:22 +0000

[…] [Via Antonio Cangiano] […]

By: R. Elliott Mason

R. Elliott Mason — Wed, 17 Dec 2008 21:44:13 +0000

So what would you say is the cognac of Ruby web frameworks? because that’s what I want.

By: James Britt

James Britt — Mon, 15 Dec 2008 03:04:03 +0000

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.

By: Antonio Cangiano

Antonio Cangiano — Sun, 14 Dec 2008 21:08:43 +0000

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

By: Jeremy

Jeremy — Sun, 14 Dec 2008 20:37:09 +0000

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

By: Phill

Phill — Sun, 14 Dec 2008 20:08:23 +0000

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.

By: Yehuda Katz

Yehuda Katz — Sun, 14 Dec 2008 19:32:42 +0000

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

By: Brian Takita

Brian Takita — Sun, 14 Dec 2008 19:26:12 +0000

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

By: Pratik

Pratik — Sun, 14 Dec 2008 17:19:52 +0000

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