Facebook just taught us all how to build websites
Sometimes in software development, we take giant leaps.
In 2003, Brad Fitzpatrick released Memcached, and began talking about LiveJournal’s architecture (here’s a presentation from a few years later.) This became the prototype for the next generation of sites and apps, and is still largely the same way web apps are built today.
In 2004, Google published a paper describing MapReduce. With Google’s public success with this programming model, and inspired by their paper, Hadoop was born. While Hadoop has evolved considerably, it’s now a staple of how large sites and apps process their data.
In 2007, Amazon published the Dynamo paper which showed, in an understandable way, how databases and applications could be written to work together and scale linearly as new nodes are added to a cluster. From this concept, a bevy of databases like Cassandra and Riak were born, and are used by many of the largest apps in the world.
In 2010, Twitter publicly switched to client-side templating, turning the server into something more like a simple API. Around the same time, DocumentCloud released Backbone.js, which packaged this concept up with a neat API, a crisp implementation, and clear documentation. While Twitter may have had a few hiccups five years ago, in practice this set off the next big transition, where today many apps are written to render on the client, and more are being converted to that style every day.
In 2012, Google released version 1.0 of Angular.js. It provided a lot more structure than Backbone.js, and heavily emphasized testing and good development practices, while taking care of some of the boring parts of binding data and rendering content. Today, try looking for any web development job position, they all list Angular.js as the framework to know—its rise in popularity has been meteoric.
What do all these have in common? Companies or startups, having learned hard lessons in production, found a way forward, and have shared their breakthroughs with the world.
I believe this has happened again in 2015, this time with Facebook’s trio of React.js, Relay, and GraphQL.
Here’s my outsider’s interpretation of what has been presented this week (and over the past year or two) from Facebook, as their technique for developing apps and sites:
First, decompose your app concept into individual components. Some will be reused in many parts of the app, others will be used only once, but these components nest together to create your application.
Second, each component should hold a bag of data (called state) that contains everything the component needs to render itself. Whenever practical, use immutable data structures for your state variables.
Third, declare and explicitly reason about how that component should react to changes in state, triggered by either the user’s action or another component.
Fourth, have each individual component declare, exactly and explicitly, the data that it needs to have in order to render itself.
Fifth, colocate the style, markup, validation, and data requirements all inside of or near where each component is defined.
Sixth, if you can learn to write different markup, you can use these same exact techniques, language, framework, and libraries to build native apps. Maybe if you’re lucky you can even share some common code across them.
Everything else should be handled by the framework, compiler, or tools. For example:
- When a component’s state changes, the framework should know how to mutate the DOM (or iOS/Android view hierarchy) to match what the component says it should now look like.
- Given a tree of components, each requesting data, the framework should know how to compile the most efficient query or set of queries to send to the server to get the data it needs.
- Changes in state should be optimistically applied to your app’s UI, but verified with the server.
- When the page loads, it should render in HTML, but it should boot up and become interactive when loaded by the browser.
Why is this such a good way of reasoning about app/web development? We always talk about scalability, whether it be on the server or in the browser. We talk a lot less about scaling teams of developers. Probably because it’s a Hard Problem. But that’s where we can learn most from Facebook!
Components written using these techniques can encapsulate their logic, so they don’t have to worry about breaking or knowing about other parts of the app. They can be standardized and reused, so that you don’t reimplement that same button ten slightly different ways. Onboarding new developers is easy, since the set of primitives needed to build components is small and doesn’t hide deep underlying complexity. It just turns out to be elegant architecture.
This technique also forces us to think about our UI’s state and its state transitions, which is a more deliberate way of reasoning about presentation than imperatively writing UI mutations. It prevents entire classes of bugs.
We’re waiting for Facebook to release some of this stuff (GraphQL, Relay, React Native) and they’re opening up access slowly. Until then, if you haven’t tried it out yet, check out React.js. You’ll pick it up in an hour, have something fun working by the second hour, and have an opinion by the third. I’ll bet your opinion is that you never want to go back.
