Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, like Thor, Handlebars and Janus—or traveling the world doing evangelism work. He can be found on Twitter as @wycats and on Github.

Rails is a Pre-Fab House

At RailsConf, I had the opportunity to speak to a lot of people about Merb. I also listened to DHH’s keynote, which touched on some related concepts.

People coming from a Rails background, and are looking at Merb for the first time, wonder why they should throw away the phenomenal efficiency improvements they got from switching off of error-prone, tedious configuration scripts for another set of configuration when Rails makes all the decisions for them. DHH made this point fairly explicitly in his keynote. To sum up, he argued that people only think they want to make decisions; instead, they really want to be given a fully working, homogeneous solution so they can get on with their business.

Believe it or not, I agree.

The devil, as they say, is in the details.

In the real world of software applications, the monolithic solution doesn’t always fit your needs perfectly. That’s why Rails implemented, very early, a plugin architecture, which immediately reduces homogeneity.

You see, Rails is like a pre-fab house. For people who have gone through the pain of constructing a house before, pre-fab houses are very appealing. Suddenly, there’s no need to spend time with architects, contractors, or painters. You just place an order and you get a house. It seems great. You can get the furniture you want, or even repaint it.

And when you need to bring in a contractor for routine maintenance, you can have your pick of contractors. Because your house is the same as every other house they worked with. But soon you decide you want a window. Unfortunately, your house is pre-fab, so you pick up a hacksaw and hack away. Everything seems great until the first time it rains. And the water starts coming in.

Undaunted, you pick up the phone and call all those contractors you worked with before. When they get there, they take one look and let out a sigh. They have no idea how to deal with the glaring mess you have made for yourself. After paying a hefty bill to get everything fixed, you tell yourself that it’s still worth it. After all, you’re still ahead on time compared to Andy down the block who had to do everything from scratch.

But you see, there’s another option.

At a builder’s show, you see a shiny booth run by a new company called Mer Builders. They have put together a house kit that allows you to put together your house quickly and efficiently. And when you want a new window, you just pull out one of the wall blocks and replace it with a window block. Quick and easy.

But wait, you are probably thinking. I still need to put together the house. That smacks of all the pain of building a house from scratch. It’s not as bad, but I’ll still need to decide what pieces I want, figure out how they hook up, hire someone who knows how to put everything together, and more. Who wants that. A pre-fab house will do just fine, thank you very much.

As you turn to leave, the Mer Builders salesperson calls after you. You see, it turns out that they understand that you’d rather not have to make all those decisions yourself. And they’ve put together a starter kit that looks kind of like the pre-fab house. You can order it today and have it delivered tomorrow. But when you want to replace a window, their network of certified Mer engineers will simply and easily swap out a wall block for a window block.

Heck, soon enough you’ll probably be doing all sorts of customizations on your own.

The moral of the story is… Use Mer Buil… er… Merb!

23 Responses to “Rails is a Pre-Fab House”

I bought pre-fab houses that I extended and I put together Merb houses.

My personal experience is that you can extend your pre-fab houses as long as you stick to the Rails conventions. But if you want to do something different, make your house energy efficient or require just a tiny beach house… the pre-fab solution won’t cut it.

Also, Rails has more turn key solution and you can get a jacuzzi installed on your roof in 30 minutes. Now it may leak a bit into the leaving room, but cleaning women are cheap and repainting the house every 6 months is common practice.


Another problem with the Mer Builder solution is that they haven’t built the kitchen sink module yet. Also, each module comes half painted.

@Carl Who needs a kitchen sink anyway? I kid I kid.

We’re working on it ;)

1.0 will be out this summer. Hoorah!

I totally do not get this. Are you saying that you can only write webapps in one particular way when you’re using Rails, and that changing stuff – e.g. inserting a window somewhere or whatever – is not possible with rails? Have you ever written a Rails app? Totally lame comparison, fail.

leethal: Have you tried writing RoR apps that don’t conform to RoR best practices? Have you tried doing it on a big scale? Have you then suddenly realized that jumping through the hoops that needed jumping made you loose all the time you gained by using RoR?

@leethal see my About page.

