React.js Conf 2016 Quick Summaries — Day 2, Part 1

Feb 23, 2016 · 8 min read

I was lucky enough to attend React.js Conf 2016, and as presentation happened I jotted a few notes about each talk. These aren’t complete summaries and there will be errors in the notes, but hopefully they’ll point you in the right direction when deciding which talks to watch.

You can see the complete schedule here.

Thanks to inFlow Inventory for sponsoring my attendance.

Team × Technology

James Ide (Exponent)

With React Native, mobile developers are able to increase both their productivity and scope of work. The cross-platform technology is fantastic for teams building for Android and iOS, and developers can take ownership of products & features instead of single-platform implementations.

At Exponent we’ve extended this idea to include both products and infrastructure. I’ll talk a bit about how we apply this to our software development and the benefits and challenges of growing full-stack developers into cross-stack mobile developers who are responsible for Android and iOS.

  • React Native is ready for primetime
  • Core contrib to React Native, ~150 commits, worked at Google, Microsoft, Exponent

2 significant changes

  • 1) 1 billion computers, many mobile, some companies make more money on mobile than desktop
  • 2) React Native, challenges conventional wisdom, but extends beyond code
  • React Native will change the way teams are organized

Why React Native is awesome

  • React Native has a much higher ceiling, can take you further than DOM, embed native maps, camera anywhere
  • Extensible runtime
  • Mobile first, designed from day one for mobile devices
  • React Native apps just feel better, feel great out of the box, feel responsive by default
  • Most used mobile apps aren’t built with the DOM, built with native SDKs
  • App development is cross platform, fast feedback, edit code significantly faster than
  • JS deployment is faster, less disruptive
  • Continuous deployment means you’re always releasing
  • React Native is multithreaded, UI thread, main thread
  • React Native is open source, can read the code and contrib to it
  • Can’t do source inspection with iOS UIKit
  • React Native is guided, core contribs are using it in the apps used in their companies

Is React Native Ready for Production?

  • High quality mobile experiences are possible
  • In use at Exponent.js
  • Real apps that are going out to production
  • Brighten app: infinite feed, UI that users expect from mobile, 60fps in React Native
  • The List App: if Exponent could build List App, could build other apps: infinite feed, image gallery, native animations

React Native is only part of the story for success

  • Future mobile engineering teams: assembling a team with expertise in React Native
  • Personal Qualities: Open to RN, not same as HTML / Be unafraid to look under the hood; RN overs a lot of surface area / understand how RN works, diagnose problems at several levels of the stack

The code is the documentation, this is especially true in React Native

Experience with React is not a pre-requisite. React is picked up quickly.

  • iOS and Android SDKs are very large, different on each, different lifecycles, understand the trade offs of building Native vs RN
  • Mobile developer is keenly atuned to gestures, something you don’t learn if you are only doing desktop web dev


  • cross platform teams
  • product owners control user experience, have agency to make changes
  • One person should be responsible for a given feature’s vision so APIs are consistent
  • Not Cross Platform, but Cross Stack Engineer: cross platform responsibilities
  • React Native improves the way we work as mobile devs
  • React Native is ready today

Universal GL Effects for Web and Native

Gaetan Renaudeau (Project September)

gl-react is a universal library for implementing advanced filters and effects on top of images, videos, text or any VDOM Content (such as UI Views) — without having to deal with the imperative and low-level OpenGL and WebGL APIs. Because they are defined as simple React components, complex arrangements can be composed using the VDOM descriptive paradigm.

gl-react hides OpenGL’s statefulness and exposes its greatest functional feature: GLSL (an expressive ‘functional rendering’ language) and its rendering pipeline that runs on the GPU. Effects such as blur, saturation, color rotation and tinting, image composition, noise,… can all be implemented easily. But OpenGL is extremely powerful, unlocking the potential for spectacular effects and UI components: image deformation, localized blur using depth map, normal map effects, and more.

  • React Solved Virtual DOM->DOM, state represented in a functional way
  • gl-react aims to solve same problem
  • Virtual GL->WebGL or OpenGL
  • OpenGL is a pipeline with a series of steps, vertex shader, fragment shader….
  • Fragment Shader: functional rendering, from a point to a color
  • Not limited to primitives, efficient, stateless, scalable, rendering can be split into different paths and run in parallel on the GPU
  • see
  • gl-react can be composed as easily as React
  • Real world use case: wanted to have text over an image where the image is blurred just behind the text
  • gl-react hides imperative part, universal GL with DOM and native implements
  • Expost GL components on NPM and can use them
  • VDOM referential transparency means complex rendering is reduced

