This post is the expansion of a lengthy Mastodon thread I posted 0 in response to blog posts from Alex Russell (@slightlyoff)1 and Laurie Voss (@seldo) 2
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 Boilerplate3 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)4. 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 Components5. 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.
| Year | WCs | React | WC Diff |
|---|---|---|---|
| 2013 | 33 | 7 | +371% |
| 2014 | 57 | 54 | +5% |
| 2015 | 28 | 108 | -74% |
| 2016 | 24 | 167 | -86% |
| 2017 | 18 | 142 | -87% |
| 2018 | 19 | 121 | -82% |
| 2019 | 24 | 120 | -80% |
| 2020 | 11 | 157 | -93% |
| 2021 | 15 | 153 | -90% |
| 2022 | 33 | 161 | -80% |
| 2023 | 6 | 17 | -65% |
What do I perceive as being the catalyst for the rise of React? React.js Conf in January of 20156 and also a few months later the release of React Native7. 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 generalization8 (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 component9 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 component9. 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.
| Item | HTMLElement | React | Diff |
|---|---|---|---|
| Lines of Code | 54 | 41 | +32% |
| Web Platform Concepts | 1110 | 811 | +38% |
| Node/Library Concepts | 0 | 612 | -100% |
| Dependencies | 0 | 3 | -100% |
| Minified Size | 1009 | 131515 | -99% |
| 30x Components Size | 30270/0 | 23760/130723 | +27%/-100% |
| 50x Performance | 17.38/19.37 | 34.55/38.11 | -50%/-49% |
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.
Top comments (2)
Glad to see a slew of these style discussions. In my own class we briefly cover R_act as the way people used to work because they had to, and then move onto web components. I think a combination of advocacy, education, and being welcoming to those seeking help can go a long way toward turning the tide over the next decade + that we'll be dealing with Next jQuery.
React isn't the best choice for performance, accessability or even scaling, that is when you have a good team using it. In reality you find that junior programmers are jumping to fill jobs and create components without understanding vital metrics like big O. Developer experience has replaced user experience.
We find that people patch problems rather than fix them. React is the most popular framework so it is the most popular framework - it feels like I am screaming this into the void so thank you for this great article.
Year on year the average size of apps have been growing. React is the most popular framework.... because it is the most popular framework, not because it is good by any metric.
I say it is a touch below average when if it is your business on the line you want to be far and away the best. It has a tangible cost the user as you pointed out.The average speed of devices has increased and there have been a large amount of browser optimisations as javascript packages are replacing understanding HTML, however if you have a bad internet connection and a large payload of badly optimised code nobody is a winner.
There is this feeling that nothing can be more performant than vanilla javascript - what about HTML. As the web continues to scale the paradigm as switched to javascript(or typescript) everywhere. As framework on top of framework come out your title is very poignant.