Looking Backward: Ten Years on Rails

By Luke Francl (look@recursion.org), as prepared for presentation at RailsConf 2014

Ruby on Rails timeline, 1972–2014

Including influences on Rails and associated developments. Corrections and additions welcome.

circa January

Smalltalk-72, the first version used in research, is released.

circa January

MVC pattern first created by Trygve Reenskaug at Xerox Parc.

December 21

Ruby 0.95 is released. (First public release)

circa January

XML-RPC is released, based on a draft of the SOAP protocol specification.

circa January

SOAP (“Simple Object Access Protocol”) 1.1 is released. It becomes a standard way to do web service calls in Java and .NET.

October 30

The Pragmatic Programmer: From Journeyman to Master by Dave Thomas and Andy Hunt is published. It recommends programmers learn a scripting language.

circa November

SourceForge launches, providing free CVS hosting for open source projects.

circa January

Roy Fielding defines “REST” in his Ph.D. dissertation.

March 10

The dot-com bubble collapses.

circa January

Microsoft releases Outlook Web Access, the first large application to make use of Internet Explorer’s built-in XMLHTTP library.

circa January

Programming Ruby (first edition) by Dave Thomas and Andrew Hunt published.

circa February

Agile software manifesto created.

circa April

State Software (Douglas Crockford’s company) begins working on “JavaScript Message Language” for data interchange. It is quickly renamed JSON.

circa January

JSON.org website launched

February 11

Struts 1.0.2 released

circa January

Patterns of Enterprise Application Architecture by Martin Fowler published; includes description of the Active Record pattern.

circa January

RubyForge launches to provide project hosting for the Ruby community; it is based on a fork of the SourceForge platform.

December 7

PEP 333 defining the Web Server Gateway Interface is published; it provides a common HTTP interface for Python web frameworks.

February 5

Basecamp launches.

February 10

Flickr launches; its "yellow fade" edit animation is widely copied.

circa March

Java Server Faces 1.0 released; it is "the way forward" for Java web application development.

April 1

Google launches GMail, showcasing live reloading of a web application.

March 14

Initial public release of Rubygems.

July 24

First release of Ruby on Rails (0.5)

I’ve been talking (and hyping) Rails for so long that it’s all wierd to finally have it out in the open. Mind you, we’re still not talking about a 1.0 release, but the package currently on offer is still something I’m very comfortable to share with the world. Undoubtedly, there could be more documentation and more examples, but Real Artists Ship and this piece will grow in public. Enjoy Rails!

October 2

DHH presents Rails at RubyConf 2004. Francis Hwang estimates 60 people are in attendance.

October 5

O'Reilly’s invitation-only Web 2.0 conference popularizes the term.

October 25

First RubyGem release of Ruby on Rails (0.8)

December 10

Google launches Google Suggest, which uses XMLHTTP to asynchronously update search suggestions as you type. Developers quickly reverse engineer the technique.

January 1

The Robot Co-op launches 43 Things; the site is an early adopter of Ruby on Rails.

January 20

Rolling with Ruby on Rails published.

January 27

Carlos Riberio discusses the problem of Python web frameworks.

In Python land, there are several competing Web frameworks. It’s interesting to see how many of them are badly documented, or not documented at all. But even projects that have a good volume of documentation still fail to address the mental model problem. A manual that touches only on practical issues -- mainly, API specs -- is close to useless in this regard.

I would like to see more effort spent on documenting the architectural issues of a framework. Not only 'how do I call this method', but 'how do I structure my app'. That’s the really difficult question, and the lack of a satisfactory answer to it is often a good reason to write yet another framework.

February 2

First mention of Ruby on Rails on my blog

The Java community has been buzzing about Ruby on Rails for a few months now.

Today, I finally took a look at it.

It seems cool. A REST-ful framework for creating dynamic web applications with minimal amounts of coding. Writing REST-ful applications with clean URLs in other frameworks can be a big, big pain (just try doing this with plain vanilla servlets -- you will be begging for mercy).

Beyond that, what I like about it is that it is an entire stack, integrated together very nicely. This is something I’ve really found lacking with Python. Python has a million web frameworks, but none of them have the whole package like Rails does.

