Rails creator doubts Silverlight can win converts

In this interview, David Heinemeier Hansson also comments on open source, JavaFX, and differentiators in Ruby on Rails framework

David Heinemeier Hansson is the creator of one of the hottest technologies amongst software developers these days: the Ruby on Rails Web framework. Hailing from Denmark, Hansson is a partner at 37signals, a Chicago firm that develops tools for communications and collaboration. InfoWorld Editor at Large Paul Krill met with Hansson during the RailsConf 2007 event in Portland, Ore., last week, where Hansson expressed pride in how the community has latched onto Ruby on Rails. Development of Ruby on Rails 2.0, featuring REST (Representational State Transfer) is in progress. Hansson stressed Rails' emphasis on convention over configuration, suggested Microsoft is having battles internally regarding open source, and expressed doubts about whether Microsoft can win converts to its new Silverlight technology.

InfoWorld: When did you develop Ruby on Rails and why?

Hansson: I started developing Ruby on Rails actually as part of the first Ruby project I did, which was Basecamp. The summer of 2003 was when I originally got into Ruby, and I had been doing PHP and some Java for about four or five years ahead of that. But I was getting fed up and tired with those environments and wanted to give something new a chance, so I stumbled over Ruby and started playing around with it. And within about a week of playing around with it, I knew there was no way I could go back to either PHP or Java or anything else I'd been doing before.

InfoWorld: Why is that?

Hansson: Ruby just felt like such a great fit for my mind. So many things that I was frustrated about in previous environments I'd worked with just seemed to be solved incredibly beautifully in Ruby. And that was really one of the first things that I noticed that I intensely liked about Ruby, it was the aesthetics of the language. Ruby code is just inherently beautiful. Sure, you can write ugly code, but you can write incredibly beautiful code too.

InfoWorld: How did Rails come about?

Hansson: It started out not wanting to be Rails. It started out just me wanting to implement Basecamp, this Web application for 37signals. And I started working on that, and Ruby at that time had some Web frameworks, but [they] weren't necessarily what I directly liked. I came into Ruby with a lot of preconceptions of what Web applications should be like and how they should be developed from all the work I'd been doing in PHP and Java. And I wanted to bring some of those ideas in. So I started working on a little bit to talk to the database, a little bit to run some templating language to get something in HTML displayed. And all of those small pieces started just getting built up more and more. And a few months into it, I realized that I now had a fairly sizable chunk of tooling that I'd built just for myself just to implement Basecamp in Ruby. Maybe I could actually share that. So around December 2003, I kind of got into the mode that, hey, I want to release this. I want to wrap this stuff up, these tools I'm doing, put it into a box and let others enjoy themselves with it. Because I was thinking, Ruby is kind of a hidden gem right now. And it's really a shame. There are so many Web developments out right now that are, in my mind, stuck in PHP or Java, which is what I was thinking about at the time. And if I could have so much fun as I was having with Ruby right now, it'd be a travesty if I just kept all that to myself. So around December of 2003, I made the decision to really make a framework out of it, but it wasn't until six months later that Rails was actually released for the first time. We released it I think June 24 of 2004, the release of Rails 0.5. 

InfoWorld: This is another weekend Ruby Conference.  Why are developers so excited about Ruby and Ruby on Rails? You kind of elaborated on that a bit before.

Hansson: Sure. I think a lot of developers are excited about Ruby on Rails because it allows them to focus and think about something as simple as the joy of programming. That's not just a side effect of working on real enterprise production systems, it's at the forefront of development [of] Ruby on Rails.  We really want developers to be happy about the programs they're working on, the tools that they're working with, and the environment they're living in as programmers. And I think that [we are] explicitly choosing to make that the center of development of how we go about developing Rails, making sure that the aesthetics are just right. It's not the traditional computer science attributes we're trying to optimize for like memory usage or performance. We naturally care about those things because if it's not fast enough, it's not going to make us happy. But primarily, we care about getting beautiful code and getting a development environment where people are just happy about their work. And there are plenty of things in most traditional development environment that make people miserable. We tried to find those pain spots and remove them.

InfoWorld: Could you just name a couple of them?

Hansson: One of the things, for example, is how you configure your applications. A lot of environments, especially before Rails came around, had a notion that you basically started with a blank sheet of paper every single time. Everything had to be configured from scratch. How do I talk to the database? How do I map these fields between objects and records and rows and so on and so forth? You had to configure that explicitly every time, even though you might be doing the same thing over and over and over again. Like Groundhog Day, everything just started over and over and over again. So with Rails, we decided it's not going to be Groundhog Day. We're going to make some decisions and we're going to make them once. And once we've made those decisions, we're going to turn them into conventions, and we're going to teach you those conventions. And once you've learned them, it's done. Like we're no longer going to talk about what the primary key field in database tables are going to be called. They're going to be called ID, that's it. Now, [it's] done. Let's move on to the next decision. And like that we progressed through a ton of standard configuration points and literally removed them. We replaced them with conventions that said if you're just doing what most developers are doing the same [way] most of the time, you're going to get it for free. So they're going to be called ID. You don't care about that anyway. You shouldn't be caring about what the primary key fields are called, and if you can lift yourself above that and not care about it, you can get all this configuration stuff for free. So I think that's probably the biggest contribution we've made to thinking about frameworks. How can we get less configuration? How can we replace it with conventions instead?  And how can we get a lot of productivity out of that?

