Is It Time to Regulate React?  ## Metadata - Author: [[David Bushell]] - Full Title: Is It Time to Regulate React? - Category: #articles - Document Note: --- tags: [React, Web accessibility, Web performance] author: David Bushell source: dbushell.com reference: [https://dbushell.com/2025/10/23/react-regulation/] date created: 2025-10-23 00:00 --- # 🏷️ Title: Is it Time to Regulate React? ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author provocatively argues that React culture fuels “slow, fragile, inaccessible websites,” then clarifies he’s not calling for government regulation but for a professional reset toward web fundamentals. - Why it matters: Performance and accessibility debt from JS-heavy stacks harms users and undermines the web. - Key stakeholders: Web developers, framework maintainers, accessibility bodies, legislators (indirectly). - Risks and tradeoffs: Over-indexing on DX vs. UX; framework lock-in vs. platform literacy; regulation risk vs. self-governance. - Bottom line: “Stop fighting the web.” Learn and use native platform capabilities before reaching for React/meta-frameworks. ## 📖 Main Content - Core arguments: - “The enshittifcation of the web is built with React.” Excess JS leads to bloated bundles, CPU burn, lag, and “div-soup” a11y failures. - React’s DX masks fundamentals: “bypasses the hard parts” of HTML/CSS/JS; confusing APIs + indecisive docs enable errors at scale. - Cultural critique: meta-framework defaults, npm accretion, and AI-driven slopware prolong the problem. - Not literal regulation: Suggests stronger accessibility enforcement and professional norms; asks devs to become “web developers,” not just React developers. - Context/definitions: - DX vs. UX: Developer convenience can degrade user experience when it increases payload/complexity. - A11y framing: Proposes treating poor performance as an accessibility issue under evolving guidelines. - Uncertainties: - How WCAG 3.0 and regional laws will concretely score performance as accessibility. ### 🗒️ Notes - “React is a legacy framework turned cargo cult that promotes inaccessible development.” - “You cannot fix ‘too much JavaScript’ with more JavaScript.” - “React’s failures all too often manifest as div-soup accessibility violations.” - “I’m not actually serious about regulation. Not that kind anyway… Though a JavaScript tax is what we deserve.” - Calls to “learn the platform and embrace what browsers can do.” - Anecdote: Delivers sites without any JS framework despite clients pre-prescribing React. ## 📚 References - Web Content Accessibility Guidelines (WCAG) Overview: https://www.w3.org/WAI/standards-guidelines/wcag/ - WCAG 3.0 (W3C Silver) project: https://www.w3.org/WAI/standards-guidelines/wcag/wcag3/ - European Accessibility Act (EAA): https://digital-strategy.ec.europa.eu/en/policies/european-accessibility-act - Core Web Vitals (Google): https://web.dev/vitals/ - “Learn the Platform” (Jim & Alex): https://learntheplatform.com/ ## 🗣️ Paraphrase - Paragraph A: The web’s bloat and fragility stem from React-first habits that neglect fundamentals, producing inaccessible, error-prone UIs. - Paragraph B: Rather than government regulation, strengthen accessibility enforcement and shift culture toward native browser features and lean builds. ## 📰 Newsletter - React isn’t the villain—our defaults are. This week, a fiery essay argues that framework-first stacks ship “div-soup” and missed a11y basics. Refresh your chops with Learn the Platform, revisit Core Web Vitals, and audit your bundle before your users do. Less DX, more UX. - Resources: Learn the Platform, WCAG 3.0 draft, EAA overview, CWV guides. ## ✅ Action Items #### DevRel - Publish “No-Framework Web” demos: form validation, SPA-like navigation with View Transitions, and server-rendered islands. - Measure and report: before/after CWV and a11y scores; starter repos with budgets and lint rules. - Docs: examples-first patterns for semantic HTML, ARIA only-when-needed, progressive enhancement. - Campaign: “Ship Less JS” with attribution via UTM and conversion goals. - Community: monthly office hours on a11y/perf; code-of-conduct for respectful critique of stack choices. #### OSPO - Governance: contribution policies prioritizing a11y/perf acceptance checks. - Compliance: license scanning + a11y/perf CI gates; quarterly training. - Security: dependency policies, signing, SBOMs for web apps. - Inventory: SBOM freshness SLOs; ownership for front-end bundles. - Engagement: fund upstream a11y tooling; operator agreements on perf budgets. #### Community - Maintainers: release hygiene with size guards; roadmap clinics on reducing client JS. - Contributors: “first issue” a11y/perf audits; pairing sessions. - Sponsors: budget for a11y audits; publish impact reports. - Ecosystem: coordinated disclosure drills for perf regressions. #### WordPress - Core: enforce perf budgets; SSR-first defaults; reduce client hydration. - Core Performance: profiling plans; dashboards; bounty program for largest wins. - Core AI: eval sets for latency and accessibility. - Core Program Team: cross-team rituals to keep budgets green. - Training/Docs: examples-first patterns; pattern library. - Accessibility: WCAG reviews; heatmap of recurring issues. - Meta/Plugins/Themes: provenance checks; scoring transparency; mentorship. #### The WPCC - Programs: maintainer stipends for a11y/perf work. - Projects: documentation sprints and governance clinics. - Funding: matched grants for measurable CWV improvements. ### FAIR - Independence: local provenance and signature checks for builds. - Covenants: anti-capture clauses; sunset heavy dependencies. - Governance artifacts: perf/a11y scorecards and charters. ## 🧪 Hypotheses - Treating poor performance as accessibility will reduce JS bundle sizes by ≥30% within six months. - Examples-first platform training reduces new a11y violations by ≥50%. - Enforcing perf budgets in CI cuts user-visible errors by ≥25%. - Replacing a meta-framework with SSR + islands reduces TTFB+INP by ≥20%. ### 📊 Methodology - A/B org teams: platform-first vs. framework-first; track CWV (LCP, INP, CLS), a11y violations, and error rates. - CI gates: block merges exceeding budgets; log deltas. - Usability tests with assistive tech across devices; task success and time. ### ❓ Questions - How will WCAG 3.0 operationalize performance as accessibility? - What minimal client JS is justified for most content sites? - Can SSR+islands match DX without harming UX? ### 🔮 Future Research - Cost models of DX vs. UX tradeoffs. - Longitudinal studies on bundle growth and user abandonment. - Automation that flags “div-soup” anti-patterns. ### 💡 Implications - Practice: budgets, SSR-first, progressive enhancement. - Policy: a11y regs may implicitly tax performance debt. - Security: fewer deps, smaller attack surface. - Education: fundamentals-first curricula. ### 🧠 Learning Styles Assessment - Reading level: Flesch–Kincaid Grade ≈ 9–10. #### 👀 Visual learners - Improve: add architecture and data-flow diagrams; before/after perf charts. #### 🔊 Aural learners - Improve: 3-minute audio summary. #### 🗣️ Verbal learners - Present: sharp definitions and quotes; add glossary. #### 🧩 Kinesthetic learners - Improve: hands-on labs replacing framework with platform APIs. #### 🧠 Logical learners - Improve: decision trees for choosing SSR/islands/native features. #### 🧑‍🤝‍🧑 Social learners - Improve: moderated Q&A and cohort challenges. #### 🧘‍♀️ Solitary learners - Improve: self-check quizzes and reflection prompts. #### 🌿 Naturalistic learn - Summary: The one where I pen some premium rage bait - URL: https://dbushell.com/2025/10/23/react-regulation/ Regulate?! Sounds like rage bait. I’ll try not to disappoint. It’s right to balk at the idea of government intervention in your sacred tech stack. Legislation from tech-ignorant bloviates? The last resort for an industry that fails to self-regulate. But I dare say React is tempting that fate! The enshittifcation of the web is built with React. What am I talking about? Slow, fragile, inaccessible websites. Too much JavaScript clogging the tubes and burning CPU cycles. Lagtastic and error-prone user interfaces. Why am I blaming React? React is a legacy [framework](https://dbushell.com/2025/02/06/frameworks-vs-libraries/#frameworks) turned cargo cult that promotes inaccessible development. There is nothing more guilty! > “React can be performant and accessible!” > > - Typical React Apologist > > Of course, no true React developer would code it wrong. So why have we witnessed over a decade of React failing the web time and time again? #### Failure I’m not here to [recite all the evidence](https://jsx.lol/). React’s failures are bemoaned ad nauseam. [React’s core failure](https://infrequently.org/2024/11/if-not-react-then-what/#:~:text=Virtual%20DOM%20was%20never%20fast) is compounded by confusing API design for which [documentation](https://react.dev/learn/you-might-not-need-an-effect) is indecisive, [essays](https://overreacted.io/a-complete-guide-to-useeffect/) are written, and correct usage is [endlessly](https://medium.com/@letscodefuture/you-are-using-useeffect-the-wrong-way-please-stop-27b67e627195) [debated](https://tkdodo.eu/blog/the-useless-use-callback). Is it any wonder that [absurd mistakes](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/#what-happened) continue to happen? React exists as a profound perversion of the web platform. React has failed upwards to widespread adoption because it provides a “developer experience” that bypasses the hard parts. Like learning HTML, or CSS, or JavaScript. Even learning React *itself* is discouraged; that’s for adults, you should use [meta-frameworks](https://react.dev/blog/2025/02/14/sunsetting-create-react-app#how-to-migrate-to-a-framework). React devs are burdened with multi-megabyte monstrosities before they’ve written a single line of code. You cannot fix “too much JavaScript” with *more* JavaScript and yet React devs are trained to `npm install` until their problems become their users’ problems. React is no more a *‘web framework’* than React devs are *‘web developers’*. React has spawned a generation void of web fundamentals and woefully ignorant of accessibility. Forget core web vitals, the preferred metric is [time to first error](https://dbushell.com/2025/06/13/your-framework-is-showing-nextjs-error/). The proliferation of [“AI”](https://pivot-to-ai.com) has ensured we’ll suffer steaming piles of React slopware for likely another decade. The new [React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) is a lovely bunch; companies uncomfortably close to [genocide](https://dbushell.com/2025/10/02/not-my-cup-of-tea/) and — let me reach into the *“what the fuck Zuck”* archive — [good lord](https://www.theguardian.com/technology/2025/sep/20/parents-outraged-meta-uses-photos-schoolgirls-ads-man) — [jesus christ](https://www.reuters.com/investigates/special-report/meta-ai-chatbot-guidelines/) — excuse me while I vomit. The absolute worst of *Big Tech*. > “React Compiler and Server Components will fix this!” > > - Someone, somewhere > > #### Regulate I’m not actually serious about regulation. Not *that* kind anyway. Though a JavaScript tax is what we deserve. But it can’t be denied that many in the web industry need an intervention. Please, can we have a little more respect? People have to use the stuff we build. React’s failures all too often manifest as div-soup accessibility violations. Is there room in [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) to denounce an *“overall shitty experience”* from a bloated bundle? [WCAG 3.0](https://www.w3.org/TR/wcag-3.0/) is overhauling the guidelines. Directives like the [European Accessibility Act](https://en.wikipedia.org/wiki/European_Accessibility_Act) give them more teeth. Can poor performance be framed as inaccessible? Regardless, stop fighting the web! Make the choice yourself to move from React developer to web developer. It’s a big leap but worth the effort. Learn the platform and embrace [what browsers can do](https://blog.jim-nielsen.com/2025/more-control-equals-less-performance/) as Jim and Alex say, and as Jeremy asks: [“why *wouldn’t* you do that?”](https://adactio.com/journal/22188) It has never been easier to build a website, stop avoiding it! P.S. yes I do list “React” on my services page. It’s shocking how early React is prescribed for web projects. When I enquire more it’s just “we use React” without technical merit. I have successfully delivered many of those websites without any JavaScript framework., Is It Time to Regulate React?, David Bushell, 01k88d4r6btxm9bgf6nsmgk36d.