React Rally 2016 Recap

I recently attended the React Rally conference in Salt Lake City, UT. The conference was about the front end server and client framework React, created by Facebook. Speakers covered topics such as Redux, Relay, RethinkDB, Async and of course React and Javascript. React allows developers to write in Javascript easily on the client and server (universally), sharing the same code that comprises the components on both sides. The trivial benefits are for speed in rendering and ease of reuse but as the conference showed it does much much more.

Day 1 #

Sarah Drasner started the day with a talk on animation. If you hate animation, it might be because you’re doing it wrong. There was a big push for GSAP (GreenSock) as well as using SVG for animations and responsiveness.

Joseph Savona from the Facebook Relay team had the next talk regarding the new Relay 2.0. The main idea was for product devs to focus on product not how to get the data. Relay 2 will have collocated GraphQL with React components as well as a declarative API. It’s all about the Time to Interaction (TTI) - the time from app start to be able to see new content and interact with it.

James Long from the Mozilla Dev Tools team had the following talk on debugging your debugger. Refactoring large code bases - is it worth it? Don’t have that Oh Shit moment where you’ve spent so much time refactoring and it still sucks. He introduced a CLI debugger in the talk as well as the debugger.html open source project.

Brian Lonsdorf followed that up with his talk on composition. Handling state is the root cause of complexity. Everything is connected and data flows through like reading a book. Makes it hard to hack something in poorly since everything is composed which keeps you away from tech debt.

Kevin Old then did a talk on deploying GraphQL in a serverless context. Serverless is about not managing the infrastructure your code is deployed to. The push is to “optimize human time, not machine time” - mostly used for single-purpose, stateless functions so you can use a compute service such as AWS Lambda to execute code on demand by having push-based, event-driven pipelines.

Raquel Moss talked about all the terrible things she did when she made her first complex React app. Big, unwieldy components is the key problem since people are usually afraid to split them up because managing messages between components is a pain. Flux and Redux could be the saving grace but it is also quite a learning curve so basically just use the right tool for the right job.

Kate Hudson, from Firefox Engineering, afterwards talked about the problems she had writing multi-process apps (more than 1 JS runtime). She talked a lot about concurrency and the problems from wrong assumptions about it. Concurrency is about dealing with a lot of things at once. Parallelism is doing a lot of things at once. React and Redux helped deal with the complexity of concurrency by having:

• State is immutable
• Testable pure functions
• Composable components

“Concurrency is the composition of independently executing processes” - Rob Pike

Saif Hakim then had a talk on scaling React for heavy usage. How fast is fast enough? 60 fps for games but most people type at 12-30 fps.

What to Optimize? Bottlenecks - use Dev Tools to spot and clean. Prevent regressions by having better abstractions when rewriting components to solve perf issues.

Michael Trotter later on talked about PureScript and the idea that pure functions have no side effects. More about programming and not about how to build your UI.

Mike Glukhovsky the cofounder of RethinkDB ended day 1 with a demo of a photobooth app built on top of React, Node, and RethinkDB that is real time - it moves with you cross platform no matter where you are (Google Docs, Slack, etc). RethinkDB’s change feeds lets you build scalable, real time apps that is language agnostic. In fact, Glukhovsky drops that NASA runs RethinkDB on Space Suits which NASA constantly monitors in real time.

Day 1 Highlight: Dr Boolean #

Brian Lonsdorf from Oh Composable World talk revealed his secret (or not so secret) identity as Dr Boolean. It was definitely a key highlight of the first day especially when he started doing fun stuff with functional programming like dot chaining an entire React app. Conclusion: Map = compose = program construction.

Day 2 #

Marcy Sutton kicked off day 2 with her talk on accessibility, pitfalls to avoid and testing. Specifically her keynote on accessibility testing with axe-core provided the confidence and mantra to be in charge of accessibility in your application instead of having someone else do it for you. An example: React Modal test for escape key support using react axe.

Paul O'Shannessy from the Facebook React team followed that up with a deep dive on what the React framework does internally to display the DOM (very base case of the framework). Use React if you want, basically any framework has tradeoffs.

James Kyle from the Facebook Flow team went after with a talk on data structures. From Stacks (FIFO) to Queues (LIFO) and Graphs, there is no perfect data structure just tradeoffs. But generally picking the right data structure for your needs is a performance and memory game changer and also simplifies complicated logic.

Ben Lesh from the Netflix UI Team and the RxJS 5 Lead then talked about handling harder async tasks with Redux. He posits that cancellation of AJAX requests is the hard part and that middleware to manage async is common to deal with this. Observables are the future just as Promises took over callbacks.

Parashuram afterwards talked about performance on the Virtual DOM. He created a site http://web-perf.github.io/react-perf/ which measures the scripting time the Virtual DOM takes. His solution is to use Web Workers to reduce scripting time by creating a custom React Renderer (ReactWorker) which does the ProxyDOM on the Web Worker message bus it to the UI thread that then modifies the DOM.

• Rendering happens in Webkit, Gecko, etc.
• JS happens over runtime (Chakra, V8, SpiderMonkey, etc)
• UI Thread communicates with worker thread