InfoWorld: How does Ruby on Rails compare to Java framework like Spring?

Hansson: I think one of the big differentiators is definitely that notion of convention over configuration. Java frameworks in particular have been peculiarly fond of XML for wiring pretty much everything together, and in some sense, it sounds great. You get ultimate flexibility, you get the opportunity to wire everything together exactly like you want it, but most people don't really care. That amount of flexibility is not worth the tradeoff.  And I think that's the fallacy of a lot of frameworks, especially in Java, they thought flexibility was free. Flexibility is not free. It's overrated. And if you trade that flexibility in for some constraints, you get a lot of complexity removed from the equation, you get a lot of productivity back from all the stuff you don't have to do. So that's one of the reasons that Rails is different from something like Spring or Struts and so on.  Another thing is just the aspects of something like Ruby. The Ruby programming language is just an amazing programming language to be able to work with, and we choose to employ it across the stack. So everything is written in Ruby. We write the views in Ruby, we write the models in Ruby, we write the controllers in Ruby. We try to keep everything as Ruby as we can instead of mixing something up with XML this or configuration files that.

InfoWorld: Could you name a couple of the major Web applications or Web sites that have been developed with Ruby on Rails?

Hansson: Sure. So my own company, 37signals, has been kind of the poster child for some time, it's the original, the first Rails applications. We have something called Basecamp, a project collaboration tool. We have something called Highrise, just managing context online. But there's a ton of other companies out there too. I especially like 43things.com, which is like a social networking site about the goals you want to achieve in life. There's shopify.com, which is a really cool e-commerce marketplace where you can create a beautiful-looking shop in very little effort at all and start selling merchandise for very little up-front cost. 

InfoWorld:  Are you following any of the Ruby and Ruby on Rails tools that are being released, such as Ruby In Steel from SapphireSteel, CodeGear's upcoming Ruby offering, and the FiveRuns's Management Suite for Rails?

Hansson: I am. And I'm very pleased to see all that work going on. One of the things that I've wanted from day one for Ruby on Rails was to create an economic ecosystem around it because I think that's one of the factors that make sure that something like a framework like Rails will stick around. When people start depending on this for their jobs, when people start depending on this for their paycheck, it'll ensure a long life for the framework. And that happened early on with consultants who shifted to making Ruby on Rails projects instead of whatever they were using before, and now it's happening in second tier. People were building up businesses around selling tools to Rails developers, and I think that's just -- it's such an important point in the evolution of the ecosystem and a great milestone for Ruby on Rails.

InfoWorld: What do you think of Sun Microsystems' recently announced JavaFX Script for content creation? Is the world ready for yet another scripting language?

Hansson: I think there's always room for new ideas, but I don't think that the whole fuss that's currently going on about RIA, rich Internet applications, is justified. I think we've been through this cycle so many times before that it in some ways amazes me how history seems to be ignored. We went through this with Java applets, they were going to rule the Web. Everything was going to be in a Java applet. HTML and CSS is history. And Flash came around, and Flash started focusing on applications. Now Flash is going to rule the Web and HTML and so on is yesterday. Now, Silverlight, Apollo, JavaFX, they're all bidding to take over the JavaScript, HTML and CSS [spaces], and I just don't buy it. I don't buy that developers by and large are going to jump into a proprietary technology and replace what HTML and CSS has given them.

InfoWorld: I think Sun is saying JavaFX is open source. I'm not sure if JavaFX Script is focused exclusively on Web development. I think it's just one function that can be done with it, and I'm not even sure if it does it that well at this point.

Hansson: That might be true, and I think that HTML and CSS [are] focused on Web development.  And I think that there are misconceptions going on from people who are pushing these alternative delivery platforms that somehow Web developers are hungry for richer and richer experiences, that they're really unhappy working with HTML and CSS.  And that's just not true. We're not clamoring to re-create the desktop on the Web.

InfoWorld: We don't need a new mousetrap?

Hansson: No, we don't. HTML and CSS is actually a wonderful development environment, and a good number of computer scientists or people who have been around for a long time might consider them hacks or dirty or whatever, but they work.

InfoWorld: But you do use those on Ruby on Rails?

Hansson: Totally. HTML, CSS, and JavaScript are the key components of how you get Rails applications to a user. And I don't see that changing.

InfoWorld: But not Ruby?

Hansson: Ruby generates those things, so HTML, CSS, and JavaScript are delivery mechanisms.

InfoWorld: Do you think Java is being displaced by scripting languages like Ruby or some of the others that are out there?

Hansson: I think Java and C# and other languages of that type [are] definitely being replaced by leaner and lighter approaches. I think Ruby and Python and SmallTalk and other languages in that sphere [are] gaining rapid ground just by people realizing that they would much rather have an enjoyable, productive environment [rather than] buy into these arguments for safety or bad things that will come down if you don't have types and so on and so forth. So I'm absolutely seeing the market share of these languages going down as more and more people just realize that they didn't die by using [the] scripting languages.

InfoWorld: What do you think of .Net and Windows development and Microsoft enabling its Common Language Runtime to run on the Macintosh platform?

1 2 Page 1
Page 1 of 2