I guess we could say that if you want a stained glass window in a modern Rails-built house you’re screwed, but that’d look really weird on a modern house.

And of course the new house won’t fit on your old foundation (read: legacy database), but that foundation is old and sloppy anyway, you’d want to build a new.

Meh, how lame, of course you can insert a window in a Rails house.


Most of “Rails developers” like you would greatly benefit from reading computer science classics and trying to work with complex data structures using ActiveRecord.

What?! 32 queries per request? ActiveRecord said to be so awesome!

I can buy that it may be easier to stray from the “golden path” without detailed knowledge of the framework internals with Merb.

But I don’t buy for a second that maintenance will be much much easier. Regardless of framework, you have to take the time (as a contractor/new hire) to get into the app (and you’ll always end up in darks corners where you’d go “wtf where they thinking”) and try and and figure out how all the cogs works together. Depending on the size of the app, sorry house, there’ll be loads of domain specific solutions fitted into it that you’ll have to figure out.

leethal: If Rails is a prefab house, then no, you can’t insert a window easily. Where are the studs in the wall? Will you have to add more for support? What if the plumbing goes right through the spot where you want the window? What’s on the outside of the wall?

Prefabs limit your choices, which is the point of the analogy.


Any non-trivial rails site requires customization. Heavy customization. And due to the way Rails is implemented, the more you customize, the less like Rails your application becomes. As a result, you lose the compatibility not only in terms of software (i.e. plugins and the like), but also in your ability to hire people who know Rails (well, that or you need more to time to train them).

Rails lets you paint yourself into a corner, or worse yet, lets plugin authors you rely on paint you into a corner (the company i work with has had that happen). Then you get to spend your time undoing other people’s bad decision making in order to continue moving forward.

Wycats’s point, as i take it, is that merb is modularized to a degree where if a chunk of your app is causing you trouble, you can just pull it out and replace it, even if this component is central to framework (good luck pulling active record out of Rails). I don’t know if Merb does this better, but Rails’s capacity for this is certainly mediocre.

Just as long as you don’t take your lovely Mer Builder house and set it up in France like the rest of the Pre-fabs! Right cats? Hahaha…


“As a result, you lose the compatibility not only in terms of software (i.e. plugins and the like), but also in your ability to hire people who know Rails (well, that or you need more to time to train them).”

more time to train them compared to what? Teaching someone your customizations while leveraging their previous knowledge for everything else (i.e. rails knowledge) is less time than if they had to learn your whole setup.

“Rails lets you paint yourself into a corner, or worse yet, lets plugin authors you rely on paint you into a corner (the company i work with has had that happen). Then you get to spend your time undoing other people’s bad decision making in order to continue moving forward.”

I’ve had this happen as well, but this isn’t rails fault. It’s the fault of the plugin authors and whomever made the decision to use that plugin. I learned very fast that most plugins are crap and I had to review them before allowing them into my apps. Again, this is not a rails problem and you’ll find it anywhere you try to use third party code. Code reuse is hard, period.

“Wycats’s point, as i take it, is that merb is modularized to a degree where if a chunk of your app is causing you trouble, you can just pull it out and replace i”

Again this goes against your argument about training time. Someone coming into a project where you did this will require more training than someone coming into a rails project with some customization.

@jshen my point had more to do with how a framework should go about providing ways to customize. Rails encourages the extensive use of things like alias_method_chain to extend any part of the framework. As a result, it’s not easy for them to refactor and improve things because literally every method in Rails is considered “public API.”

Merb exposes very explicit modular extension points, and we’ve given a lot of thought to exactly how things should fit together. It’s much harder, but the benefit is that we don’t use Ruby’s metaprogramming facilities in lieu of a known developer API, and we can refactor internals much more easily.

In addition, it’s a lot *less* likely that plugin authors will stomp on top of each other (although I agree that you can’t eliminate that possibility entirely). In effect, we’re taking convention over configuration to the next level and handing it to the PLUGIN authors.

@wycats: I was just having some fun with the metaphor :P.


