acemarke
- https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-2...
TLDR:
OpenCode + CodeNomad web UI, Opus 4.6, bunch of customized plugins and some codebase indexing MCPs, a separate `dev-plans` repo for generated project docs and artifacts, and a personal workflow where I stay very hands-on directing the work.
also I wrote a lengthy post detailing my emotional and mental journey from "I will _never_ use AI to write code" to actively using it, as well as my opinions on where we stand now and whether this is actually any good or not:
- https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1...
https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-2...
The general TLDR is:
- CRA was listed in the _old_ docs site
- The new docs site coincided with the React team emphasizing "frameworks" to provide an all-in-one build experience and hopefully lead to better apps.
- That also meant no ala-carte build tools were listed. This made many people (including me) unhappy.
- CRA broke when React 19 came out in Dec 2024. This caused problems for beginners.
- I pushed the React team to both deprecate CRA and finally rewrite the setup pages to list other build tools as valid options.
I wrote up a much longer background of what happened around the "frameworks" push and this docs page here:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
And here's the issue I filed pushing the React team to deprecate CRA (after some online discussion):
- https://github.com/facebook/create-react-app/issues/17004
and a follow-up PR where I tried to rewrite the initial rather confusing post-CRA-deprecation "Creating Your Own Framework" page with a more relevant "Creating a React App" page:
- https://github.com/reactjs/react.dev/pull/7618
but the overall point of _all_ of this is that CRA was unmaintained as of 2023, the community had _already_ moved on to Vite, and all this was an attempt to get the React docs to reflect that reality.
If you look at a typical Zustand store vs an RTK slice, the lines of code _ought_ to be pretty similar. And I've talked to plenty of folks who said "we essentially rebuilt RTK because Zustand didn't have enough built in, we probably should have just chosen RTK in the first place".
But yeah, the very justified reputation for "boilerplate" early on stuck around. And even though RTK has been the default approach we teach for more than half of Redux's life (Redux released 2015, RTK fall 2019, taught as default since early 2020), that's the way a lot of people still assume it is.
It's definitely kinda frustrating, but at the same time: we were never in this for "market share", and there's _many_ other excellent tools out there that overlap in use cases. Our goal is just to make a solid and polished toolset for building apps and document it thoroughly, so that if people _do_ choose to use Redux it works well for them.
FWIW we do have our docs on testing approaches here, and have recommended a more integrated-style approach to testing for a while:
- Vite has become the default for most SPAs
- Vite is now backed by the VoidZero company, which is moving full speed ahead on a suite of Rust-based build tooling: Rolldown for bundling, Oxc for parsing, etc
- Meanwhile, you've got Bytedance cranking out RSPack and RSBuild
and at least another half-dozen alternatives.
- Immer (C++) appears to be roughly equivalent to Immutable.js ( https://immutable-js.com/ ): a set of specialized data structures
- Immer (JS), on the other hand, uses JS Proxies to wrap plain values, traps attempted mutations, and then replays them to return a safely immutable updated final result
As far as I know, Michel Weststrate came up with the name independently (although I can't 100% confirm that).
(source: I didn't create Immer (JS), but I started using it in Redux Toolkit in 2018, am quoted in the docs about how much I love it, spent the last couple months doing performance optimization work that got shipped in Immer 11.x, and just put up some more bugfix PRs today. I'm a secondary maintainer at this point.)
(I actually spent most of Sep/Oct working on optimizing the Immer JS immutable update library, and used a benchmarking tool called `mitata`, so I was doing a lot of this same kind of work: https://github.com/immerjs/immer/pull/1183 . Would love to add some new tools to my repertoire here!)
If you watch the various talks and articles done by the React team for the last 8 years, the general themes are around trying to improve page loading and data fetching experience.
Former React team member Dan Abramov did a whole series of posts earlier this year with differently-focused explanations of how to grok RSCs: "customizable Backend for Frontend", "avoiding unnecessary roundtrips", etc:
Conceptually, the one-liner Dan came up with that I liked is "extending React's component model to the server". It's still parent components passing props to child components, "just" spread across multiple computers.
I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-external perspective:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
- https://blog.isquaredsoftware.com/2025/06/presentations-reac...
Redux is still by far the most widely-used state management library in React apps. Some of that _is_ legacy usage, sure. But, our modern Redux Toolkit package has ~30M downloads a month. Zustand has become very popular as a client-side state option, and React Query is now the default standard data fetching tool, but you can see that even just RTK is still right up there in monthly NPM downloads:
- https://npm-stat.com/charts.html?package=redux&package=%40re...
I've frequently talked about the original reasons for Redux's creation, which of those are still relevant, and why Redux is still a very valid option to choose even for greenfield projects today:
- https://blog.isquaredsoftware.com/2024/07/presentations-why-...
I actually did a recent conference talk called "Maintaining a Library and a Community" where I discussed how being an OSS maintainer is really about communicating with your users and contributors, more than it is about writing code yourself. And yes, a big part of that is responding to issues _and_ reviewing externally-contributed PRs:
- https://blog.isquaredsoftware.com/2024/11/presentations-main...
I also even just tweeted over the weekend about how a user filed a PR to add a good new option to one of my libraries, but I still had to take time to review it, figure out what additional functionality should be added, then add tests and docs:
If you're thinking of _Redux_, are you referring to the early conventions of "folder-by-type" file structures? ie `actions/todos.js`, `reducers/todos.js`, `constants/todos.js`? If so, there's perfectly understandable reasons why we ended up there:
- as programmers we try to "keep code of different kinds in different files", so you'd separate action creator definitions from reducer logic
- but we want to have consistency and avoid accidental typos, especially in untyped plain JS, so you'd extract the string constants like `const ADD_TODO = "ADD_TODO"` into their own file for reuse in both places
To be clear that was never a requirement for using Redux, although the docs did show that pattern. We eventually concluded that the "folder-by-feature" approach was better:
- https://redux.js.org/style-guide/#structure-files-as-feature...
and in fact the original "Redux Ducks" approach for single-file logic was created by the community just a couple months after Redux was created:
- https://github.com/erikras/ducks-modular-redux
which is what we later turned into "Redux slices", a single file with a `createSlice` call that has your reducer logic and generates the action creators for you:
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
- https://www.diewithzerobook.com/welcome
Read it earlier this year and it definitely changed some of my thinking along those same lines.
My loose summary of the book:
"Any money left in the bank when you die is essentially wasted - you could have used it to have experiences when you were alive, or given it to family / charity earlier when it would have had more benefit. Figure out what major experiences and memories you want to have in life, plan to do them earlier when you have health and time, and build up memories for later in life."
I didn't find the discussions of how to plan out retirement savings very useful - there's a lot better info on withdrawal approaches in various FIRE-related groups.
But the "be willing to spend now on activities you might not be able to do later / don't hold off on 'living' until you're retired" argument made a _lot_ of sense to me for a variety of reasons, and it was a major factor in researching early retirement a few months later (and deciding to make that a new goal. along with taking more vacations before then).
First, there's the separation between the generic cross-platform `react` package, and the platform-specific reconcilers like `react-dom` and `react-native. All the actual "React" logic is built into the reconciler packages (ie, each contains a complete copy of the actual `react-reconciler` package + all the platform-specific handling). So, bundle size has to measure both `react` and `react-dom` together.
Then, the contents of `react-dom` have changed over time. In React 18 they shifted the main entry point to be `react-dom/client`, which then ends up importing the right dev/prod artifacts (with `react-dom` still supported but deprecated):
- https://app.unpkg.com/[email protected]/files/cjs
Then, in React 19, they restructured it further so that `react-dom` really only has a few utils, and all the logic is truly in the `react-dom/client` entry point:
- https://app.unpkg.com/[email protected]/files/cjs/react-dom.d...
- https://app.unpkg.com/[email protected]/files/cjs/react-dom-c...
So yes, the full prod bundle size is something like 60K min+gz, but it takes some work to see that. I don't think Bundlephobia handles it right at all - it's just automatically reading the main entry points for each package (and thus doesn't import `react-dom/client`. You can specify that with BundleJS though:
- https://bundlejs.com/?q=react%2Creact-dom%2Fclient&treeshake...
> Bundle size is 193 kB -> 60.2 kB (gzip)
- https://redux.js.org/understanding/history-and-design/prior-...
I actually wrote exactly that blog post and did a conf talk on it earlier this year. I covered why the React team switched to directing users to use "frameworks" to build React apps, the development influences behind React Server Components, why the React docs didn't list tools like Vite as viable options until just a couple months ago, and various other related topics:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
- https://blog.isquaredsoftware.com/2025/06/presentations-reac...
Looking at the source, it seems to use a `wsl --export` option rather than `diskpart`.
I do get what you mean about the conceptual separation, although something about the HOC approach also led to a lot of historical user confusion about "where _are_ my props coming from?".
As for writing the rest of your Redux logic, our modern Redux Toolkit package has addressed the historical concerns about boilerplate and other pain points:
- https://redux.js.org/introduction/why-rtk-is-redux-today
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
FWIW, I can confirm that hooks have _not_ "eradicated Redux" - it's still the most widely used client side state management lib in React apps. It's definitely as common as it used to be, since the ecosystem has evolved significantly, but both download stats and discussions with devs tell me it's still in very widespread use.
So, the `react` core package is tiny because it just has a few small common methods and shims for the hooks, and all of the actual logic and bundle size are in `react-dom`.
Yes, managing types does take more work up front than _not_ having types... but the overall result should be that you benefit from them significantly by having fewer runtime bugs, and an easier time maintaining and understanding the code.
Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS.
See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation:
- https://redux.js.org/understanding/history-and-design/histor...
- https://redux.js.org/understanding/history-and-design/prior-...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJY...
In this case, it looks like the compiler has hoisted the console logs from the `useMemo` calls out into the main body of the function component, because it considers those to be side effects. So, the logs are still occurring. However, the actual child component output _is_ being memoized as expected.