Earlier this month, Netflix announced that they had dropped Java from the rendering pipeline for their primary netflix.com web application. In its place, the company is using an architecture that leans on two technologies that have received an immense amount of press in the last couple of years - Node.js and React.
The fact that Netflix is using either one of these tools to power its most public and widely-accessible app would be newsworthy on its own, if perhaps a bit unsurprising to engineers building modern applications for the web. (Node.js is being used in production by PayPal, LinkedIn, Microsoft, and many others. React, originally created at Facebook, is a major part of that company’s front-end architecture and is gaining traction at many other companies, including the BBC, Dropbox, and Airbnb.)
HTML From The Server
This is the way the world wide web was originally conceived. The user makes a request to a server via a web browser. The server responds to the request with an HTML document. Done.
Over the years, various tools have popped up that try to reduce this redundancy. Mustache, a templating language that allows users to layout HTML in a language-agnostic way, remains a popular option. But it requires some capitulations on the part of developers - most importantly, it’s intended to be used for presentation, not for application logic.
Additionally (and also very important): complex and highly-interactive UIs become much more difficult to build and maintain.
JSON (or some other structured data) From The Server
In many cases, no HTML is sent to the browser from the server after that initial page load. The result is a UX that’s more responsive and "app like.” Complex UI interactions - especially when you’re dealing with long-running sessions - become much easier to reason about and build.
This is how WillowTree builds most of our web applications. Because we’re so comfortable with this architecture, we’re also intimately familiar with two of its biggest drawbacks:
Back to Netflix. They and the RentalSpot team at WillowTree are attempting to architect a “best of both worlds” solution.
This is a bit oversimplified, but it captures the essence of what makes this architecture unique. In sequence:
The user makes an initial request to your site.
The server receives the request and uses the React application code to gather data and assemble views. The end result is a string of HTML.
The user interacts with the page. For instance, they might click some main navigation from your home page to the “events” section of your app.
The React app residing in the browser handles updating the associated views.
Steps 4 and 5 are repeated until the user refreshes the page or requests a page that specifies a full HTML refresh from the server should occur.
To Reiterate: There’s No Silver Bullet
As the patterns firm up and the tools around Universal JS continue to improve, expect to hear more sites adopting the architecture. It’s a compelling option with real benefits for users and developers. In the software development world, it’s hard to ask for more than that.