React Amsterdam 2019: A Recap

This year, the React Amsterdam conference was held on April 12, welcoming 1,300 attendees from places including as far away as New Zealand. Once again, it was a two-track event—General and React Native; the former is covered here.

The day practically revolved around the newly released React feature hooks, as one would have expected, given the recent chatter in the React community. Hooks allow for React components to be pure functions, doing away with the previous class structure. They were released for production in February with React version 16.8, and a large number of developers at the conference were already using them for their live applications. The enthusiasm for this new technology shone through in most of the developer talks on the General track.

Other speakers focused on the interaction between developers and designers, Scalable Vector Graphics (SVG), successful refactoring, and architecture patterns for scalable front-end design. The entire 8-hour track can be viewed on YouTube.

Full talks

Keynote: Requisite React by Kent C. Dodds

Programming Educator and ubiquitous presence in the React community Kent C. Dodds had three suggestions for the conference attendees: Dive deep on the fundamentals, learn how abstractions work, and don’t be afraid of node_modules. He urged the audience to take a look under the hood of the technologies they use in order to be more effective engineers.

Elaborating on abstractions, he broke down how React renders JSX code, demonstrating how JSX is “just JavaScript”—a phrase many developers employ but don’t fully comprehend. Exploring how these technologies work enables us to write better code. For instance, there are rules about writing JSX that are much more logical when understood in the context of the actual functions being called.

Finally, he encouraged us to build abstractions ourselves so that we can understand them more deeply. Anything in your node_modules is fair game, but he specifically mentioned Lodash methods.

Dodds’s slides can be found on GitHub.

Refactoring React by Siddharth Kshetrapal

The skill of live coding is one few possess. Siddharth Kshetrapal, Design Systems Architect at Auth0, was able to refactor React code live on stage in front of the 1,300 attendees and made it look easy. His refactoring demo emphasized the best practices to use with React:

• Name behaviors, not interactions. When working with a Switch component, for instance, it’s possible to use onClick, onToggle, or onChange to make the toggle “on” or “off”. The behavior is that the switch changes state, but the interaction would be the click. Therefore, the name onToggle would be fine for the event handler to use were it not for the fact that it increases the mental load of developing. Using onChange instead normalizes the application programming interface (API) for components across the application.
• Prop order is important. Props that are given after others will overwrite the previous one. Keep this in mind when determining what should control component behavior.
• Use tests to have confidence in your refactoring. The first step for any big refactoring should be to make sure functionality is reserved. Having a just-enough test suite ensures that the most important code functionality will be preserved without bogging down your application.
• Use children instead of custom props. Kshetrapal gave the example of an Alert component. Instead of creating a message prop and passing it, simply add text as a child of Alert: text. In the Alert component, render {…this.props.children}. This makes the Alert component more flexible and will display any children, including divs, spans, icons, and so on.

Links to full blog posts on each of these topics and a few others are available on Kshetrapal’s website.

A Common Design Language. Let Designers and Developers Talk to Each Other by Andrey Okonetchnikov

In Andrey Okonetchnikov’s view, one problem the web-development community faces is the inability of designers and coders to collaborate effectively. Designers make beautiful displays in Sketch and other programs, or even on paper, and developers need to translate these visuals into the language of computers. So, Product Designer and front-end developer for Feedly Okonetchnikov elaborated on a way of combining these skills: Through the use of UI primitives.

HTML primitives are the base building blocks of HTML: div, p, a, and so on. A UI primitive is a similar basic unit of presentation, but encoded specifically to match a project’s design system. For instance, a project may have a developer-created that operates much like a . The major benefit of defining a Text component is the ability to set properties on it that a design system translates—warning, perhaps, or emphasis. While a tag can take CSS properties as well, scoping down the options allows developers and designers to understand the same code.

Another benefit of creating a UI primitive library for a project is that you can export these designs into Sketch, allowing designers to work with the components as they would appear in code to the developer.

Designing with React by Mark Dalgleish

Piggybacking on Okonetchnikov’s talk, Mark Dalgleish, DesignOps Lead at product and technical blog Seek and co-creator of CSS Modules, detailed how developers and designers can use exciting new React technologies to collaborate. The future of web development is in “blurring the lines between design and code,” he said. React makes this easier by abstracting the HTML, CSS, and JavaScript behind components and JSX, something developers and designers can both use for different but related purposes.

