InfoQ had the opportunity to talk with the creator of Merb and the founder of Engine Yard, Ezra Zygmuntowicz
Robert Bazinet (RB): For those not familiar with Merb; What is Merb and how is it different than Ruby on Rails?
Ezra Zygmuntowicz (EZ): Merb is a web application framework with many similarities to Rails. The main difference is a focus on understandable, non-magic, fast code. There is a tight core framework that can be used to build high performance web services and then there are opt in plug-ins and additional features that can be cherry picked from. This keeps Merb-core small and fast while still allowing for full-blown applications to be constructed. Merb is also ORM, JavaScript and Testing framework agnostic. It has official plug-ins for using AcitveRecord, DataMapper and Sequel ORM's and can easily be used with CouchDB or ThruDB or other data stores.
RB: What type of developer or type of project is Merb designed for?
EZ: At this point I would say that Merb is more targeted for intermediate to advanced developers. It doesn't have all the training wheels that Rails has, but it also tries hard to adhere to ruby idioms and gets out of your way when you need to do something custom. Merb aims to be more resource efficient on the server then rails has become, currently it uses about half the memory and is approximately 2-5 times as fast at dispatching and rendering.
RB: Merb 0.5 was recently released; What are the milestones with this release?
EZ: This release has a bunch of polish and new features. It is still a development release but is being used in many production situations already.
RB: Merb 0.9 appears to be the next official point release and will be broken up into a Merb-core gem and a package of other gems. What is the advantage to developers for this?
EZ: The advantages of this approach is keeping the core framework small, understandable and *fast*. This means you can get close to the metal and get really fast requests for web services and SOA/REST type back ends. Instead of packaging the kitchen sink like Rails with no way of trimming things down, Merb starts small and allows you to cherry pick only the features you need for your applications. This saves costs and increases performance when it comes time to put your application into a production environment.
We will have a Merb meta gem that will install the Merb-core and a collection of plug-ins so you can still have a quick start full stack framework for prototyping. But I think it is very important to keep the modularity to avoid the bloat that rails has accumulated.
RB: Why is the team doing a 0.9 release and a 1.0 release and not just going to 1.0?
EZ: 0.9 will basically be Merb 1.0 RC. We are doing major refactoring here so we want people to use Merb 0.9 for a little while to flesh out any issues before we pull the trigger on Merb 1.0
RB: Merb has been in development for a while now and getting to 1.0 must be a relief. How do you feel about where Merb will be at 1.0 and how you envisioned 1.0 back when it was started?
EZ: The first release of Merb 0.0.1 was in October of 2006. It has grown organically since then, from a small toy hack into a full fledged framework. It is a relief that we are getting close to 1.0 and I am very excited about the platform people will be able to create with Merb. I feel that Merb 1.0 will be a major milestone for Ruby as a web platform. I hope to finally kill off the meme that Ruby is always slow. Ruby can be quite fast when the proper care is taken in coding standards.
RB: What is the team doing in the area of tutorials, screencasts, and documentation beyond API documentation for 0.9 or 1.0? What can we expect to help developers get started?
EZ: Yes with the release of 0.9 on the way to 1.0 we will have a community doc and central plug-in site with a wiki, forums etc.. There are also a few Merb books in the works. A few of the community members are working on various screencasts also.
Expect extensive centralized documentation and tutorials to be released by or before Merb 1.0. We have adopted a new documentation standard for the Merb code base and we are using it extensively in Merb-core, we will apply the same standard to Merb-more and all the plug-ins before 1.0 is out.
RB: Merb 1.0 will be a stake in the sand, in my opinion. A 1.0 release often is indicative of a product arriving, as a Ruby on Rail developer how can the team help me transition to Merb?
EZ: We will have rich, professional documentation and tutorials along with the 1.0 release. We will of course take into account that many people will be coming from Rails to Merb and will make sure to have proper information to help ease the transition.
One of the key ideas behind Merb is to keep the framework code simple, small and non magical. This eases development because the framework is not so much a black box. It is approachable and hackable to do anything you might want. I've felt the pain of trying to read the Rails framework code way too many times to repeat some of the mistakes they have made and I hope to steer Merb in a direction that will allow for not only a scalable framework, but a scalable code base for the future.
We have adopted a standard in the code base of @public, @semipublic and @private specs. After 1.0 we will not break @public APIs, @semipublic will allow for some changes but we will try to keep those to a minimum. @private API's will keep us free to refactor the internal implementation as long as we do not break @public or @semipublic specs. We feel that this will help us avoid some of the problems Rails has with backwards compatibility hampering innovation and stifling the code base.
RB: Ezra, thank you for taking the time out of your busy schedule to chat with me about Merb.
One of Engine Yard's new software engineers, Yehuda Katz, gave an update on his blog about the plans for the next versions of Merb. Yehuda gives us details on some of the points Ezra told us about.
He explains some important details of the new Merb-core gem:
Merb Core is also based on a Rack adapter now, so it’ll work out of the box with Mongrel, Evented Mongrel, FCGI, regular CGI, thin, webrick, and Fuzed, as well as any server you can write a rack adapter for. And fear not, you’ll still have access to the raw mongrel request if you want to do fancy stuff like streaming or deferred rendering outside the mutex.
More information on refactoring Merb into Merb-core and the changes we can expect:
In an effort to keep Merb core really tight, we’re also adopting some more formal programming and documentation techniques that will make working on and using Merb much easier:
- All methods (public and private) are required to provide a clear method signature, including the types for any parameters, and the possible values for any options hashes, as well as return types and other information (see below for an example).
- Methods can be tagged @public, which means that changing them will break the public API. Methods can also be tagged @semipublic, which means that they’re used in other parts of the framework and possibly the test harness. This’ll aid future refactoring, because methods that are not public or semipublic can be reimplemented at will as long as the test suite still passes.
- We’re removing all hardcoded paths from the framework. This means that Merb will scale from a single-page app to any application structure you want. You can even specify how to name template files (you can go from the traditional controller/view.mime.type or controller.view.mime.type or even view.mime.type for a single controller app)
- We’re splitting our test suite into public and private tests. Public tests test the public API, while private tests test things like the Request object. Public tests are required to use only methods in the public or semipublic API, so they should still pass after major refactors.
Documentation seems to always be lacking in projects and especially in open source projects where there doesn't seem to be enough resources. Yehuda points out:
The documentation format will be itself documented as part of the Merb Core release, and we hope to write a parser that uses RDoc to spit out just the public API (leaving out public methods that are not marked @public).
Merb is certainly getting much attention in the Ruby community as of late and appears to be a solid alternative to Ruby on Rails. Readers can find more information about Merb from their web site or read about Merb here at InfoQ in a previous article by Sebastien Auvray titled High Performance Ruby MVC: Merb which gives a good introduction to Merb. Follow updates to Merb on Ezra's blog as well.
