Please note: This site's design is only visible in a graphical browser that supports Web standards, but its content is accessible to any browser or Internet device. To see this site as it was designed please upgrade to a Web standards compliant browser.
Signal vs. Noise

Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)

Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List

Subscribe to our free newsletter and receive updates on 37signals' latest projects, research, announcements, and more (about one email per month).

37signals Services
XML version (full posts)
Get Firefox!

Ruby on Rails to Basecamp

21 Mar 2004 by David Heinemeier Hansson

The use of Ruby and Rails in developing Basecamp seems to have sparked interested in both language and framework. So if you want to learn more about Ruby, I’ve compiled a Getting Started list of references. If you want to know more about the Rails framework, have a look at the overview presentation.

20 comments so far (Post a Comment)

21 Mar 2004 | anon said...

hrm, why use ruby when you probably could have developed this thing in less time with php?

plus, you could find a lot more developers that speak php... (i.e. maintaining this beast in the future would be easier)

is it just some desire to be different than everyone else?

21 Mar 2004 | David Heinemeier Hansson said...

Before finding Ruby, I spent about four years developing PHP web-applications (including a few for 37signals), so I think I can say with some authority that we most certainly couldn't have developed Basecamp in less time with PHP. On the contrary.

On the subject of finding developers, we've found exactly the reverse to be true. It's really easy to find highly qualified applicants for Ruby development.

Jason posted a small note some time back that we were possibly looking for some help. We received a ton of extremely qualified applicants that we're more than just a little interested in getting Ruby work.

This is so because Ruby is still a relatively unknown language in the mainstream, which makes Ruby job listings few and far in between. So when an opening finally comes along, you have a large community of devoted Ruby fans eagerly applying.

So far the data we're getting seems to fly counter to your arguments. For more on the same subject of niche languages, I recommend the Smalltalk blogger James Robertson -- like this post on productivity.

21 Mar 2004 | anon said...

I have a real problem believing that coding a somewhat complicated system (doesn't look like Basecamp is that complicated) in some obscure language like Ruby would be faster than in another language that has a bigger developer pool.

Maybe you are not intimate with the PHP libraries available nowadays, like Horde or even PEAR ? I'm not trying to put you down, but I really can't see how it would be slower to code something in PHP than in another language, especially one that you don't know intimately (which I think was your case in the beginning, right?).

There's obviously a bigger developer pool in the PHP world, and that means a bigger percentage of 16-year-olds doing guestbook type applications that will answer to a possible "PHP developer wanted" ad ;)

However, I don't have any difficulty in finding experienced people in PHP...

This is all very strange, choosing ruby over any other tool, especially a tool aimed at web development kind of reminds me of the alternate universe with the weird superman (bizarro was his name?)...

21 Mar 2004 | David Heinemeier Hansson said...

When you say "I really can't see how it would be slower to code something in PHP than in another language" then you've already closed all ears to argument. If you think PHP—or any language—is the be all, end all of development in any domain, I can only wish you the best of luck in your future endevours. Perhaps you could be so kind as to reveal your name, so future clients could know that this is your opinion and choose their engagement so advised?

The bizarro world is the one where inertia rules the land and any tool but the one in your hand must be feared or distrusted. If you're interested in stepping back into the world of informed opinion and facts with specific questions instead of meaningless slander, let me know. I'm happy to answer based on my experiences with developing both PHP and Ruby and with the data we have on finding Ruby programmers.

21 Mar 2004 | dusoft said...

Could you tell us the differences between Roby and PHP? I would like to know - I could probably do a search on Google, but it's better to read it from someone using both.

21 Mar 2004 | Paul Hart said...

I'm interested to know what made you want to choose Ruby over Python? My understanding is that they have a very similar feature set. I've chosen to focus on Python for my own web development, though I'm stuck using Java in the office.

As for the whole PHP argument, doing anything in an MVC way is a real pain in PHP from what I've seen. It might be good for something quick and dirty, but I wouldn't want to build a major project using it. If I had to build it and maintain it, I'd definitely steer clear! :)

22 Mar 2004 | Jameson said...

I've been a PHP developer for a few years. I didn't choose it initially, per se, but it was pretty easy to learn and I've had success with it so far. Jason's post for a Ruby developer was the first I'd heard of Ruby, and learning that Basecamp was developed using Ruby has made me very curious about it. I too would be interested in hearing your comparisons. Not that I am skeptical of Ruby at all; I'm curious about it with an entirely open mind and -- as dusoft said -- I think you'd be the perfect person to lay out the compare/contrast between Ruby and other languages.

22 Mar 2004 | anon said...

When you say "I really can't see how it would be slower to code something in PHP than in another language" then you've already closed all ears to argument. If you think PHPor any languageis the be all, end all of development in any domain, I can only wish you the best of luck in your future endevours.

Whoa, don't get touchy just because I'm trying to argue over what you said about not being able to do the same project faster in PHP.

What is interesting to me, and I kind of remember reading this in your weblog, is that you started work on Basecamp in Ruby without any prior knowledge of Ruby. So yes, it seems "bizarro" to me the idea of anyone starting a project in a programming language they never tried before, and finishing it up faster than in a language that they use for over four years, as you stated above. That's all I'm saying :)