I’ve considered using Python for some side projects, and I still haven’t found "the one" Python web framework. Do I use mod_python or FastCGI? Which Object-Relational mapper is the best? What templating language should I use? Which view framework will give me beautiful, search engine friendly, professional-looking URLs? Finally, of these miriad frameworks, which of them can I count on an active and outward-facing developer community for good documentation and support?

It’s a friggin’ hassle.

The same problem applies in the Java world, but there you can always muddle through with the standard Servlet/JSP package, which has institutional support from Sun, or go for one of the frameworks like Struts, Spring, and Hibernate that have thousands of developers, good docs, books published, etc.

But in the end...is Rails worth learning Ruby over? Hmmm...

February 5

Sam Stephenson releases Prototype.js

February 8

Google Maps launches for Internet Explorer and Firefox, redefining the level of interaction possible in a web browser.

February 15

Jesse James Garrett coins the term Ajax to describe the rich new web applications like Flickr, Google Suggest, and Google Maps.

April 7

Initial release of git distributed version control system.

June 2

David Heinemeier Hansson records 15 minute blog demo, showcasing Rails’ rapid development speed.

circa July

Initial release of Groovy on Grails, a Rails-inspired framework for the JVM language Groovy.

July 7

script.aculo.us 1.0.0 is released, making it easy to add Web 2.0-style effects to your application.

July 21

Django released after being developed for over two years

circa August

Locomotive released; makes setting up a Rails development environment on a Mac easy.

August 4

Agile Web Development with Rails, first edition published.

August 20

Foundations of Ajax published; an entire book about how to use Ajax.

October 26

First meeting of Ruby Users of Minnesota.

December 3

Snakes and Rubies conference brings together creators of Django and Rails (video).

December 13

Rails 1.0 released.

March 21

Jack Dorsey posts first tweet: “just setting up my twttr

June 22

The first RailsConf is held in Chicago.

July 5

JRuby 0.9 can run Rails.

July 29

Django 0.95 released, including "magic-removal" changes.

August 26

John Resig releases jQuery

circa October

Merb 0.03 released ("Mongrel+Erb")

December 11

I start new job as a Rails developer.

January 18

Rails 1.2 released with RESTful resources.

February 20

Christian Neukirchen defines the Rack interface, inspired by WSGI.

circa May

Play Framework for Java released

October 4

Initial release of Sinatra microframework; it is widely copied in other languages.

October 19

Chris Wainstraith and Tom Preston-Werner begin working on GitHub.

circa December

Rails 2.0 released.

April 2

Rails development moves to GitHub.

April 10

GitHub launches out of beta.

December 23

Rails/Merb merger announced; Merb team joins Rails core team.

March 16

Rails 2.3 released; Rails is now a Rack application.

May 27

Initial release of Node.js, a web programming environment for the V8 virtual machine. It allows programmers to write JavaScript client side and server side.

August 1

Rails 3.0 released with contributions from Merb core team; it has been over a year since Rails 2.3 was released.

August 31

Rails 3.1 released; jQuery is now the default JavaScript library.

circa June

Rails 4.0 released with features like Turbolinks and caching to try to make "classic" web based apps as fast as front-end JavaScript-based apps.

This year, Ruby on Rails turns ten years old[1]. It’s an appropriate time to look back at the origins of Rails and think about where it might be going in the future.

I’ve been thinking about the early days of Rails because the company I work for makes site search software, and I use my own site for testing. Searching for “rails”, I ended up re-reading some of the blog posts I wrote when I first discovered Ruby on Rails in early 2005. I was impressed with Rails, but I was initially skeptical — I was working as a Java developer, and I was interested in Python, and I wasn’t sure if Rails was worth learning Ruby over. I thought Rails was impressive, but I was sure that Python would quickly catch up.

Months passed, and I grew tired of waiting for Python to catch up to Rails, so I finally decided to take the plunge and learn Ruby and Rails in the summer of 2005. That fall, I caught wind of a new group forming: the Ruby Users of Minnesota. I attended the first meeting of about a dozen others interested in Ruby and excited about Rails, and thereby joined the Ruby community. A year later, I was working full-time as a Rails developer, and I haven’t looked back since.