He debuted a tool created by his company called Playroom, one of the coolest technologies demonstrated at the conference. This enables users to work with components like building blocks, whereby they can write JSX code with predefined components right in the browser. Users can also share links to JSX they have created and work together through the editor. Best of all, it’s open source, so teams can manage this tool for their own projects.

Tech Regrets at Spectrum by Max Stoiber

Spectrum and styled components are two big-name products that 23-year-old Max Stoiber has written. In his frank talk, he covered the four biggest tech regrets he has about how he built the open-source chat app Spectrum and the lessons he learnt from those mistakes:

1. Not using react-native-web. Designing mobile-first applications and translating them to web is much easier than going in the opposite direction. React-native-web allows for a smooth conversion of code to web-based products and would have made his work much easier.
   Lesson learnt: Optimize for learning, prioritizing iteration speed and flexibility.
2. Not using Next.js. Stoiber and his team chose to build their own server-side rendering (SSR) and found it massively inefficient to build.
   Lesson learnt: Use proven out-of-the-box solutions for problems you do not understand properly.
3. Using RethinkDB. Spectrum was built on the obscure database RethinkDB, because at the time, it offered a feature that was unavailable on other databases: Listening for live updates. Though this is an appealing feature for a chat-app database, the lack of community created troubleshooting problems for the Spectrum team.
   Lessons learnt: Carefully choose technologies in case they are difficult to change later. Prioritize community size and active maintenance, especially in unfamiliar territory.
4. Using Draft.js and a WYSIWYG editor. The Spectrum team was very excited about delivering a WYSIWYG editor for Spectrum users, but this feature came at the cost of many other features users were asking for. WYSIWYG editors are a very niche product that are infamously difficult to implement.
   Lessons learnt: Thoroughly assess cutting-edge technology and favor conservative choices. Be open about a product roadmap so that end users can provide feedback about what features they are looking for.

Scaling Applications with Micro Frontends by Max Gallo

The pattern of scaling applications with microservices on the back end is one very much back in style in web development. Max Gallo, Principal Engineer at video-streaming service DAZN, presented an architecture for creating microservices on the front end. He recommended organizing developers into small full-stack teams responsible for individual business domains, such as authentication, recommendations, and checkout.

Teams can enjoy a great deal of autonomy with this approach, as each can have their own versions of technologies and dependencies, and are able to innovate quickly without getting bogged down with concerns about other parts of the application. Additionally, since they work independently, the amount of people needed to be involved in decision-making goes down dramatically, meaning there’s much less need for communication and more time for working on ideas.

The main downside to this pattern is code duplication. Because different parts of the application are not being shared, items such as headers and buttons may be duplicated across teams. However, Gallo sees this as an appropriate trade-off for the benefits obtained through using micro frontends.

An SVG’s Tale by Elizabet Oliveira

Scalable Vector Graphics (SVGs) are images that are rendered dynamically based on code, meaning they can be controlled by props and state, just like any React component. Elizabet Oliveira, Senior UX Designer and Developer at health services and innovation company Optum, explained how SVGs can function inside a React codebase, demoing several projects she has built using this technique—as well as rapping freestyle in front of all those attendees.

Her React Kawaii open-source project, which won the Fun Side Project of the Year at React 2018, is a collection of adorable SVG graphics with various “states” of emotions—sad, excited, and so on—that could potentially be toggled with prop changes in an application.

The GraphQL Developer Experience by Peggy Rayzis

GraphQL is a very popular alternative to a REST API because of query speed and flexibility. Peggy Rayzis, Engineering Manager at Apollo, a wildly popular GraphQL client for React, argued that the greatest advantage of adopting a GraphQL pattern is developer experience. With Apollo, developers can leave their application data layer almost entirely in the hands of someone else.

Apollo works as a wrapper around components, allowing injections of GraphQL data fetches. This exposes data, loading, error, refetch and networkStatus props to the wrapped component, giving developers an efficient and DRY (in other words, “don’t repeat yourself” when it comes to software patterns) way to fetch data.

Rayzis demonstrated a refactoring of tutorial code using Apollo, greatly simplifying the example. She also showed off several tools Apollo has made available to improve the developer experience, including an extension for the Visual Studio Code editor.

Painting Pixels with WebGL with React Hooks by Ashi Krishnan

For the last talk of the day, Ashi Krishnan, Senior Software Engineer at GitHub, took attendees inside the engines that enable touch-screen drawing. When a user draws on a screen with a stylus, a large, complicated array of actions takes place to determine where on the screen the touch occurred, how much pressure was used, and other effects, such as what color was selected.

