The Emperor's New Library

This post is the expansion of a lengthy Mastodon thread I posted ⁰ in response to blog posts from Alex Russell (@slightlyoff)¹ and Laurie Voss (@seldo) ²

delete you.React;

Many promises and flashy demos have been made over the course of the prior decade using React. There is no denying that adoption of React is widespread. What is concerning is the bait-and-switch technique of promotion that React engenders where conference speakers, tutorial makers, or bootcamp instructors flaunt bells-and-whistles that are ill-suited to production. Confirmation bias, due to the popularity of React, has blinded people to the reality that React should not be the foundational basis for hiring developers, starting new projects, nor performing frontend training and bootcamps. The reality is that developers and companies can remove React from their tooling and be better off for it.

A Decade Apart

Alex speaks a lot about the last decade, and when I look back, his claims resonate a lot with my experience. I can look at things happening in February 2013, and it makes me think he may have even been a little too kind limiting it to a decade. Issue #76 of "HTML5 Weekly" from @cooper had a great (at the time) link to a Simple Frontend Boilerplate³ useful as a historical record of the apps at the time.

What we see, a decade ago, are that many of the "popular" libraries, frameworks, and methods, not surprisingly, have gone by the wayside, a lot that have remained in current code as difficult-to-removemodernize legacy cruft (Bower, Gulp, Grunt, Backbone, Angular 1, ...), and then we have the small minority that are still here. Some that remain have had their utility lessened/questioned by platform and language improvements (jQuery, lodash, ...), but very, very few exist that are the same now as they were then. Another fun historical reference: issue #118 of "JavaScript Weekly" (February 22, 2013) includes a first link out to asm.js.

People were even "predicting" the rise of Single Page Apps (SPAs)⁴. Given the broader historical context, my personal experience was taking over leadership of a Google Developer Group in 2013. So I was knee-deep in what Google was promoting for the open web (with an emphasis on mobile web performance): WebP, WebM, and the first look at Web Components⁵. Web components transformed and reignited my passion for the web platform.

The Rise of React

What followed in the years after, however, was a marketing blitz of React promotion. I know this quantitatively, by looking at my relatively neutral web development newsletter subscription emails (general web dev topics) and comparing "React" (the library) versus "Web Component(s)" occurrences (example: after:2012/12/31 before:2013/12/31).

Email Newsletter Subscription Mentions

Columns: the year searched, the number of emails received mentioning Web Components (WCs) or React (R), and the percent difference between Web Component emails and React emails.

What do I perceive as being the catalyst for the rise of React? React.js Conf in January of 2015⁶ and also a few months later the release of React Native⁷. The first gave validation to the ability to run, or speak at, a conference with React topics, and the second gave developers a way to do "native" mobile development in a way much smoother than offerings available at the time. Thus began in earnest, in my view, "The Shill Wars". This is also when I started to notice that it had become more and more passe to discuss things other than React in my dev circles. Even significant platform updates fell by the wayside or went relatively unnoticed or unacknowledged.

A Tale of Two Blogs

My experience and subjective observation affirms every point in Alex's post. Unfortunately, that means that there were/are individuals, real people, ignorantly or intentionally continuing to regurgitate the same 'ol framework and library narratives with zeal. What has always been lacking, is accountability for the "complexity merchants". Instead of mea culpa, they went full Order 66 on the Web Platform Jedi when confronted with the less savory realities of their libraries or frameworks.

I came into Laurie's post with an open mind and relatively few expectations, but making a hasty generalization⁸ (intentionally or implicitly due to the proximity of the two statements) that of the "tens of millions" of software developers, a majority (71%) use React. I felt unseen, and the claim tripped me up, and misrepresented the 9.993 million other devs out there that may or may not use or know React.

There is Always Money in the React Stand

This is not new ground we're treading. This is the same type of result we've seen year after year from the "State of JS" surveys. The network effect within the web development world reached a critical mass in favor of React in 2015, and due to the ever-present ability to make money off of training, conferences, media, and ephemera within the industry we've reached the point where confirmation bias runs so rampant that nobody is willing to accept that the Emperor's new library is not a net good for developers, for users, or for the web. There is a growing number of people who are trying to help those too afraid to appear inept or stupid to realize they have been duped (or so the folktale goes).

