← Blog

Tis the season to be jolly in Reactverse

#Reactjs

This fall/winter is shaping up to be an exiting season for the Reactverse! Reactverse… like “metaverse” but for React, you know? 😉

On the core library’s side, the new Docs site, beta.reactjs.org, became available as a preview. Also, React 18 just hit its first beta release.

On the metaframeworks’ side, Next.js 12 was released recently with pretty much an entire conference dedicated to its annoucement. Shopify entered the scene with its own commerse-focused metaframework named Hydrogen. And Remix, which used to require purchasing license to gain access, just released its v1 as FOSS.

Each item in that list fully deserves its own article. In this post, however, I want to only briefly comment on each as well as its implications.

Core library

The stated goal for the new Docs site is:

[to] teach React Hooks-first, with a focus on “how to think in React” and deeply grok React over building an app in React.

Accordingly, the new Docs site marks that the paradigm shift to Hooks-based mental model, which began back in 2019 with the release of React 16.8, is finally complete! “Thinking in React” still follows the same principles, but all examples are now based on function components with Hooks.

This sets a novel foundation for a way forward, where API for new core features are provided as Hooks. And that’s exactly what the upcoming React 18 looks like.

When React 17 was released, the main highlight was that it had no new features. Instead, React 17 was presented as a “stepping stone”. React 18 is a complete about-face in that regard, packed with new features—even a new paradigm!—that embrace concurrent rendering and SSR.

And how are these new features are made available to us? As Hooks!

  • Do you need to keep your app responsive while expensive rendering is taking place by making certain state updates interruptible? useTransition().1
  • Do you need to bring in an exteral store that your components subscribe to (think Redux) and have it play nicely with concurrent rendering? useSyncExternalStore().
  • Do you need to generate unique IDs that can be shared between client and server and work well with (streaming) hydration? useId().
  • Do you need an efficient way to insert CSS <style> tags early (before useEffect() where the component is already mounted) but not too early (after useLayOutEffect() where inserting new <style> leads to slow render)? useInsertionEffect().

Yes, most major third-party libraries and (meta-)frameworks in Reactverse have already transitioned to Hooks-based API for a while.2 But isn’t it something to see that React itself is finally bringing that transition to its conclusion? Long live Hooks!

Metaframeworks

Let’s start with the latest of the OG React metaframework: Next.js 12. One of the most notable as well as most highlighted aspects of this release is its new Rust complier:

Our Rust compiler is built on SWC, an open platform for the next generation of fast tooling. We’ve optimized bundling and compiling with ~3x faster refresh locally and ~5x faster builds for production.

This is another huge win for SWC—likely one even greater than being chosen by Deno!—and serves as yet another testament to the growing adoption of non-JS/TS tooling by the JS/TS ecosystem to deliver performance. And it seems that Rust—mostly SWC, but also beyond that—sits at the heart of this new trend.

Meanwhile, we are seeing two new entries to the crowded React metaframework scene: Hydrogen by Shopify and Remix by the team behind React Router.

Hydrogen is intriguing to me because it’s the first metaframework that I know to fully embrace the React Server Components. Yes, Next.js 12 also supports React Server Components but that support is not central (yet!) to how Next.js works. And that’s understandable since, officially, React Server Components is still considered experimental. What’s fascinating about Hydrogen is that, instead of waiting for React Server Components to reach a stable release, the team is moving forward with its own “reverse-engineered version” of React Server Componetns. If that’s not ambitious I don’t know what is!

By the way, Hydrogen serves up another win for Vite, which by now has pretty much won the next-gen build tooling war in the frontend web development world.3 This, by extension, is another win for non-JS/TS tooling since esbuild, the not-so-secret sauce for Vite’s performant dev server, is written in Go.

If Hydrogen felt like a bit of surprise, Remix has been gaining a lot of hype and following since its original annoucement in April 2020.4 This is understandable since Remix is created and developed by the same people behind one of the most popular project in the Reactverse, i.e. React Router. I, too, have been following the project with a lot of interest even though I never signed up for the newsletter or purchased license to actually try it.

What stands out the most about Remix is how much it takes advantage of the web technology (“web fundamentals”, as they say), such as HTTP, native web APIs, HTML elements, browser and CDN caching, etc. In fact, much of Remix’s API feels like an ergonomic yet lightweight wrapper around the existing web technology. Meanwhile, Remix lacks support for Static Site Generation (SSG), which means a Remix app always needs a runtime. Instead, Remix is betting on the ongoing (r)evolution of edge computing and provides adaptors to various deployment targets:

While you were waiting for your static site to build, distributed web infra­structure got really good. Break through the static.5

Tis the season, indeed!

If we look back, React Server Components got just announced around this time last year, a huge news that excited and inspired so many people—including myself, of course!

And this year, what an amazing time again for the React community! In fact, I’ve only scratched the surface here, omitting many other exciting news in the Reactverse—most notably, React Router 6 and React Location. I very much look forward to digging into all these new and intriguing technologies this winter and, hopefully, grow as a web technologist as well.

Footnotes

  1. Invoking useTransition() returns the [isPending, startTransition] tuple, and startTransition is what we need to achieve interruptible state update. In fact, startTransition can be imported separately: import { startTransition } from 'react. ↩

  2. This shift hasn’t always been made easy. I, too, am currently struggling with my project at work that’s stuck with React Table 6. React Table 7 has brought a total overhaul of API—i.e. going full Hooks—without providing much guide on migration… 😥 ↩

  3. From what I can tell, SveltKit’s migration from Snowpack to Vite back in March practically made Vite the winner. Before that, it was not so clear which of the two would be the next-gen build tooling. (WMR from the Preact team never really took off…) ↩

  4. So much so that the project was able to secure enough funding and decided to go FOSS with v1! ↩

  5. A quote from Remix’s landing page. I find this developing very interesting. SSG was the backbone of what became today’s Jamstack, a still hugely popular—maybe even dominant!—strategy for deploying web sites/apps built with JS UI frameworks. With that in mind, I have to say that for a new major contender in the (meta)framework scene to completely skip SSG support is, well, telling. ↩