Thinking back on those days reminded me of the late 19th century novel Looking Backward by Edward Bellamy. In the novel, an upper class man is hypnotized and sleeps for over one hundred years. He awakens in the 21st century to find the world has completely changed — it’s now a socialist utopia. Since he was upper class back in the late 1800s, he had it pretty good and is initially skeptical of the new order. But as he’s shown the wonders of the new age, he comes to believe that it is a better way to organize society.

This got me wondering: what would a programmer from 2004 think about our web development utopia of 2014?

Web development in 2004

Let’s set the stage: what was web development like in 2004?

Back in 2004, the most common web browser was Internet Explorer (IE 6 had been released 3 years prior) with 92% market share. The hottest phone was the Motorola Razr. It could display web pages — sort of. The Mac had not yet taken over as the most fashionable development machine. MacBooks did not exist; the top-of-the-line Mac laptop was the PowerBook G4. I used Linux at work with a 17 inch monitor.

I can’t claim a general experience of what every web developer’s work was like, but I can talk about what it was like for me. In 2004, I was working as a Java developer at a small software company. I’d graduated in 2001 right after the dot-com bust, so it took me a long time to find a job. I felt really fortunate to be programming in Java — the hot language of the time — at a real software company, instead of the IT department of some big company.

If you’ve ever done any Java web development, you know it can be pretty painful. The big reason for this is the long Edit-Compile-Debug cycle. Or, in the case of Java web development, the Edit-Compile-Deploy-Debug cycle.

My company didn’t use the hot Java web development technologies of the time: Struts and Hibernate. We used Servlets, Java Server Pages (JSPs), and hand-written SQL[2]. Writing a web app this way was complicated. The Java Servlet API isn’t much of a step above using raw CGI, and since Java is so verbose, it took a lot of code to get anything done. JSP is just like ERb, except you use Java instead of Ruby inside your HTML code. Java circa 2004 lacked convenient looping and mapping constructs, and everything needed to be typed, so writing code in JSPs was complicated and error prone.

Once I’d got my code compiling, I’d have to deploy it to my local app server to test it out. We used WebSphere, and packaging up the web application and restarting the app server to load the new code took a while.

Debugging was also complicated. Since JSPs work by generating a Java class that outputs the HTML, if I had an error in my JSP, I would get a stack trace saying something like “NullPointerException on line 20075 of 28032”. The line numbers were totally uncorrelated with the code I wrote and so I’d wrack my brain trying to map that error to the code in the JSP. Eventually, I found the setting that let me keep around the generated Java source code, and so I could open that up and look at line 20,075 to see what was actually happening.

However, there was also a sense in 2004 that something better was on the way. People were getting excited by new possibilities for the web as a platform. This started with Microsoft’s development of Outlook Web Access in 2001. This was the first app to use what we now call Ajax without requiring a browser plugin. In 2002, Google released GMail [sic – GMail began development circa 2002, but was released in April 2004], which opened people’s eyes to how dynamic a browser-based application could be. And in 2004, Google launched Google Suggest. People quickly pulled apart the code to figure out how it worked.

I was also looking for something better. I attribute that to reading The Pragmatic Programmer by Dave Thomas and Andy Hunt early in my career. It’s a terrific book about becoming a better programmer, and one of their recommendations is to learn a scripting language, because you can use that for tasks that would take too long to write in a heavy-weight language like Java.

So, after reading that book, I headed to the bookstore and grabbed all the books about scripting languages I could find. There were a lot of books about Perl, and a lot about Python, and one book about Ruby (by the same authors, Dave Thomas and Andy Hunt). I immediately discarded the books about Perl, because I’d worked with it before and didn’t like it. Python looked pretty good. I looked at the Ruby book, and I saw all the $?, $!, @, and @@ symbols and I thought, “This looks just like Perl! I don’t want anything to do with this!” And so I decided to learn Python.

