Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.
Can’t we all just get along?
May 21st, 2008
Following up on Ezra’s great post today, I wanted to throw out my thoughts on the topic.
Pretty much since I got started on the Merb project (which I did primarily to get an awesome mailer in; I spent a long time wrestling with ActionMailer on a corporate project), people have looked at the Merb project as competition for Rails.
Honestly, to some degree, we’ve fueled that by providing benchmarks and comparisons between Merb and Rails. And since our architecture is so similar, it’s only natural that people’s initial reaction upon looking into Merb is, “Why should I use this instead of Rails?”
The truth is, Merb scratches a completely different itch from Rails. Rails was responding to the almost comical amount of configuration needed to get started on the Java or PHP “stacks” at the time. Its siren song was in making as many common choices for you as possible so you’d be able to start building your app quickly and efficiently.
Rails was a massive success. It changed the way the world looked at web development. Struts 2 touts convention over configuration and Cake PHP is virtually a clone of Rails.
Today, Merb exists not to supplant those ideas, because we fundamentally agree with convention over configuration, the common usage of the MVC pattern, the use of RESTful resources, and a bundle of other things that Rails introduced to the world. Instead, our niche is making life easier for hackers, those who find themselves repeatedly delving into the framework itself to squeeze the last bit of performance or customization out of it.
It is true that we think there are concepts in Merb that are incremental improvements over Rails. But we are not unhappy when those things make their way into the Rails core. Last month, Ezra spent a week porting over Merb’s rack support into Rails, and I spent a day improving the speed of the Rails Inflector by an order of magnitude. We’d love to see our
provides API make it back into Rails, and we’ve already begun to see Rails focus more on efficiency and speed in the past few months.
The fundamental difference between Merb and Rails, the one that will likely remain as the most salient features of Merb slowly find their way into the Rails codebase, is our emphasis on hackability, and the Rails emphasis on get-up-and-go. We do not see this as a competition; we see it as a way to widen the appeal of Ruby (the language that we all love), and to keep people who fell in love with Ruby through Rails from falling out of love with Ruby when their needs become more about squeezing the very last drop of performance and customization out of Ruby.
To that end, I intend to continue pushing improvements from Merb back upstream to Rails. Some of them, like my Inflector change, will likely take some time to make it all the way back to the Rails trunk because they may break backwards compatibility, but the patches will be sitting in my github repository for the next backwards-compatibility breaking release :)
Let’s all be friends!
Ruby will be better for it.