Reprinted from Swyx Wang.React Distros and The Deployment Age of JavaScript Frameworks. Feb 19 2020

Why don’t we have a front-end framework debate anymore, and a reflection on the React Meta Framework now and then

James K Nelson recently made an interesting point.

Mr. Abramov keeps telling us that # reactJS is a UI runtime. To me, it sounds like React is a kernel. The Webpack/Create React App is the boot loader. Next. Js and Gatsby are the closest thing we have to a release. Then I think we need more distributions.

If, like me, you’re not sure what a bootloader is, Google says “a bootloader is a piece of code that runs before any operating system runs. Bootloaders are used to boot other operating systems, usually each operating system has a specific set of bootloaders. I think that’s the runtime for Webpack, but it’s also a compilation mechanism, um, from/SRC to /dist.

Anyway, the metaphor is right. I’d like to shed some light on this problem.

To discuss

  • The Carlota Perez Framework
  • The “Age of Deployment” of JavaScript Frameworks
  • React Distros
  • What other React distributions should exist?
  • React release for people who build wheels

The Carlota Perez Framework

The VENTURE capital world is obsessed with the Carlota Perez framework. Fred Wilson and Marc Andreesen love it, and Ben Thompson, Benedict Evans, and Tuur Demeester have recently extended the concept to big tech, smartphones, and cryptocurrencies.

People love the DISS tech gurus and think they reinvent something every 10 years, it’s an endless, meaningless cycle. But really big trends tend to take a different shape.

The X-axis is 20-50 years, and the Y-axis is the percentage of population penetration. This has happened repeatedly over the past century, with the adoption of new technologies accelerating as we have improved in distribution.

The basic pattern is an initial phase, followed by a “fever” phase of massive growth and technological competition, followed by an inflection point where technologies reach synergy and maturity (often compared to Everett Rogers’ “late majority” and “laggard” groups).

The “Istallation Age” focuses on growth and innovation, often leading to creative destruction (read: mass churn). The “Deployment Age” focuses on stabilizing and addressing latecomers, which are often the needs of a larger market segment. In the former, where hobbyists and speculators dominate, things tend to be simpler. In the latter case, business people in suits dominate, and a lot of time is spent on trivial details.

The deployment era of JavaScript frameworks

I think the turning point for the JS framework started a year or two ago. We no longer have a new front-end framework every month. React has been at the top of the Hacker News Job Board for 31 months. But it’s not just React. Both Vue and Angular have found very stable applications in larger companies that won’t easily migrate their technology stacks anytime soon.

The era of deployment has brought with it the rise of “meta-frameworks” — frameworks built around frameworks that are designed to solve the deployment problems that the original frameworks were not designed for. React has next.js and Gatsby, Vue has Nuxt.js and Gridsome, Svelte has Sapper, Angular even recently has Scully. In most cases, these frameworks are designed to control a single DOM element and manage a tree of dynamic elements within it, and their meta-frameworks extend it to cover the entire site/application, including routing and static/server-side rendering.

I’m a big Marvel fan, so I like to compare meta-frames to the anti-Hulk armor that wraps around iron Man suits — they’re heavier, but more powerful.

React “Distribution”

Now let’s talk about the React “distribution.”

Obviously, the metaphor is appropriate. For example, React is Linux, Vue is MacOS, Angular is Windows. It’s just that Linux has the largest number of front-end frameworks in the world. There are dozens of Linux distributions built for different types of users, all sharing the same underlying technology. As React performs many of the operating system’s functions on top of the browser, this is an apt metaphor.

This is what I’ve observed in the last year:

React’s refusal to comment on things like styling and routing was the biggest source of frustration for users, but also the biggest reason for its success. There isn’t a framework called React, but more than a thousand ingenious frameworks. React gets the benefits of all of these frameworks.

This is both the best and worst thing about React — its small size and lack of guidance on many basic things. This means that not only do you get to choose what goes with it, you also have to make choices.

I disagree with James that CRA is a bootloader– I think it’s also a React distribution, which is a good distribution for single-page applications, but not a perfect one.

