Looking Backward: Ten Years on Rails

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

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.

Conclusion

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.