Why and How Coursera Does Isomorphic Javascript: A Fast and Snappy Quiz

By Turadg Aleahmad

Pop quiz! Have no fear; this will be the easiest Coursera quiz you ever take.

Coursera’s home page is rendered by…

1. your browser
2. a server.
3. a server and also your browser by the same code.
4. microscopic monkeys squeezing the liquid crystals in your display.

If you answered C, you are correct! Coursera has adopted isomorphic rendering.

“Isomorphic” rendering means…

1. your UI feels snappy, like a good Single Page App.
2. your UI renders fast, before all the SPA assets are downloaded.
3. both A and B.
4. the same as Universal Javascript.

If you answered C, you are correct! (Partial credit for D). Back in the day, web pages were all rendered on the server and the web browser simply turned the HTML into pixels. Web browsers have come a long way since Mosaic and are now little operating systems. Web pages are little applications that run in them. This has allowed more of the logic of a web application to run in the client instead of the server, and for UIs to be much snappier. But it has also meant:

SPAs take longer to become interactive because of all the assets that have to be downloaded to the client. (Forming a cottage industry of spinners.) What you really want is to have the page arrive fast like in the old days, and then to be snappy once all the client logic is running. Isomorphic rendering buys this the best of both worlds.

Why did Coursera adopt isomorphic rendering?

1. We adopt any new shiny tech.
2. Our servers were too idle.
3. Many of our learners around the globe have relatively poor network connectivity.
4. Fridays our engineers play Truth or Dare and there were no questions left for Truth because we are such a transparent company.

If you answered C, you are correct! Coursera’s mission is to create universal access to the world’s best education. Moreover learners with slow networks are often those must hungry for education. We must reach low bandwidth, high latency environments like mobile networks in India and eventually over drone link in rural Africa. In extreme cases, we saw some users in these environments wait minutes for all the Javascript to load before they could see even the page. We knew other potential learners with poor connections must be simply giving up. In controlled experiments, we found a drop in usage around 8s page load time. With isomorphic rendering, we were able to meet this threshold even in many of these extreme cases.

With server rendering, learners with the 10% slowest connections saw…

1. Coursera pages 2x sooner.
2. Coursera pages 3x sooner.
3. Coursera pages 4x sooner.
4. Coursera before they even requested it.

If you answered C, you are correct! At the median of our time-to-interactivity metric, our pages reached learners twice as fast. Learners at the 90th percentile received our pages four times as fast as before. And for the 10% with even slower connections, the gains were even greater.

How

So how does it work? Isomorphic rendering places new demands on development. We share some details on:

• application architecture
• serving infrastructure
• development

There is also a considerable cost to migrating existing applications, which we’ll cover in a future post.

Application architecture

Coursera’s isomorphic applications are in…

1. Backbone
2. Meteor
3. React
4. ScalaJS

If you answered C, you are correct! Note that there are many ways to go isomorphic. We use and recommend React with a Flux application architecture. We’ve been gradually migrating from Backbone to React over the past year and it has provided marked improvements in our developer experience and velocity. We had already adopted React so the cost here was only added costs for isomorphic rendering were to manage rehydration. Here’s how it works:

We may write another article with details on Edge, Render, and the Node co-process. If you are interested, please let us know @CourseraEng.

Once you’ve got the rendering working, you’re all set, right? Actually, there are still a number of things to keep in mind in your app development. Here we describe a few.

Development

User actions before rehydration

In your client-side rendered SPA, the user couldn’t do anything until all the Javascript was running. Now she sees the page before the Javascript assets arrive and she expects to start using it. What do you do?

WHAT DO YOU DO?!

1. Go Web 1.0, <form> tags, server handling, all that.
2. Limit interactions until rehydration.
3. A or B on a case-by-case basis.
4. Insert <script> Array.prototype.slice.call(document.querySelectorAll(‘*’)).forEach(function(node) {node.onclick = function(){window.alert(‘RELAX! PAGE NOT LOADED YET.’)};}); </script>

If you answered C, you are correct! Some actions you never want to make a user wait for. Signing up is a good example. “Oh I want to sign up to learn with others and works towards a better life but there’s this big spinner. Nevermind, off to cat videos.” Because this happens (in our data 37.337% of the time) we replaced our JSON auth APIs with good old Web 1.0 x-www-form-urlencoded form POSTs. Thanks to HTML5 we were able to use the browser’s native form validation without waiting for Javascript. Of course sometimes there’s no way around running Javascript, such as a nav menu. In these cases you might want to insert a little bit of Javascript on the page to handle each case. But be careful because these are hacks out of your React flow.

Event tracking before rehydration

Whatever your users do before rehydration, you don’t want to lose those events. If you fail to event before rehydration then you’re introducing sample bias into all your analysis, differentially excluding events from people with slower internet.

We solve this with a library we call Retracked that we’ve open-sourced at [https://github.com/coursera/retracked]. To track clicks, we put anchor tags on the page, but instead of a React-Router Link, we use Retracked’s TrackedLink which augments the <a> tag to record events the same pre- and post- rehydration. To activate it, a separate snippet of Javascript listens to all TrackedLink anchors on the page and records clicks. Once rehydration happens it lets React’s event handler take over.

Operations

Your code is flawless, but sometimes other developers you work with may cause problems. To minimize the impact on users we have unit tests, integration tests, and continual monitoring. Our unit tests ensure that our basic server-side rendering code path works in our testing environment. Once code is landed on master, we have Selenium tests on staging asset builds that verify the SSR is working with production services. Because our Edge service is robust to server errors, we test not just that the page renders but that it rendered on the server before the client. All that takes is testing for the presence of the data-react-checksum attribute produced by renderToString(). Finally, our monitoring systems tracks “time-to-interactivity”, the time it takes a user from navigating until they the page is useful to them. Using the Navigation Timing API, tti = (timing.domInteractive — timing.navigationStart).

Take-aways

• Isomorphic rendering can dramatically improve your users’ experience
• Developing apps that run SSR introduces some enduring complications
• You might love working at Coursera.

Thanks to Richard Wong, Brennan Saeta, Nick Dellamaggiore, and Joshua Newman for reading drafts of this.

Subscribe to Building Coursera for our next article detailing problems we had to solve while migrating.

Originally published at building.coursera.org on August 18, 2015.