So since you opened the door, why do you think it was so much easier to do this project in Ruby than in PHP? I would like to get the reasoning to see if I should go do another look at Ruby.

22 Mar 2004 | Ian said...

He has put forward his position in a rather convincing account. I doubt there is any question of his ability as a PHP programmer considering that he said he had been doing it for 4 years. If you are interested in looking into ruby, do so. If you aren't, nobody is forcing you.

What Im wondering is: how did he find out about ruby?

22 Mar 2004 | David Heinemeier Hansson said...

It sounds like an excellent idea to have some side-by-side comparisons of Ruby and PHP. I'll try to cook up some good examples shortly and post them to Loud Thinking.

On Ruby vs Python:
Yes, functionally, Ruby and Python are really close. In terms of elegance and consistency, though, Ruby feels (this is both subjective and non-quantifiable) way ahead to me. Especially when it comes to the level object-orientedness and the widespread use of blocks. There's an informed comparison done by a Python guy at Ruby Garden.

On doing maintainable development in PHP:
It is certainly possible to do both object-oriented and maintainable development in PHP. I did just that for more than a few years. Rails is built on principles I realized and used in PHP.

Most languages has a sweet-spot, though. A range of tasks it does better than any other language. Building MVC-style web-applications with an attempt to foster a reusable framework isn't the sweet-spot for PHP. As I said, it's doable, but I found it much more painful than doing the same in Ruby. Likewise, I probably wouldn't use Ruby for a quick little thing little adding some level of dynamics to the 37svn blog. PHP has a sweet-spot for getting simple things working really fast and on a ton of web-hosts. The longer you move beyond that sweet-spot, the more painful it gets. (PHP5 moves this sweet-spot closer to my needs, but still falls way behind Rubyin my ever humble opinion).

On finding Ruby:
I've long been an admirer of both The Pragmatic Programmers and Martin Fowler. The former wrote the seminal The Pragmatic Programming, many brilliant articles for IEEE Software and latest the Pragmatic Starter Kit. The latter wrote Refactoring, Patterns of Enterprise Application Architecture, and a range of other interesting books.

Both the Pragmatic Programmers and Fowler had used coding samples in Ruby to illustrate programming lessons and in general talked with much fondness about this all object-oriented language with unrivalled elegance. This lead me to Programming Ruby, which in turn introduced to a community of immense devotion to this language with Japanese roots.

And now I truely appriciate why Ruby programmers hold the language in such high regard.

22 Mar 2004 | Kent said...


The way you describe it, this is exactly the way I found out about Ruby.

We have been trying to choose between PHP and Ruby for a long time for our web development. And after I wrote a OR Mapper AND MVC layer in no more than tree days I've convinced everybody in my team that if you need a little of dynamic behavior for your website PHP is very useful, but if you need something more complex Ruby is the way to go.

BTW, this is very interesting presentation. What was the advantage of using ActiveRecord pattern over DomainModel+Mapper patterns?

22 Mar 2004 | Paul Hart said...

David, thanks for the link to the Ruby/Python comparison, very interesting.