Krishnan’s beautiful presentation tied artistry with code and ended with a classic computer simulation called Game of Life, which she had coded to display colorful blobs on the screen that ate each other. In layering them, she was able to “draw an intergalactic civilization.”

She also talked of looking forward to a time when “paintings paint themselves” and our technology allows us to “explore a world of chaotic non-determination.”

Lightning Talks

The lightning talks focused on SSR, which involves creating a static view of your application on the server and shipping it to the client. The client, meanwhile, loads the site’s JavaScript. The speakers in this section highlighted the benefits of SSR and also discussed its drawbacks.

Next for Next.js by Tim Neutkens

Lead Maintainer for Next.js Tim Neutkens presented statistics for the framework, which has become exceptionally popular for delivering SSR applications. Uber, GitHub, hulu, Twitch, and the Chinese site Tencent all use Next.js.

Neutkens also debuted the stable release of MDX, which allows developers to inject JSX into their Markdown.

Fetch Like a Boss with React Async by Gert Hengeveld

React Async is an open-source library that serves as a wrapper for HTTP requests through the Fetch API. Utilizing hooks, of course, it ties into the React lifecycle methods, handling pending, fulfilled, and rejected states. Gert Hengeveld, a Full Stack Developer at software company Xebia, explained that this tool can be used to minimize code surrounding data requests and keep a codebase tight.

Lightning-Fast SSR React Apps with Top Perceived Performance and No (Client Side) JavaScript by Håkon Gullord Krogh

Håkon Gullord Krogh, Frontend Architect at Norweigan product-design company Snowball Digital, made a bold statement in his talk: It is not true to say that SSR provides faster delivery for the end user. Because there is a latency between when the user sees the content and can interact with it, an “uncanny valley” is created, where the web app does not behave as expected. Krogh encouraged the audience to take responsibility for this problem and lobby for resources to speed up the time it takes to reach interactivity.

Speeding up React SSR by David Mark Clements

In his presentation, David Mark Clements, Principal Architect at software company NearForm, presented ESX, a tool his company built to decrease the time it takes for SSR apps to deliver to the client. It improves the algorithm for creating DOM elements, reducing the stress on the server to serialize the React object tree.

Demystifying Server-Rendered React Apps: Performance and Security by Fernando Porazzi

There are two main reasons to deliver SSR applications: SEO and performance. Because search-engine crawlers cannot work with single-page applications, much of the content that applications possess is hidden behind JavaScript that does not load. SSR applications are able to get around this problem as they deliver static content. Load time is important for conversion, explained Fernando Porazzi, Head of Front-End Development at IJsberen. He also argued for showing “something” (static content), even if it’s not the full application, as in some countries up to 2.7% of users have JavaScript disabled. On the other hand, he pointed out, SSR applications are slower “to first bite”, increase code complexity, and require a change in mindset.

What we learnt from the event

It was a long day, packed with fairly short talks that left attendees spinning with new ideas:

• Hooks! More than half the presentations either included code with hooks or referenced it. This brand-new technology has already consumed the imagination of the React community. We learnt how to use it in many ways in production.
• Server-side rendering. After the lightning talks, attendees were left questioning how they could use SSR to improve the speed of their own applications.
• Design systems versus micro frontends. Okonetchnikov and Dalgleish’s talks about enabling designers and developers to talk to each other more easily presented an interesting contrast with Gallo’s talk about micro frontends, where application code is handled completely independently by small teams. One encourages maximum sharing, the other requires none. It’s fascinating to consider the various architectures and processes that make diverse teams successful.
• SVG and WebGL. Working with JPEGs and PNGs is simplistic compared with lower-level image rendering and SVGs, but the flexibility allows for many new possibilities.
• Many new tools and plug-ins. The most interesting demo was Dalgleish’s Playroom. It’s safe to say that many of the developers who attended this conference set up their own version of the studio when they got back home.

What we liked about the event

• The atmosphere was extremely open and friendly. You could find someone to have lunch with just standing in the food line. The after-party was actually really fun!
• All of the speakers were clearly seasoned professionals—both technically and from a public-speaking standpoint. The organizers chose their presenters well.
• Most of the talks were accessible to developers of all levels.
• We got to travel by boat to the conference.
• The organizers have created a really cool logo and gave us a bunch of swag with it on!

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustrations by WTTJ