Merb has come along way since Luke first examined it here over a year ago. The philosophy remains the same: “All you need. Nil you don’t.” But the implementation has changed a bit, and it is far more mature.

Like Rails, Merb is a MVC web framework written in Ruby. Unlike Rails, Merb doesn’t tell you what ORM to use – you can use ActiveRecord, but DataMapper and Sequel are a bit more in line with the Merb philosophy. Similarly, Merb supports several Javascript libraries and templating languages, and doesn’t recommend one over another. Merb strikes a balance between Rails (large and full-featured) and Camping or Sinatra (tiny), but it is closer to Rails; one gets the sense that a large, complex site could be reasonably maintainable in Merb, unlike Camping or Sinatra.

Merb got a lot of attention at RailsConf this weekend, and will probably get even more at RubyFringe and RubyConf, and it seemed like time to review it again, about a year after our first look. Ezra Zygmuntowicz, creator of Merb, was kind enough to give us an interview.

Rail Spikes: How much production use has Merb seen so far?

Ezra: A lot. We have about 40 or so Merb apps hosted here at EngineYard. A few of them are doing 2-8 million pageviews/day with Merb rock solid at 35Mb ram on a 64 bit system.

Rail Spikes: Merb is thread-safe, unlike Rails. What advantages does thread-safety bring to Merb?

Ezra: It allows for long requests to not block the process, effectively letting multiple requests get served at once. This can drastically reduce the latency any one user gets because requests do not get backed up behind longer requests waiting for their chance to run.

Rail Spikes: So do Merb apps typically use a single mongrel/thin instance, or multiple instances?

Ezra: Merb apps still typically use multiple processes, but they require less processes then an equivalent Rails app by far.

Rail Spikes: Is the only advantage of multiple instances to make use of multiple CPU cores? And will a natively threaded Ruby implementation allow us to use a single app server per box?

Ezra: Yes, it is to use multiple cores and to spread out the load. Natively threaded ruby implementation will allow us to use much fewer processes, but running an app out of a single process is still a bad idea in case the instance crashes, so load balancing over a few processes helps increase uptime if there is an issue with any single process.

Rail Spikes: Does one need to use a thread-safe ORM like DataMapper to take advantage of this, or does ActiveRecord::Base.allow_concurrency = true work just as well?

Ezra: Yes – you need a thread safe ORM like DataMapper or Sequel. ActiveRecord::Base.allow_concurreny = true does not work well and should be avoided for now.

Rail Spikes: Merb has long been agnostic about things like ORM, templating language, and Javascript/ajax libraries. Will that continue, or will Merb ever “prefer” one systems over others? And is Merb test framework agnostic, or does it prefer rspec?

Ezra: It will continue as much as possible. We do favor rspec over test/unit so that bias does show a bit. I also personally prefer DataMapper as my ORM. But Merb will definitely remain ORM agnostic as I think that going forward there are going to be all kinds of interesting non-relational data stores to build web apps on. Merb will be right there at the forefront easily using any new persistence layer that pops up.

Rail Spikes: You’ve written that Merb and Rails can get along. Would you use Rails instead of Merb for some projects? If so, what and why?

Ezra: Rails is a more complete end to end solution; there is a large ecosystem and plugins for almost everything. But Rails is also a large bloated codebase so if you want to step outside the golden path of the framework you will often run away screaming. ;) Merb is more of a platform for you to build whatever it is you want on it. The framework code is simple and to the point so it is very easy to extend and bend Merb to your will when you run into a problem that the framework has not thought of or dealt with before. In the end I think this makes for a more scalable framework for serious hackers to build interesting new stuff I have never thought of.

So Rails may get you up and running quicker, but Merb will scale further as your application needs to go “off the rails” so to speak.

Rail Spikes: Beyond the docs, what is the best resource for a Rails developer looking to learn Merb?

Ezra: There is a Merb PeepCode that is pretty good, and the merbunity.com site is good. The Merb wiki is starting to have a lot of information. There is a book coming out soon from Manning called Merb in Action, written mostly by Michale Ivey and Yehuda Katz with me as an advisor/proofreader.

Rail Spikes: Can you point us to any speed benchmarks?

Ezra: I don’t have any prerolled benchmarks at this point. But I can say that in general Merb’s routing, dispatching, request parsing, filters and rendering are dramatically faster then ActionPack. I encourage folks to run their own benchmarks as microbenchmarks are rarely helpful.

In general Merb can serve a hello world action at 2500req/sec on ebb and can serve a simple template wrapped in a layout action at 1700req/sec or so on a Macbook Pro.

Rail Spikes: What is the 12-month plan for Merb?

Ezra: Merb 1.0 will be released sometime this summer along with DataMapper 1.0. I don’t have a long term 12 month plan for Merb, but I think that 1.0 will be a super solid platform for folks to build on top of. I don’t believe in having Merb become a kitchen sink framework, I’d rather see a tight/fast/documented core and let everything else be plugins so we don’t end up bloating the core framework.

Rail Spikes: Thanks!