Notes on React Europe 2016

The second React Europe conference has just finished and this is a jotting-down
of some thoughts on the conference and my favorite talks whilst the Parisian red wine and almond croissants clear out of my system.

The Conference

This was a two-day conference preceded by a hackathon kindly hosted by Mozilla
and a welcome event hosted by Red Badger. It was well organized and ran smoothly, the main
part consisted purely of 30 minute talks with a few lightning-talk spots. There
was plenty of time in-between for discussions.

For the hackathon attendees made project suggestions on a wiki and the organizers also set an optional challenge that involved working on specific React/React Native GitHub issues. For me the important part is not the specific project being worked on but the chance to work alongside someone you haven’t met before and see how they think and use their tools. That’s something I tend to miss out on working remotely.

The conference is of course about React and most of the talks are about React or related parts of the ecosystem. What interests me most though is the broader exploration around the benefits for users and developers of applying
functional programming ideas to the front-end.

I think it is because of the functional leaning that this conference and Reactive
2015 last year attracted quite a number of people who work
with different but like-minded technologies (eg. Rust, Clojure, Elm). One fun hackathon output was rust-redux!

Talk Highlights

Dan gave a very good distillation of what made Redux as successful as it has been
in a very short space of time. The first thing he pointed out is that it isn’t because of
its feature set - the library is tiny and a basic version of the code fits
on a couple of slides. However the constraints that it imposes on the application
make it easier to reason about what is going on, makes debugging and testing workflows
easy and enables all kinds of interesting tooling which led to an ecosystem growing around it very quickly.

The part I found most interesting is that the design was ultimately a product of
two ‘stress tests’ that had to be satisfied - the ability to reload the
application without losing state during development and the ability to do
time-travelling debugging. These two tests sound like cool albeit non-essential
features. It turns out though that a design which meets these needs also makes
a lot of other features with user or developer-facing value easy: Undo/redo,
optimistic UI updates, persisting and restoring app state and cross-device
synchronization.

Whilst this is all true, I think the success also owes much to more practical
things like very good documentation and the fact that there is enough
flexibility and guidance on what to do when the app goes beyond the TodoMVC
example.

Oh, and there was a throwaway comment at the end that the “time travelling” requirement
came out of a change in the title of his talk last year at React Europe just to make it sound more
interesting 😀. Richard Branson would approve.

Cheng’s talk provided a useful way to evaluate technology choices in different
contexts by placing them on a spectrum of abstraction and understanding the
trade-offs that come with choosing technologies at different points on that
spectrum. The “spectrum of abstraction” refers to the fact that some technologies
solve very specific problems (eg. The clock app on a phone) and others
are much more abstract but are useful for a broader class of uses (eg. a Promises
library for JavaScript).

Cheng framed it as a kind of optimization problem to minimize the overall
cognitive costs of the codebase in order to satisfy an evolving set of use
cases. On the one hand, choosing unnecessary abstractions imposes a cognitive
cost because of the gap between the abstraction and the problem being solved.
On the other hand choosing too many problem-specific tools imposes other costs.

There was an interesting look at the trade-offs around the power that different
abstractions have. eg. Declarative systems for specifying things limit the
developer’s freedom but often enable useful tooling and optimizations because
of those constraints.

The talk then went on to discuss how to use this to deal with common
choices that front-end developers need to make. This included specific
choices such as imperative build systems (Gulp) vs declarative (Grunt) ones,
templates vs. functions for transforming models into views, mutable vs. immutable data structures.
It also included broader questions of when to even use an abstraction versus
just copying, pasting and tweaking code.

I think having these kinds of frameworks for looking at problems is pretty handy, especially
if you can visualize them, because then you can see gaps where there might
be solutions that have not been considered.

This was a technical dive into how the Flow type checker for JavaScript works,
how its approach differs from the type checking phase of a traditional compiler
and the possibilities that opens up for detecting classes of bug that a typical
compiler might not be able to. For example, detecting all the places that unsanitized
user input might reach in a program via taint analysis.

Beforehand I’d talked to many people who had some interest in trying type systems
for JavaScript and wanted recommendations for one or the other. Frankly I think both
are good options that you can’t go wrong with, but before this talk I only really
understood the more practical surface-level issues (like platform support) rather
than the deeper ones that stem from the differing priorities of the projects
and the fundamentally different ways that the tools understand code.

A couple of times Jeff mentioned semantic differences between the type systems.
This presentation from Oliver Zeigermann
shows a couple of concrete examples (although note that the upcoming TypeScript 2.0 release
does have non-nullable types).

The React community have produced several of the most successful projects on
GitHub, where “successful” in this context was taken to mean widely adopted/having direct impact.
This talk provided specific advice for project maintainers on how to help their
projects gain traction. Many of the points were things that would be obvious to
entrepreneurs behind new startups but are often forgotten in open source:

Talk to your users. It doesn’t matter which channel you use
but you need to be present on them and active. In the React project,
different members (and active contributors) tended to focus on
specific channels (GitHub issues, StackOverflow).

Ask as many of your users as you can two specific questions:

What did you struggle with? - Find out what they had problems with,
aggregate the feedback and prioritize. The phrasing of this question
is important because you need to break the implicit social barrier
that prevents users from criticising your work.

What cool stuff are you building? - Show genuine interest in what your
users are doing. Ask them to share what they have been up to (eg. by writing blog
posts) and then promote their work.

Create the perception of a community. When evaluating a technology
choice, the perceived level of community activity is often an important
factor.
In the early days of a project, it helps to create this perception by
asking users to blog about what they have been doing, writing community round-ups etc.
Over time, this perceception becomes its own reality.

Speaking of making users feel loved, the organizers produced personalized
T-shirts with GitHub handles for attendees who had made contributions to the
code or docs for various React-related projects. I thought that was a pretty
cool touch. Thank-you!

Also worth watching

Plus a couple of others from my notebook that I’d recommend seeing when
they are up on YouTube:

Andrew Clark’s talk on recompose was a useful introduction to
the concept of higher order components, what you can do with them,
the performance costs they can impose and how to mitigate these.

Lin Clark’s talk was useful if you want to understand what actually happens
when a component is “rendered” and why some of the performance tips
in the React documentation matter. Also it had cool cartoons.

Takeaways

The debate about basic app architecture from last year seems to have
largely been resolved in a pretty short time in favor of
the Redux/Elm model. Lee Byron’s talk
from RenderConf was cited a couple of times as a good overview of this architecture. The current
exploration has moved on to building all kinds of
useful tooling that assumes this model of state
management.

The exploration of how best to manage effects
nicely in Redux/Elm-like applications is ongoing
and there isn’t a clear winner yet.

React Native has been around long enough now that
people outside of Facebook have been able to build and ship reasonably sizable applications
with it and provide a decent appraisal of where
it works well, where it still needs improvement
and where it isn’t the right choice. Brent Vatne’s talk about
li’st is worth watching.

One of the main React/React Native focus areas right now is performance
especially for the common use case of apps that need to render large lists of
complex stuff whilst animating smoothly and responding instantly to user
input.