Devon Lindsay talked about using our talents for charity. It can be as simple as doing 1 hour a month to give a little back to charity like creating a static React website for your local charity.

Drew Conley followed that up with his experience building a real RPG game on React. In the end, it was a big system but its filled with small parts. Iterate on each part separately and be setup technically to grow your game (or application). Separate Application from Content - makes game maintainable and easy to work on.

Jared Forsyth afterwards talked about real world debugging. How to prevent bugs? State management, having one owner which is the least common ancestor by embracing the tree. If the parent needs to know about it, it should be the owner of the state. How to catch bugs? Linting, testing, or your users. Depends on how important it is and how much time you have but none is really a good way to catch bugs. How to fix bugs? React Dev Tools to isolate issues if logic is decoupled from presentation.

Lukas Fittl talked about using PostgreSQL to power GraphQL boards. He insists that Serverless != Stateless since if you are using DynamoDB, there can still be state. It’s important to have our state in the database so we have our source of truth. There’s no best practice yet whether subscribe is best or pushing data out is best - the idea is just not to ask for all the data but just the data that you need.

Ryan Florence the cocreator of the react-router finished the conference with a very entertaining live coding of an application to show new ways of doing things by architecting an application using purely composition. Replacing old technology does not give productivity boost, you need to rethink best practices.

“It looks like recursion but it’s really not!” - Ryan Florence

Day 2 Highlight: Parashuram’s ReactWorker #

Parashuram had a great talk on Service Workers and it was truly amazing to experience the process in which he found the best ways to optimize the scripting time React takes. Traditionally to maximize efficiency, we need to multi-thread (throw computers at it), but in his case (and ours on the web) the idea is to leverage Web Workers. He posits a great argument for why aren’t web workers already in React? That way the web workers can handle the blunt of the scripting time while only sending mutation instructions for part of DOM tree that is part of the DOM tree.

Top Quotes #

“If you’re polling anywhere, you should figure out how to not do that" - Mike Glukhovsky

Glukhovsky argues that polling for data is slow, cumbersome, hard to maintain. Instead one should try to move to a push driven architecture. One source of truth makes it easy to manage state, RethinkDB can be that source of truth. If multiple DBs are required then use something like event sourcing + Kafka or RethinkDB to keep it to one source of truth and thus one state to handle.

“We made something that was really simple because it didn’t need to be complex” - Bernd Hartzer (who was quoted at the conference)

This was in reference to leveraging a Serverless infrastructure to handle large loads while still being cost effective.

“Your whole app must be "stateless functional components” … but maybe think about components and give them credit" - Ryan Florence

There are definitely tradeoffs for any approach, a Redux rewrite for Hyperterm generated 2,752 additions and 1,142 deletions so more code for plumbing. This was however a good decision since it sets the app up later on to grow rather than be confined. Florence creates a whole React app that is entirely made up of components, no Redux or Flux. “This looks wacky, but it’s really composable!”

Themes #

State #

• Handling state is the root cause of complexity
• Composing functions minimizes state - Build subsystems of reducers to be able to handle whatever state you throw into them
• Serverless architecture is for single-purpose, stateless functions
• Use state deliberately so the component can update independently rather than check the whole tree
• State is your enemy, as best as you can avoid spreading it
• React encourages stateless components vs stateful
• One source of truth makes it easy to manage state (RethinkDB and PostgreSQL)
• Decouple Logic From Presentation
• Redux is a library for managing state with reducers
• Do not set state in the component and pass it up to the parent → If the parent needs to know about it, it should be the owner of the state

The general consensus is that state is bad and is the root of all complexity. Out of the Tar Pit is a great paper that throughly explains this theory. There was different ways proposed to handle state but all of them have one source of truth.

Serverless #

Serverless might be the new hot tool, don’t need to worry about ops just application code. Apex (written in Go is an alternative) to Serverless Framework which helps deal with the stress of using AWS Lambda. You scale instantly, and only pay for what you use so its even cost effective. Serverless != Stateless, it’s important to have our state in the database so we have our source of truth. (talk by Lukas Fittl).

Feeds, Streams, Observables, etc. #

• RethinkDB Change Feeds for real time apps
• Connection Streaming in Relay 2 creates batched fetches
• RxJS = “lodash for async” in composing observables
• Observable is inert before subscription
• Epic is a function that takes a stream of all actions dispatched to reducers and returns a stream of actions to dispatch

Streaming / Subscribing is the way to go for the future, from heavily using generators to leveraging tools such as RxJS for async. This is the way to deal with data.

Right Tool for the Right Job #

Is React the right tool? Is RethinkDB the right DB? Is Redux needed? Should we use a Binary Search Tree? Is declarative better than imperative?

“When I have a problem, everything is a nail” - Ryan Florence

Developer happiness is the root of all happiness. Happy developers create great products. Sure sometimes you need to let your developers use trendy tools (like React a couple of years back) just for the sake of gauging the strengths and weaknesses of it. But trust your developers to make the judgement on what tools are needed to get the job done properly.

Charity #

While not really a theme, this is a plug for us to do better as a community (talk by Devon Lindsey). To help out, take a look at “the semicolon project” to help suicide awareness or simply take 1 hour a month to give a little back to charity by building a static React website to your local charity.