Here is an incomplete list of React distributions.

  • React Native – a distribution built for iOS and Android applications. One of the few React distributions actually includes good default components (because the target ecosystem has them).
  • React Boilerplate- Probably the first React release, just a clone of the Boilerplate.
  • Electron React Boilerplate– suitable for desktop applications.
  • React 360 – React for VR? Sure.
  • React Ink – React for CLI’s? Why not?
  • Next.js – Hybrid server, serverless, and static rendering. The plugin’s story is surprisingly cute. Page pull data.
  • Gatsby. Js – Static Rendering with GraphQL Data Layer. Plugins are plentiful. You can push data and pull it in/out of the page.
  • React Static – Static rendering with a simple data layer. You can push data to the page.
  • Create React App – Single page App launcher with no data layer.
  • Ionic React – Over 100 excellent React components with cross-platform targets and React Router built under the hood.
  • Docusaurus – Document-centric static rendering. Lock-in workflow from Markdown to default templates.
  • Storybook-component Library playground for making documents and displaying non-React components.
  • Meteor. Js – a full stack framework that later adopted React.
  • Redwood-tom Preston-Werner’s upcoming full-stack framework includes a back-end GraphQL layer.
  • Blitz.js–Brandon Bayer’s new Rails+React meta-framework.

There are even meta-frames on top of meta-frames.

  • Navi and CURA are James projects that add some routing and SSR capabilities to CRA.
  • Docz – Builds on Gatsby and renders documents statically using default TypeScript and MDX Settings.
  • Expo– a great React Native release that focuses on the developer experience.
  • React Native Web- An RN distribution of the network. See my article on RN singularities
  • React XP – Microsoft’s RN distribution that includes building into Native Windows applications.

Parcel and possibly Rome follow the Collapsing Layers paper by folding meta-frameworks into build tools (rather than having them surround the build tools). Of course, React Native has Metro, a dedicated bundle, and Hermes has its own JS engine.

What other React distributions should there be

However, I agree with James that there should be more React Distros, especially as we start addressing well-defined use cases within the community. He wrote:

But anyway, this is my ideal React distribution. Out of the box SSR simple CSS-in-JS whenever you want. Sane default routing and data fetching/caching, and… You don’t need GraphQL to work like a CRA build, but… Allows Webpack configuration and routing to FS

Except for my preference for Fs-based routing, I mostly agree with 😂.

I think there are a bunch of toggles out there that you can play with while figuring out your own needs, rolling out your React distribution, or using an off-the-shelf one. We covered some of these in our /R /Reactjs status survey.

  • Build Target (Doc static page SPA etc.)
  • State management
  • The data layer
  • styling
  • Support the TypeScript
  • test

Note the lack of Routing due to the de facto dominance of the React Router, while Gatsby, Next. Js, React-static, and Navi also include their own routers due to the need to integrate the data layer. React Native used to have more of a scramble for routing, but now React Navigation seems to be de facto.

I happen to think STAR apps are a well-maintained set of apps. I also particularly like the classNames pairing of tail Wind and React model, which is why I did Rincewind as a basic proof of concept.

In terms of writing formats, I also think we have some way to go. JSX files are almost certainly not the final state of affairs. I did some preliminary testing of the React SFC proposal inspired by Vue, but I think Storybook actually got it right with Component Story Format. I think React SFC looks closer to a standardized ESM file Format. Rather than custom templates (The Formats over Functions papers). Of course, MDX also exists as a content format for React short code, but I think it has the potential to be a full-fledged single-file component format — MDSvex from the Svelte ecosystem is moving in that direction.

The React authoring format will require a dedicated compiler, which becomes especially interesting at a macro level when you design it to address style solutions like Facebook and support Suspense rendering for fetching solutions. But even at the micro level, we often talk about a compiler that is advanced enough that the low-level hooks for React let us do all the template optimizations. I do think we could design more syntax to make this more ergonomic. Of course, if we were going to make a compiler, we could also make an optimized compiler! If we don’t really rely on React’s subtle behavior and event system, then Preact? I bet that sounds a lot easier than it is).

As Tom Dale observed in 2017, compilers are the new framework. But will React go the way of Svelte, Vue, and Angular and break its own runtime? No, it has other concerns.

React release for people who build wheels

Why only App developers can have React Distros? (Don’t people who make wheels deserve names?)

I first met Travis Fischer while exploring creat-React-Library. I also help maintain TSDX, a toolchain for building React + TypeScript libraries, such as Formik. When we are confident that the foundations of the deployment phase have stabilized, we can start building the wheels to help us build the wheels.