I plan to try out merb once it’s at 1.0 and has good documentation. I think the goal you laid out is a good one. There are a few other things that would lead me to switch to merb overnight (for my personal projects). If I can add another merb application to my site, like a blog app under /blog, AND not have to run 3 more separate mongrel processes for it as I do with rails. Also, if I can run it under jruby and not have to run separate processes to handle simultaneous requests. I can go on, but it’s just the standard rails issues that everyone is aware of.

The first is big for me because I do a bit of consulting and most small/medium sized businesses want a custom site, a blog, and a message board or some such. Having to run 9 processes at minimum is prohibitive to say the least.

I have no idea if merb addresses these issue or plans to, but I’ll switch if it does.

I’m in the process of migrating a Rails app to Merb. It’s currently running on two different slices of the same hardware. The Rails apps take 110 MB each. The Merb apps take just over 40!

the more I use merb the more I like. only thing I’m going to miss (a lot) is RPM.

@jshen the purpose of merb-slices, which was released to some fanfare a few weeks ago, is to allow exactly what you suggest. You simply install a slice (blog) to an existing app and it can have routes and everything. You can also override individual parts of the slice (routes, views, controllers, models, JS, etc.) by simply putting the overridden stuff in /slices/* and the stuff in there will win over the defaults in the slice.

Because Merb is threadsafe, I don’t see any reason why it wouldn’t be able to handle a ton of simultaneous requests in one JRuby process. Ping me on IRC (wycats on freenode) and we can discuss that a bit more.

I think the prefab you are thinking of is Drupal or Mambo?

Seriously, Rails is plenty flexible for the same target space as Merb. The plugin architecture and ecosystem is a great strength too.

I think it’s great that we have both Rails and Merb. Right now Rails fits my needs very well and so I don’t feel a compelling reason to switch to Merb, but if I need something different that a pre-fab house I think its great that I have more options available without leaving Ruby. I think it was very important for Ruby to have one app with a lot of focus and momentum to draw people in, and now I think that Merb is just what we need to challenge Rails while also giving more power to Ruby.

I totally agree.

You seem to have neglected, however, what Rails is really good for. It’s really good for people who have never built houses before.

It’s also really good for people who have been stuffed around by other dodgy prefab companies before – have had their houses built in really bad materials.

It was the first framework that let people focus on the important code decisions rather than the logistics of writing the code.

Truth is, Merb would BE without Rails, and I think you, as developers of Merb, need to respect that.

I’m not in any way bagging out Merb. Merb is necessary and very useful, and I love it a lot.

Now, the interesting thing for me, is that Rails is SORT-OF going down the microsoft route in that it has to maintain backwards compatibility and versioning.

I *hate* backwards compatibility and versioning. There should be versions for bug fixes, but I’m not too much of a fan of versions for new feature sets, changes in API, etc.

What I would *love* is if Merb had a set of releases – For instance Merb “BlahBlah”. Marketing departments might not like this much, but opensource software doesn’t have marketing departments. It’s like “okay, we have a set of goals for merb BlahBlah, and the project will be FULLY COMPLETE when these goals are released” in exactly the same way that unix commands are small, nice pieces that fit together well and should never break their own API’s and syntax.

Does that make sense?

If I have a program, and all it has to do is take one number, and multiply it by 5, then the only “versions” that should be released for it are the versions that fix bugs in it. It is simple, and small, and tiny, and works its job, and that is all it does.

It is, essentially, its smallest part. Why would we need to upgrade it? From a marketing point of view, with Micrsoft Word, or Windows, or whatever, they want to keep making money, so they want to push “upgrading”.

My idea is … Merb “BlahBlah” (or “chocolate” or “puma” or “funky” or whatever you call it) should do ONLY what its spec says. Nothing more. So Merb Core BlahBlah will have a spec, an API, and that is that. It is either finished or it’s not, but it will never do more than its spec says. Thus we have a clearly defined API and we ALWAYS know what it does.

I’m fairly sure this is what you’re trying to do with Merb: to get the simplest set of API’s possible across smallest-possible objects. If all the pieces are very very small, and they all do only one job, and one job well, and they all fit together very well, then fixing it will be easy, changing it will be easy, etc.

In short, I love you guys. :)

Leave a Reply