I was able to use Python for some things at my job. I wrote a script that migrated our bug tracker database, and I wrote a build system, and I wrote a few personal scripts. But what I really wanted to do was write web apps, because that’s always what I have been most interested in. However, every time I would get an idea for a web app, I’d sketch out some details about how it should work, and then I’d start researching how to build it. And this is where I would get frustrated, because I then would start reading about how to build web apps in Python. And there was no clear answer. The standard library included CGI functionality, but who wants to use that? Then there would be any number of templating systems, object-relational mappers, database drivers, and object publishing systems. I would get discouraged and give up.

I didn’t know it at the time, but there was something better on the way.

Our modern web development utopia

Let’s jump forward now to 2014. What would a programmer from 2004 think about how we work now?

I think they would be amazed. It is truly a great time to be a programmer.

In 2004, Ajax was in its infancy. The term had not even been coined yet. Today, all web frameworks come with powerful Ajax libraries built in. And if you want, you can write your entire application in front-end JavaScript. Browsers are immeasurably more powerful than they were in 2004.

In 2004, deploying your web app was difficult. Now, you can spin up a server with a click of a button. You can host everything on EC2 if you want to do it yourself, or you can use a platform-as-a-service like Google App Engine or Heroku if you'd like to have someone else manage your servers for you. This dramatically reduces the requirements for deploying a web application, because you no longer need to be a skilled sysadmin and a programmer.

And today, you can extend your app with powerful APIs with a simple HTTP request. There are APIs for everything from search like Swiftype provides, to payments from Stripe, and even telephony from Twilio. Best of all, these APIs use JSON and REST for data exchange, so there’s no XML situps or complicated libraries needed to integrate them.

But what would a programmer from 2004 think of Rails? As I think back to my initial reactions to it, a few features stand out.

First, live reloading. In Rails, you could edit any file in your app — model, view, even the database schema — and your changes would be immediately reflected. Coming from the Java world, this was a revelation. Best of all, when you made an error, you'd get a stack trace pinpointing the exact line where the problem occurred, even in the view.

Second, the development console was a huge boost to developer productivity. With a single command you could get programmatic access to your app. I keep a console open constantly to try out new things and confirm how code works. I’d hacked up a development console with a Java tool called BeanShell, but it was difficult and didn’t work nearly as well as the Rails built-in console.

Third, the concept of multiple environments. Having separate testing, development and production environments made it easy to keep these concerns separate. Again, this is something it was possible to set up elsewhere, but in Rails it came for free.

Finally, for someone writing SQL with JDBC, ActiveRecord was amazing. It could dynamically build a model based on the structure of the database! Database migrations were also amazing. This is another thing I'd worked on building for my job, but it wasn’t nearly as nice as Rails — you had to use SQL, it tied the version of the database to the version of the app, and there was no way to migrate down.

All of these features existed elsewhere. So why Rails? What made people excited about Rails — so excited they were willing to switch to a little-known programming language and a web framework with no clear deployment strategy?

I believe there were three reasons.

First, Rails was the whole package. In a essence, Rails was the first “full stack” web framework. All of these features were possible in various other systems, but with Rails, they were built-in. Rails took a bunch of best practices for how to build web applications, and made them the default. It took things that were possible and made them easy.

Second, the triumph of hype. When Rails came out, it caused quite a stir, especially in the Java and Python communities. And if you read those early blog posts, DHH was right there, engaged in discussion, responding on his own blog, promoting Rails everywhere. And that was important, because it’s not enough to write great code and put it up on the internet. You have to tell people about it. David and the early Rails community were passionate about Rails, and they did a great job sharing that enthusiasm.

Third, the triumph of community. From early days, you could extend Rails with plugins. This made it possible for you to add important functionality like login or file upload so you could focus on the core features of your application. And today, there are thousands of Ruby gems for just about any functionality you could imagine.

A look to the future

Let’s turn now to the future. What does the future have in store for Rails, and what might it’s legacy be?

Rails is now a mature, accepted way to make powerful web applications. But I believe Rails will face challenges in the future. David has said that Rails is for building apps like Basecamp: database-backed apps that are generating HTML on the server to build the view. I’ll call those “classic” web-based applications.

Today, that model is being challenged from two directions.

