# frameworkism

Published articles for frameworkism.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Why "state management" is a misleading term in React

DevFeed: [Why "state management" is a misleading term in React](<https://devfeed.tech/articles/the-absolute-state-of-management-26566.md>)

Original publisher: [Read original article](<https://infrequently.org/2026/07/state-management/>)

Author: Alex Russell

Published: 2026-07-23T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>)

Tags: [alternatives](<https://devfeed.tech/tags/alternatives.md>), [frameworkism](<https://devfeed.tech/tags/frameworkism.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [library](<https://devfeed.tech/tags/library.md>), [react](<https://devfeed.tech/tags/react.md>), [redux](<https://devfeed.tech/tags/redux.md>), [state-management](<https://devfeed.tech/tags/state-management.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

### AI overview

This opinion article argues that "state management" is an imprecise label for React and the surrounding ecosystem. It surveys libraries including Redux, Zustand, Apollo, and others, and contends that they primarily encapsulate state or propagate notifications about state changes rather than manage state themselves.

### Source excerpt

It is by no means the gravest linguistic crime of the React epoch,1 but "state management" grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this: me: This UI is far too heavyweight for what it does, have you considered not using React? them: But how will we do state management without React? me: What do you mean? <alternatives> are reactive. them: React manages state in our app. me: It does? Then what are <various_libraries> for? them: Oh, those manage state. me: The libraries that trigger this "Who's on First?" routine include: MobX, which promises "simple, scalable state management." Satchel, apparently, "is characterized by exposing an observable state that makes view updates painless and efficient" Recoil, billed as "a state management library for React" Jotai, which pledges "primitive and flexible state management for React" XState, a "state management and orchestration solution for JavaScript and TypeScript apps" Apollo, promising "a comprehensive GraphQL state management library for JavaScript" Redux, tagline: "a predictable state container for JavaScript apps." TanStack Store, "a framework-agnostic state primitive for immutable updates" Zustand, described as the "🐻 bear necessities for state management in React" Contrasts sharp enough to cut softened butter.2 Suffice it to say, the ecosystem has not picked a winner. Indeed, I regularly see several of these libraries on a single page. But even one would seem too many, given that we're adding a second "state management" system to a framework that spills considerable documentation ink chest-beating about its state management facilities. One of the following must be true: React is a state management system and someone has smuggled in a duplicative dependency we can jettison. React is an inadequate state management system and we should stop trusting it with an ill-defined subset of the "state management" problem. React is not a state management system and we should s

## Why the author argues new web projects should avoid React

DevFeed: [Why the author argues new web projects should avoid React](<https://devfeed.tech/articles/if-not-react-then-what-26549.md>)

Original publisher: [Read original article](<https://infrequently.org/2024/11/if-not-react-then-what/>)

Author: Alex Russell

Published: 2024-11-29T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [Framework](<https://devfeed.tech/topics/framework.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [legacy](<https://devfeed.tech/topics/legacy.md>), [CSS](<https://devfeed.tech/topics/css.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [css](<https://devfeed.tech/tags/css.md>), [development](<https://devfeed.tech/tags/development.md>), [frameworkism](<https://devfeed.tech/tags/frameworkism.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [html](<https://devfeed.tech/tags/html.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [legacy](<https://devfeed.tech/tags/legacy.md>), [performance](<https://devfeed.tech/tags/performance.md>), [react](<https://devfeed.tech/tags/react.md>), [web](<https://devfeed.tech/tags/web.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

### AI overview

The article argues that React and other modern frontend frameworks can create performance and accessibility problems, especially in new web applications. It recommends minimizing client-side complexity and favoring HTML and CSS over JavaScript where practical.

### Source excerpt

Over the past decade, my work has centred on partnering with teams to build ambitious products for the web across both desktop and mobile. This has provided a ring-side seat to a sweeping variety of teams, products, and technology stacks across more than 100 engagements. While I'd like to be spending most of this time working through improvements to web APIs, the majority of time spent with partners goes to remediating performance and accessibility issues caused by "modern" frontend frameworks and the culture surrounding them. Today, these issues are most pronounced in React-based stacks. This is disquieting because React is legacy technology, but it continues to appear in greenfield applications. Surprisingly, some continue to insist that React is "modern." Perhaps we can square the circle if we understand "modern" to apply to React in the way it applies to art. Neither demonstrate contemporary design and construction. They are not built for current needs and do not meet contemporary performance standards, but pose as expensive objets harkening back to an earlier era's antiquated methods. Contents The Rule Of Least Client-Side Complexity OK, But What, Then? And Nothing Of Value Was Lost Vignettes Informational E-Commerce Media Social Productivity Other Application Classes "But..." "...we need to move fast" "...it works for Facebook" "...our teams already know React" "...we need to be able to hire easily" "...everyone has fast phones now" "...React is industry-standard" "...the ecosystem..." "...Next.js can be fast (enough)" "...React Native!" References In the hope of steering the next team away from the rocks, I've found myself penning advocacy pieces and research into the state of play, as well as giving talks to alert managers and developers of the dangers of today's frontend orthodoxy. In short, nobody should start a new project in the 2020s based on React. Full stop.1 The Rule Of Least Client-Side Complexity Code that runs on the server can be fully costed. Pe