RIA News Desk

Subscribe to RIA News Desk: eMailAlertsEmail Alerts
Get RIA News Desk via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: RIA Developer's Journal, AJAX World RIA Conference

RIA & Ajax: Article

AJAX on Rails: An AJAXWorld Interview

Full Transcript of Dion Hinchcliffe's SYS-CON.TV Interview with David Heinemeier Hansson

View David's AJAXWorld Presentation: AJAX 0n Rails

Dion Hinchcliffe:
Welcome to SYS-CON TV. My name is Dion Hinchcliffe, I'm CTO with Sphere of Influence and editor-in-chief of the Web 2.0 Journal. I have with me today David Heinemeier Hansson of 37signals and creator of Ruby on Rails. David, welcome and let me ask you, Ruby on Rails is one of the most exciting stories in the application AJAX server stack space. Could you tell us a little bit about what it is, why you created it, and what are its advantages?

David Heinemeier Hansson: Ruby on Rails is what we call a full stack. A full stack meaning that it has all the components built in for doing most Web applications. Unlike a lot of other open source software, you don't have to cherry pick a lot of different packages. We try to deliver one solution in the sense of Apple delivering one solution that spans across multiple layers. We like to think of ourselves as the Apple of open source Web application development, in the sense of dealing with the database, wrapping data objects, dealing with the controller and the control flow, and getting requests coming in and dealing with template languages, and of late also dealing with AJAX on the client side, and tying all of these things together seamlessly with knowledge of each other.

I started building this about two-and-a-half years ago. I had been doing PHP and Java for about five years and, frankly, I wasn't really enjoying the role of programmer. I wasn't really enjoying the actual programming work.

Hinchcliffe: Why, because you were mired in complexity or -

Hansson: I was mired in complexity, I was mired in stuff that couldn't be maintained, the hassles of ups and downs. Either you went with PHP, which I liked for its immediacy; you could get something done really quickly, but as soon as you tried extracting these things, making a framework, building on top of it, reusing and going back and changing things, this is not the most welcoming language for that. You could certainly do it, and I did it for a good number of years, but it just took more effort than it should. On the other hand, you have something like Java where it's actually possible to create something nice and maintainable if you have a thousand years to do it. I felt that there must be some split between these two things, where you can get something that's neither quick and dirty or slow and clean but perhaps quick and clean. And that's kind of the sweet spot I tried to approach with Ruby on Rails.

    I needed it for my own stuff. I work at a company called 37signals, and about two and a half years ago we were contemplating getting out of the consultancy business and getting into products. So we created our first application, Basecamp, on top of Ruby. At that time Ruby did have some things to do or some libraries and primers that dealt with the Web, but not any that appealed to my aesthetics.

Hinchcliffe:That was kind of my question: you have AJAX and you have application developers who know Perl or PHP or Java, and they have to learn a new application stack, they have to learn a new language, and AJAX on top of it. That's a lot.

Hansson: Right. One of the things we are trying to do with Ruby on Rails is actually make it extremely conventional. Most of the ideas in Ruby on Rails are the same ideas that people have been building Web applications on for the past 10 years; they just hurt a lot less. The actual practice of implementing these patterns that the industry has spent 10 years perfecting, is just a lot less painful in a language like Ruby than it is in a language like PHP or Java simply because Ruby is a better programming language. At the core of that, the core elements of the language just lend themselves better to building the kinds of frameworks that deliver that programmer happiness we are trying to chase with Ruby on Rails.

Hinchcliffe: Doesn't Ruby on Rails make the common task easier and put the complexity out into the edge cases. Isn't that part of it?

Hansson:  A lot of it is definitely making what most people do most of the time extremely easy, but still allowing for the fact that not everybody is doing what everybody else is doing most of the time; you need to jump off track sometimes and just get out of the way when that happens. But 80% of your application is just like 80% of somebody else's application, so that's stuff you can extract. Once you've extracted it, you can make it a lot nicer to deal with; you just don't have to repeat the same mundane details over and over again. That's what we're calling conventional configuration. We have a set of conventions in Rails that if you follow those, you learn the convention once and you never have to configure that again. That really racks up pretty quickly. A lot of these standard things and Web applications are stuff you need to configure over and over again. How does this object layer relate to the database? How do the URLs relate to the controller that's matching it?

Hinchcliffe: Same thing you always go through whenever you develop an application.

Hansson: That's the stuff that in Java we call XML sit-ups, the fact that you usually can produce just as much XML configuration as application code and that's just insane in online. Instead, get rid of that configuration, replace it mostly with conventions where you can learn the conventions once, reap the benefits over and over again, and then allow configuration for the edge cases.

Hinchcliffe:  Interesting. Some people who were used to traditional application development, they may even have heard Don Box say, "I wish .NET had a Ruby implementation," so they might start taking that seriously, but does it really scale? What is your experience with Ruby on Rails and Ruby in particular?

Hansson: "Does it scale?" is an interesting question, because just put like that with no metrics and specificity it doesn't really mean anything. But let's take the public perception of scaling, meaning you can add more hardware and then you can handle more clients. Is Ruby capable of doing that? The answer is unquestionably yes, simply because Ruby doesn't invent a new architecture. We use exactly the same architecture as people who have been building the biggest sites the Internet has used for the last decade, which is something called shared nothing, where you don't have state in the application or in the Web layer. You have pushed all the state out to the database, and if there's anybody who spent time figuring out how to scale, it's the database guys. Basically we're saying it's not our problem; it's the problem of the database guys, or NFS file stores or mem cache or any of these other technologies for managing large amounts of data fast. Once you have a Web layer and an application layer that doesn't contain state, you can add an unlimited number of application servers with no effort at all except a low balancer.

Hinchcliffe: Has it been your experience at 37signals? You guys actually host very large-scale applications using exactly this, right?

Hansson:  We started out building Basecamp, our first application, on a single server. We had a database, Web server, application server, all in one box. Today I think we have 13 boxes in our cluster that handle five applications and more than 400,000 people using our application in one form or another.

More Stories By RIA News Desk

Ever since Google popularized a smarter, more responsive and interactive Web experience by using AJAX (Asynchronous JavaScript + XML) for its Google Maps & Gmail applications, SYS-CON's RIA News Desk has been covering every aspect of Rich Internet Applications and those creating and deploying them. If you have breaking RIA news, please send it to RIA@sys-con.com to share your product and company news coverage with AJAXWorld readers.

Comments (14)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.