First, now that browsers are more powerful, there’s a great deal of interest in building client-side applications in JavaScript. Client-side apps can be faster and deliver a more interactive user experience. Since the view logic is happening on the client, the server is primarily responsible for delivering an API. Rails can do this, of course, but since the role for the server is much reduced, some people feel like they don’t need Rails any more. And there’s a lot of interest in platforms like Node.JS, because you can use JavaScript on both the client and the server.

The second reason is similar but more wide reaching, and that is that the web as a platform is under threat from mobile apps. Again, you can get a much richer experience with a native UI, and the backend server is relegated to delivering an API.

While Rails and the web faces challenges, Rails adapts to how developers want to use it. For example, think of Rails 1.2 and the adoption of REST. If more and more, we need Rails to be a terrific platform for building APIs, it will move more in that direction. And Rails already is a great platform for APIs — my company uses stripped down Rails Metal for to serve hundreds of millions of requests a month. But Rails also helps you with all the other stuff you need to support your API, like building your admin management console. No one is going to build an iPad app to manage their backend — it’s too expensive and slow. Rails is the best way to build a classic web application, and there are still many, many areas where that is exactly what you need because the web is the cheapest and easiest way of delivering softare yet created.

But even if Rails does ultimately fall by the wayside, its legacy will live on. The Rails philosophy of taking things that were possible and making them easy has been inspirational for programmers across many different languages. There are Rails-inspired frameworks in Java, Groovy, PHP and others.

Rails also has a legacy in the reaction against it. There’s two examples I’d like to look at.

First, Django. Django can’t be said to be inspired by Rails because they were under development at the same time. However, one of the major releases of Django was the “magic removal” release. In this release, the Django developers removed a number of conventions that had developed along with Django. Django follows the Python philosophy that explicit is better that implicit. In Django, you have to think about every URL you want to create, and your database models tell the database what its fields are, instead of the other way around. Rails believes convention is better than configuration. However, if you’ve ever tried to teach someone Rails, you know that convention can be a double-edged sword. It can be really confusing that you define a URL over in your routes.rb file and therefore this file over here needs to be named X and will only respond to methods A, B, and C.

Second, micro-frameworks, primarily inspired by Sinatra. When you’re building a small or API-driven app, a microframework makes sense, and I love working with Sinatra. It is truly a thing of beauty to have your full app in a single file, and the URLs are tightly bound to the code that executes when you hit them. It’s wonderful. Sinatra has been widely influential. There are Sinatra-inspired web frameworks in just about every programming language you can think of: PHP, JavaScript, Python, Go, Clojure, even Haskell. In some languages, it’s more-or-less the standard way to make web apps. However, when I use Sinatra, as the app gets bigger I find myself pulling in more and more of Rails, and at a certain point, I feel better off just using Rails.

So, Rails does face challenges, and so does the web. But its legacy is wide-spread, and whatever the next platform is, I think people will reach for the ideas pioneered by Rails.


Ten years. Wow. What a decade it has been. I wasn’t there at the beginning, but embracing Rails changed the course of my career.

Over a hundred years ago, Edward Bellamy was frustrated with society. It was the first Gilded Age, the time of monopolies and railroad barrons. Income inequality was massive and the plight of workers was dismal. With his book Looking Backward, he was able to use his imagination to create a new world, as he thought it ought to work.

Obviously, it is the 21st century now, and America is not a socialist utopia. However, Bellamy’s book was incredibly influential. Within a few years of its publication, hundreds of Bellamy Clubs had been started across America for people to meet and discuss the ideas in the book. These clubs formed the nucleolus of the early twentieth century Progressive movement, which ultimately paved the way for the creation of Social Security and the American welfare state.

Programming is more concrete, so when David Heinemeier Hansson was frustrated with the state of web development, he was able to create the world he wanted to live in by writing Rails.

And like Bellamy, people were excited by this vision and joined the Ruby and Rails community to lay the groundwork for this new way of working. Ten years on, the dynamic Rails community is a testament to that vision. I find this incredibly inspiring, and I am proud to be a part of it.

[1] The first public release of Rails was in July 2004. However, Basecamp was released in February of that year, so Rails was in development for some time before the public release. For the purposes of this talk, I’m using the public release date.

[2] We also used a non-relational data store called IBM Content Manager, so I guess you could say we were NoSQL before NoSQL was cool.