Introducing RealWorld 🙌

A Collection & Specification for Exemplary Frontend and Backend Codebases 🏅

TL;DR — RealWorld shows you how the exact same real world blogging platform is built using React/Angular/& more on top of Node/Django/& more. Yes, you can mix and match them, because they all adhere to the same API spec 😮😎

So about a year ago, I had this realization about a problem I had:

Mastering the core concepts & ideology of a new framework is unnecessarily frustrating.

You read the docs, run a contrived example in a codepen, rip apart the “todo” example app & put it back together again, get their CLI installed locally… and then you’re off to the races!

Except you’re not. Not even close. Because when you start actually trying to build out your 0wn app, that’s when Murphy’s law hits you.

“How do I preload data before navigating to a certain route?”, you wonder. “That definitely wasn’t in any of the docs or examples. And why is this CLI telling me that left-pad can’t be resolved? I can’t even get a Hello World app running right now. This is infuriating”, you conclude.

It will take weeks or even months of this mental anguish to attain ample understanding and mastery of this new framework. Worse yet, the Javascript ecosystem ain’t slowin’ down. So once you’re done mastering this one, there’s gonna be more out there that you gotta master—and you’ll never have enough time for them all.

If you step back, this is a rare problem in the history of software engineering that we’re experiencing. Most of the improvements in software’s history have been guided by centralized top-to-bottom efforts from governments, corporations, and the like. That is, until the web came around. The key difference with the web is that its upgrade model follows a more decentralized & democratic solution, and thus the direction of innovation flows opposite: bottom-to-up.

So whenever you see a new library or framework released, what’s really going on is just the Javascript ecosystem doing what it was designed to do: enable anyone to make improvements on top of the web’s runtime—some of which even make it back into the core runtime itself.

This is a good thing.

However, it’s a widely discussed problem that what’s going on is fatiguing—not because the rate of innovation itself is fatiguing, but because our traditional human learning methods aren’t scaling well enough to match it.

In other words, we can’t change the pace of innovation on the web. But we can change how fast we are able to communicate those changes to each other.

I’ve always loved how TodoMVC did this. By creating the same application (whose intended functionality needed no explaining) in every framework, they created the Rosetta Stone for Javascript UI libraries and frameworks.

However, despite the fact that most todo apps/tutorials provide an excellent cursory glance at a framework’s capabilities, they typically don’t convey the knowledge & perspective required to actually build “real” web applications with it.

Why? It’s because of the origins of todo applications themselves.

Todo apps are not good examples when you’re comparing “realistic” web applications because todo apps existed long before the web did. Phrased differently, todo apps have not been one of the breakthrough applications whose mere existence required the web itself. So naturally, one’s first idea when imagining the simplest possible todo app probably doesn’t have a hard requirement for being perma-connected to the web.

But another great model of this that I’ve always loved was the “create a blog” tutorial in the Rails docs. Spoilers: they have you make a blog.

A blog. One of the most simple inventions that never would have existed without the web itself. And it takes full advantage of the web too: querying & persisting data to a database, an authentication system, session management, full CRUD for resources—and now these days social blogging platforms (like the site you’re reading this on) have also perfected relational features like following, liking, and commenting. A blogging site is the perfect example of a simple yet robust web application.

Reusing the best ideas from TodoMVC and the Rails blog tutorial, we took a stab at solving this problem by creating the design & API spec for a real world social blogging site similar to We named it Conduit. And then we started writing the first six framework implementations that it could be powered by: Angular 1.x, Angular 2+, or React&Redux on top of Node, Django, or Rails.

As of today, we’re excited to announce that all six stacks have been completed and you can check them out on the RealWorld github repo! (Be sure to star/fork too :) You can check out a live demo of Conduit that’s powered by React&Redux on top a Node backend 😮

Now that we’ve proven that Conduit can work across multiple frameworks, we’re inviting you to share your mastery & add support for the other frameworks out there (Vue, Polymer, Elm, Go, Erlang, …) by implementing Conduit in a new framework!

PS — We’d love to hear any ideas/feedback you have in the comments (or on Twitter @ericsimons40)! 🍻