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? 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.”
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.
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.
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 Medium.com. 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)! 🍻