This past weekend, Wayfair hosted the first-ever ReactJS conference on the East Coast. ReactBoston was a two-day whirlwind of talks on everything from the popular and pressing (React Fiber) to the unexpected and astounding (piloting drones with React; that sound you hear is the audience’s collective jaw hitting the floor).

As a relative React newcomer—I pushed my first React code into production less than three months ago—I was a bit worried that most of the material would be over my head. To my delight, I found the vast majority of talks accessible to even relative React beginners like myself: even the more complicated topics offered a toehold I could use to start to explore. This post is an attempt to share some of these more broadly and offer up a few resources to dig into to learn more. Trying to sum up two jam-packed days of content is difficult, but a few clear patterns emerged over the weekend:

1) People are very excited about React Fiber.

Announced in April and released officially this week, React Fiber (the core architecture underlying React 16) is a complete rewrite of the React core aimed at more sophisticated reconciliation and rendering. Fiber’s approach to server-side rendering (SSR) drew particular attention; Sasha Aickin pointed out in his keynote on Saturday that the rewrite brings significant SSR performance gains, largely because Fiber now completely ignores the vDOM (which SSR in React previously generated and then ignored) when server side rendering. As a side benefit of this, the HTML that is generated on the server is much cleaner, without the plethora of data-reactids we’ve come to expect. More on this, plus a benchmark test of the time-to-render for React 15 and React 16 across different versions of Node, is in Aickin’s Medium post on the topic. Curious about server side rendering but don’t have a handy server to play around with? Natalie Qabazard covered serverless SSR, an oxymoron that made rapid sense after her demo.

React 15 vs 16 Benchmark

React 15 vs 16 benchmark test (credit: Sasha Aickin)

A few other neat things about Fiber mentioned at the conference:

  • In addition to the SSR performance gains, Fiber will improve perceived performance through scheduling, which lets React prioritize certain high-value updates (e.g., animation) over lower-value ones (e.g., something happening offscreen).
  • Fiber introduces the ability to stream SSR-ed content, reducing time-to-first-byte down to 0. This has some potential cons, namely that it can be hard to juggle asynchronously loaded content with a stream. Aickin offered a solution involving placeholder elements that are filled in by script tags that are sent in the stream after the content loads (including a sync vs async streaming rendering demo), but noted that this approach can still make an app feel a bit janky.
  • React 16 components can render arrays and strings: there’s no need for an extraneous wrapping element. Ben Ilegbodu also pointed to react-aux, which takes advantage of this new ability to create a component that renders only its children (helping to make intent clear in cases where this is the desired output).
  • React 16 components will render nonstandard attributes. This is useful for browser/vendor-specific attributes, new APIs React doesn’t know, and third party libraries.
  • Fiber introduces “error boundaries,” special components that can catch and handle errors, preventing the entire app from unmounting when something goes wrong.

2) GraphQL is on the rise.

Several talks touched upon various aspects of GraphQL, which lets clients request specific shapes of interrelated resources from a server without having to hit multiple REST endpoints (and potentially over- or under-fetch what they actually need). Dhaivat Pandya laid out a mental model of GraphQL, which can be boiled down to three ideas: queries (which let clients ask for specific information), mutations (which let clients update information), and schemas (which define the available information types and their relationships). Robert Zhu followed up with a live, Game of Thrones-themed interactive demo of GraphQL subscriptions, which let clients get updates without introducing polling. (Interested in GraphQL specifically? Wayfair’s 3D Model API is open to the public!)

3) You can do almost anything in React.

ReactBoston offered the opportunity not only to learn about key developments in the React ecosphere that are immediately applicable to day-to-day work; it also showcased some of the most beautiful and most boundary-pushing uses of React.

4) The React community is warm, supportive, and welcoming.

This last point is less about the tech and more about the overall conference experience. I wasn’t alone in being impressed with the degree to which conference-goers and presenters alike were friendly and encouraging: Aickin pointed out that audience questions were real questions instead of comments. Speakers recognized their colleagues, fellow presenters, and mentors from the stage. Multiple presenters spoke for the first time, and their talks were well-received and loudly applauded. Open source contributions from experts and newbies alike were invited, and the immense value that open source maintainers provide to the community was resoundingly acknowledged. Links to documentation and detailed code examples were shared (especially by Mark Erikson, who in his very first conference presentation unleashed a torrent of neatly organized information about the Redux ecosystem, but also by Robert Zhu about GraphQL and Marcel Cutts in his talk on ReasonML, among others). I left feeling overwhelmed by the amount of knowledge that had been slung my way in 48 hours, but confident that there are resources and people who are eager to help me make sense of it all.

***

Many more speakers than I’ve mentioned above gave excellent talks on topics ranging from testing to maps and charts to content migration. A full stream of the conference is available on YouTube, as is the detailed schedule.

Interested in learning more about React or joining the Boston-area React community? Wayfair hosts the ReactJS Boston meetup, which meets roughly every month.