22 Mar 2004 | Darrel said...

What is MVC? (...I'm a curious newbie programmer sitting on the sidelines listening intently to this conversation...)

22 Mar 2004 | Jameson said...


I was too! This helped make things a little clearer, although not much.

22 Mar 2004 | David Heinemeier Hansson said...

MVC is a way to separate the three basic concerns of an application into isolated tiers, which can be constructed, tweaked, and tested apart from the others. MVC is short for Model, View, Control.

The model is composed of business classes, such as Person, Project, Account. So the Project class has methods like has_milestones?, save, validate, and so on. This is the world of abstract ideas in a Plato-sense of ideals.

The view is the HTML templates that knows how to format and display the model objects, like "Title: <%= @post.title %>" (which shows the title of the post object). There's no computations and very little logic in the templates (or at least that's the way it should be).

The controller ties the view and model together by determining which models to give to which view and a given request.

This might appear as a somewhat elaborate scheme. And in a way, it is. You probably wouldn't structure your guest book application like this. Having it all mashed together is fine for that.

But as soon as your application grows to even a moderate level of complexity, there's an incredible benefit to be found in the MVC approach (or similar patterns for separating concerns). You decrease duplication, promote coherence and clarity, make it possible to test, and a world of other benefits.

Since all MVC-style applications relies on a large range of shared principles, it's possible to abstract and reuse these in what's called a framework. Rails is such a framework that tries to remove the complexity and drudgery of MVC, while still allowing you to realize all the benefits.

22 Mar 2004 | David Heinemeier Hansson said...

ActiveRecord is IMHO a much simpler solution than a complete data mapper. With the ActiveRecord it's possible to infer most of the wiring between class and table through reflection and qualified guesses. So you accept a little bit of restraint compared to a pure object model, but get a much faster development cycle. I found that trade-off to be well worth it for the kind of systems I've been developing (

22 Mar 2004 | Charbel said...

Did you ever consider using the jakarta Struts framework (java based)? It uses MVC architecture, and it allows for very easy maintenance and seperation of code, logic, and web design...

I'd be interested in Struts vs. Ruby comparison...

22 Mar 2004 | David Heinemeier Hansson said...

Rails is in many ways the antithesis of Struts. I've tried my hardest to avoid all the maintenance work that seems to go into a Struts application. There's so much work in keeping the mapping file in sync, creating an entire new class for a single command, and the use of ActionForms that duplicates the effort of the model. If you read the presentation, this is exactly what I mean by "Convention over configuration".

Mind you, I've only implemented a few sample applications in Struts (and read a lot about it, including the Husted book). It might not be as bad in real life usage, although it seems that the Tapestry and WebWork teams would argue that it is.

Also, Struts is of course based on Java, which is anything but your light-weight nimble (or IMHO even elegant) language. The verbosity is simply to much baggage for a small team like ours. It seems many Java developers concur, que Groovy, JRuby, Jython, and other attempts to leverage the Java platform without having to deal with Java itself.

23 Mar 2004 | Florian said...

Charbel, to ask for a ruby vs struts comparision is like asking for a mac os vs adobe photoshop comparision.

personally i simply dont understand what people find so great about struts. it has a lot of design flaws, just check the struts-user list, people are falling for the same things over and over again.

23 Mar 2004 | David Heinemeier Hansson said...

I think Charbel meant to write Struts vs Rails. And I didn't mean to bash Struts by saying Rails is the antithesis. (Well, okay, a little :))

Struts has done this amazing thing by bringing a standardized MVC framework to the masses. I'm sure there's a ton of projects that are much better off on Struts than without it. There's a million books on it. It's done very well for itself. Major kudos for that.

Also, it has established a benchmark against which frameworks can be judged and defined. That's a massive accomplishment. It enriches technical discussion with a baseline and a vocabulary. It also increases the awareness of the whole framework notion among the lesser technical. I hear recruiters are asking for "Struts" as a checkbox for Java resumes. That's kinda funny, but also kinda interesting.

So I'd rather praise Struts for its documentation, marketing, and reach than criticize it for its technical decisions.

Comments on this post are closed

Back to Top ^