A New Sense of Purpose for Rails

I'm on the way back from this year's RailsConf, still digesting all of the talks I saw and conversations I had.

If I had one takeaway from this year, it's this: The way we develop web apps is changing. If Rails can embrace that, and make itself central to this shift, it can cement its relevance for another decade. I think Rails 5 can do that.

I worked at Apple from 2005 to 2011, first in the retail stores and then as an engineer on MobileMe and iCloud. I was very lucky to have been at Apple at that time, because I witnessed first-hand an underdog transform into a technology juggernaut.

The Mac was an amazingly innovative product, but Apple had let it stagnate. Towards the ends of the 90s, the tech press was pronouncing the end of the Mac. It was a time when portable electronics, like PDAs, digital cameras, digital camcorders, and more were becoming affordable, and Windows was ubiquitous. It was easy to imagine a world where Windows dominated business, and small, portable electronics dominated everywhere else.

Steve Jobs saw this coming, though, and the strategy Apple adopted cemented their place in the technology ecosystem for the next decade and beyond. They realized the Mac could be a digital hub: the central, easy-to-use experience that connected all of these amazing new devices.

I highly recommend this article by Pete Mortensen from 2010, posted on the eve of the iPad announcement, as a reminder of how rapidly Apple grew once it bet big on being the digital hub:

If you’ve never heard this term [digital hub] before, or its meaning has faded, take a look back at the video at the top of this piece. It’s the most important moment in the modern era of Apple. It’s not the day the iPod was announced, it’s not when the iPhone descended from the heavens … Instead, it’s the day that Steve Jobs defined what computing would mean in the next decade.

Up until this point, Steve’s focus had been on re-energizing the existing Apple fanbase with the iMac and other nicely designed products. But things didn’t take off until the company turned its gaze toward the ecosystem.

Today, Rails is a hugely, hugely popular framework. If it stays on its current course, it will remain popular for a very long time. It's obvious you can use it to build experiences that users love, with Basecamp as just one example.

That said, many developers, including Rails developers, are embracing a new way to build web applications. Most companies, even small ones, need to support mobile apps for iOS and Android. On the web, apps are increasingly powered by JavaScript, and our customers are getting accustomed to the speed and interactivity of client-side apps that talk to an API. Very soon, JavaScript apps are going to work offline as well as their native counterparts.

We can either resist this change, or we can make Rails the most productive way to build a backend service for these disparate client platforms. If we do this, I believe Rails can cement its popularity and relevance for another decade.

On the client, we have to choose the tools that deliver the best user experience. On iOS, that's using Objective-C or Swift with Cocoa. On Android, that's Java and the Android SDK. On the web, that's increasingly JavaScript and a framework like Ember.js.

On the server, however, we have total control of what tools we use. Indeed, this phenomenon is what allowed the web to win on the desktop despite the fact that browsers were so limited in their capabilities for so long.

I believe Rails remains the most productive way to build server-rendered web applications. The same things that make it great for rendering HTML, though, also make it great at delivering JSON. I believe Rails is by far the most productive way to build a backend for clients, whether native or JavaScript, to talk to.

That's why RailsConf 2015 was so exciting. The buzz among the community was about how to extend Rails to make all of this new stuff easy.

Most importantly, DHH's keynote announced two major new features for Rails 5: it will include built-in support for JSON APIs, via rails new --api, and Action Cable, which makes real-time streaming to the browser as easy as the request-response programming model.

Projects like Turbolinks are a superb way to get more performance out of server-rendered web applications. I definitely don't think anyone who has made a significant investment in server-rendered web applications needs to tear everything down and rewrite.

But if you're a "prepper" (to borrow a term from DHH's
keynote, a team of one or two people building a product that competes with much larger teams), I think you'd be wise to bet on an architecture that allows for offline support, fast client-side routing, and user interaction on par with native apps. Anecdotally, all the preppers I know are betting on a backend built with either Rails or Node.js, paired with a JavaScript frontend.

That's why I'm very happy to see Rails 5 embracing rather than fighting this shift. I love Rails, so much so that we bet our company on it by building Skylight. And I'm happy to see Rails continue to be a great framework for apps like Basecamp, GitHub, and Shopify that render their HTML on the server.

But, as DHH says, Rails is a big tent. A large number of products are built with Rails on the backend and Ember on the frontend, including Skylight, Discourse, Square, Heroku, Travis, Zendesk, Intercom, Twitch, HuBoard, Acorns, Ride and many more.

We've tried to bring the best lessons from Rails to Ember, particularly around convention over configuration, and Rails 5 is a perfect opportunity to make using these two tools together a first-class experience.

After this RailsConf, we're more confident than ever in our big bet on Rails. Here's to another decade of a vibrant community, and for building a big tent that houses every web developer, however they prefer to build their apps.