Money, and the assessment of costs, is something I think Laurie also gets horribly wrong. Let's take a look at the February 2022 update to all the ways to make a web component⁹ to do some calculations and blow up the mainstream React narrative some more.

Developer, Storage, Performance Costs

Legend: Items are based off of implementations or data from the ways to make a web component⁹. Minified size, 30x (30 components), 50x (50 components). Comparison is between the HTMLElement implementation and the React with Hooks implementation. Diff is the percentage difference between the React and HTMLElement item.

The truth is, React costs more in every way, it necessarily has to, because it is built off of the platform that natively runs web components. React also can't scale well, because it always carries around the specter of larger dependency overhead.

Developers have to learn more to be productive with React, they have to manage more dependencies with React, the bandwidth used is higher, the performance is slower. If you strip portability and compatibility from the equation you may see gains with going with an all-React ecosystem, but then reuse and compatibility necessitate using React despite whether it is the best tool for the job. I've also seen this break down just between different versions of React being incompatible (with React or even vanilla JS; see import.meta issues), which is not something you get with native platform code.

Yet, React proponents always seem to start with big claims but then are never held to account by the community when they are forced to backtrack on those claims. In some cases, there are attempts to distract with some new shiny claim that reposition the old claim either as wrong or more likely "less right" (looking at you create-react-app).

The biggest fallacious claim of the framework and library zealots is this statement from Laurie: "We want an open, accessible, world wide web." What part of a library of choice actively working against existing W3C web standards and resisting acceptance of PRs to help devs trying to use those standards with your library seems open and accessible?

The solution is NOT more frameworks, the solution is what Alex, myself, and many others have been advocating all along: use the platform. If it doesn't do what you want, make proposals, participate in the standards process via working groups or other open communities.

"Your path you must decide" - Yoda

Good news! You can start adding things like web components to your existing apps without a complete rewrite or much concern for compatibility or build process. Easing into web components can be as simple as adding a custom element (no Shadow DOM) to handle string formatting.

We started with a date/time formatter to solve an issue we had with search results not matching a user's locale date formatting when they searched for things between specific dates. We grew from there to make an entire search page made with vanilla web components (no libraries, no frameworks, no dependencies; including Shadow DOM): https://developers.redhat.com/search?t=openshift

You can take small steps to end the naked parade of unchecked power that React has enjoyed for a decade just by leveraging the standards that the platform already provides more often, and telling others about your experience with them.

[0] - https://w3c.social/@lukedary/109851919543348747
[1] - "The Market for Lemons" - Alex Russell - https://infrequently.org/2023/02/the-market-for-lemons/
[2] - "The Case for Frameworks" - Laurie Voss - https://seldo.com/posts/the_case_for_frameworks
[3] - "Simple Frontent Boilerplate" - Cody Lindley - https://github.com/codylindley/simple-frontend-boilerplate
[4] - "HTML5: 10 Provocative Predictions For The Future" - Todd Anglin - https://readwrite.com/html5-10-provocative-predictions-for-the-future/
[5] - "Web Components: A Tectonic Shift for Web Development - Google I/O 2013" - Eric Bidelman - https://www.youtube.com/watch?v=fqULJBBEVQE
[6] - "React.js Conf Round-up 2015" - Steven Luscher - https://reactjs.org/blog/2015/02/18/react-conf-roundup-2015.html
[7] - "Introducing React Native" - Sophie Alpert - https://reactjs.org/blog/2015/03/26/introducing-react-native.html
[8] - "What Is the Hasty Generalization Fallacy?" - Lindsay Kramer - https://www.grammarly.com/blog/hasty-generalization-fallacy/
[9] - "All the Ways to Make a Web Component - Feb 2022 Update" - Many Authors - https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/
[10] - HTML, CSS, JS - Variables, DOM, Template Strings, Classes, Custom Element Lifecycle Callbacks, Shadow DOM, Events, Custom Elements Registry
[11] - HTML, CSS, JS - modules, variables, functions, Destructuring, Template Strings, Custom Elements Registry
[12] - JSX, Node modules, React, useState, ReactDOM, reactToWebComponent

I want to express my utmost gratitude to Alex, Benny, and Steven for giving my drafts of this post some much needed feedback and direction.