Three takeaways from React Amsterdam 2017

Pinterest: moving to React

Jessica Chan explains that when the frontend team at Pinterest wanted to move to React two years ago, they faced a problem. Their template rendering at the backend was still handled by Django and Jinja (Python), while the frontend used the mostly compatible nunjucks javascript counterpart. Moving front and back end to React required changing the engine — mid-flight.

Server side rendering was a strict requirement, for SEO and sharing reasons among others.

They decided to take a staggered approach. First, they started to move all the template logic to JavaScript. On the server this meant decoupling the rendering from Django and asynchronously letting node.js render the templates. Once this was done, and once performance was up to par, they started moving templates to React one by one. The team has been very happy with the move, with improved performance and a codebase that’s easier to work with because it’s all JavaScript.

Interesting to see though that the server still runs Django for many other parts, since Django has long been our framework of choice.

You can watch this talk here

Silky smooth framerate with React native

We’ve all fiddled around with some framework to create ‘native’ phone apps based on one single code base. Phonegap and Appcelerator Titanium are some of the more known ones and these have existed since 2009. Our experience is that none of these ever tackled the single major issue when using web technology to create native apps; performance. It’s for this reason that when we first heard about React native we were not super enthusiastic. Tal Kol from Wix had a very nice talk about this ‘problem’.

He explained that the main reason why React can feel slow and non performant when creating an app is because of one bottleneck. This bottleneck is the ‘bridge’ that translates everything from the Javascript Realm (web tech) to the native realm (Objective C or Java code). Simply put: the more you use this bridge at any point in time, the more sluggish your app will feel and you’ll never get a smooth 60 FPS for performance. Tal states that the key to high performance in React native apps is to keep passes of information over ‘the bridge’ to a minimum.

Synchronous updates between realms is the biggest problem we’re facing. The Javascript code has it’s own thread, as does the UI for the app (the main thread). With synchronous updates slow Javascript will slow down your app, which you don’t want. Luckily React in itself is already highly optimized to always do minimal changes, this increases performance on the web, as well as in apps built with React. He put it like this: ”React uses a virtual DOM to track changes, and only the minimal amount of data is sent to the DOM”. This happens asynchronously and increases performance out-of-the-box. Perceiving the DOM as a native construct did not occur to use before, but it is actually a very good analogy and gives us more hope that React apps will perform better than other web based techniques.

React does have it’s limits however and eventually will get really slow if you have a complex app. Acknowledging this is key, and the solution is as simple as it is elegant. Native code. Tal showed how a simple ‘scroll’ handler can kill performance really fast, and how a little bit of native code can solve this in a heartbeat.

When you think about this, it seems React native is definitely the way to go when you want to build an app using web based technology. Sure some native code is almost unavoidable, but that is really only the case when you want high performance in your app. The majority of screens in your app won’t need this and you can create those really fast using technology you use every day. We can’t wait to give it a try and see for ourselves!

You can watch this talk here

Step into the future with React VR

One of the joys at our offices the last couple of months is to fiddle around with anything related to VR. Unfortunately nothing made it to production yet (!) but that doesn’t detract from the fun we have creating it. The technologies we’ve used until today are Unity and some high level AR / VR frameworks like Vuforia. We also had a quick look at WebVR which, in short, is a standard to bring VR to the web browser. In our opinion it still has it’s shortcomings in terms of browser adoption and performance. But on the the other hand: it has a lot of potential. It uses open technologies and unleashes the raw power of WebGL within a virtual environment.

To make the WebVR world an easier and prettier place, there is a React Library available, surprisingly named React VR, and created by the guys from Facebook.

Nik Graf from the Austrian company Serverless gives a talk about this topic. The first part of the talk is about the technology behind VR in general. After that, Nik zooms in on the role of WebVR and React VR in particular. Nik uses the novel ‘The Hitchhiker’s Guide to the Galaxy’ as an analogy to make the story more lighthearted and digestible. From a technical perspective, Nik explains the possibilities of the library really well. Especially the declarative nature of React makes it easy to setup and a maintain a VR environment within the browser. And the way the technology goes hand in hand with modelling tools like Blender is quite impressive.

For our next WebVR project, we’ll definitely use the power of React VR.
In short: a must see.

You can watch this talk here

Interesting bits and bobs

There were too many interesting things to list them all. You can watch the videos online, like this one where Max Stoiber explains how he’s handled styling inside React, or this one where Alex Castillo from Netflix talks about Redux error handling middleware that catch bugs in production before your users do. Finally, in this one, Michel Weststrate from Mendix explains why using MobX (or Flux or Redux for that matter) to separate state and components is a good idea, inspired by Caesar and Napoleon’s divide and conquer strategy.

We left inspired and enthusiastic. Our understanding of React has deepened, and seeing so many developers sharing the same views about React, and seeing that companies big and small are taking the leap and (re)writing their applications in React, leads us to believe this is a solid and futureproof choice. If your application is indeed reactive, that is.

Thanks to my colleagues Mark Dibbets and Robin van der Rijst for their cooperation in writing this article. By the way: do you want to become my colleague too? Check our developer vacancies (sorry, only in Dutch): https://www.fabrique.nl/vacatures/