Redux, Re-frame, Relay, Om/next, oh my!

Jared Forsyth (Khan Academy)

Managing client-side state is pretty easy for TodoMVC, but soon after you move beyond that, your app can quickly get brittle, discouraging re-use and significantly complicating maintenance. I will give an overview of a few of the libraries/frameworks that have appeared recently that try to address this problem, show how each of them looks when used in the React context, and then discuss advantages, disadvantages, common patterns, and what we can learn.

  • Managing app state in React
  • Khan Academy has very rich JS apps, care about managing app state

What’s the Problem?

  • React is the V in MVC, library not a framework
  • fit React in with backbone, angular, but React is opinionated about data
  • React specifies some data you can modify and some you can’t
  • 2014 — Flux was the solution. Not a library, but a paradigm
  • To start, plain React components set their own state, sharing props, but lots of component props to trace
  • Redux, most popular way to do this right now
  • Redux Problem: creating an action requires touching 3+ files
  • At Khan Academy, started using Redux in production from flux
  • Redux still has problems with certain state mutations, but easier to get everything in your head about the state of your app
  • Re-frame sets up subscriptions instead of ‘mapStateToProps’ that can be reused
  • Relay requires graphql, but shared state is declared in the component
  • Relay defines mutations in the client and the server
  • Benefits, even more declarative, but a lot more complexity involved including setting up graphql backend
  • Om/Next: custom query resolution w/ both client and remote state supported, but less optimized than relay and written in closurescript


  • have conventions about how to manage app state
  • decide what you’re going to do and stick with it
  • don’t have ad-hoc solutions scattered throughout your app
  • use pure components as much as possible means you can swap out data layer easily because view doesn’t depend on the library used

Lightning Talks

⚡⚡⚡ ⚡⚡⚡

Contributing Vapor

Devon Lindsey (Apple)

  • There are a lot reasons why people are not contributing upstream even though we really want to
  • those who can’t (legally forbidden, employers, license, etc)
  • those who don’t (can’t find enough hours in the day, imposter syndrome)
  • those who won’t (community can be divisive and exclusive; keeps people out
This is what diversity looks like
  • to get involved, clone a repo, run the code, add documentation, be a community builder
  • write blog posts, write instructional videos
  • if you have extra time, start a meetup
  • evangelise the software you use and love, sing the praises

A React Native Retrospective

Eric Sauter (Fixt)

  • React Native Sucks (a little bit)
  • New product experience in RN is awesome, start building without configuration, many compenents and APIs built in
  • But in order to build new components need Xcode, objectiveC, Swift…
  • When things are broken, use github issues, but long running issues don’t get solved, many PRs, all take away time from conribs
  • But RN is awesome, spoiled by this, issues seem really big when they appear

Buzz: A Distributed, Event-Sourced GraphQL Server

Adam Wolff (Facebook)

  • problem at FB: post on a permalink page, needs to get all the posts, then all the likes, then all the profiles of those liker
  • 2 hop data fetching of graphql is great
  • but live updating doesn’t work well
  • if someone likes a comment, can’t listen for changes on the post, so have to listen to all comments for their changes
  • use immutable data to represent data structure and edges
  • Stream graph representation, a log based append system for a bag of properties
  • Apps are getting more real time, broadcast based message protocols (UDP), probabilistic data sending

React Native for Web

Nicolas Gallagher (Twitter)

  • styling and accessibility
  • DOM primitives aren’t rich enough, React Native gives better implementation
  • React Native apis can run the examples right out of the repo on the mobile web
  • replaced webpack, css modules to React Native Web for Twitter mobile web
  • Stylesheet object avoids styling colisions by creating unique classes, automatic atomic css that gets optimized into minimal footprint
  • no build step
  • supports universal rendering
  • render on the server, get back styles and html, only what’s needed is returned
  • maps accessibility aria properties and roles for the web

“Learning” Other Languages Makes You A Better Javascript Developer

Cole Voss (Hudl)

  • Why learn other languages?
  • Googling this: “Impress people around you, develop confidence, become more open minded, challenge yourself, helping others, understand your own language better”
  • Coffeescript: helped learn Javascript because it looked like Ruby, also introduced new features of ES6, Ruby taught OO programming
  • C#: taught about type safety, used this concept to introduce Flow
  • Haskel: what it taught was what functional programming is
  • Closure: uses exclusively immutable data structures, parallel learning immutable.js, made learning immutable.js way easier
  • Go “learn” other languages!