acemarke

(Replay engineer and Redux OSS maintainer)

Yep. I see it myself, both in other people's code, and our own. The _default_ behavior is a tendency to pile slop on slop, make poor architectural choices, slap bandaids on edge cases without considering the full ramifications, etc. This is more true if there isn't oversight or feedback, and also depending on model quality.

On the flip side: I personally use a strongly human-in-the-loop AI dev workflow [0]. Going back and forth on how much of that code I review myself (and I've found that AI code review frankly does a better job than _I_ do most of the time :) ). But, between staying hands-on, and the ongoing improvements in models, I've seen that the code my own agentic dev sessions produces is actually pretty high quality, and I've been able to clean up a lot of low-quality slop from unmonitored agent sessions. I've also been able to build some pretty major features from scratch and even execute massive migrations with excellent results, again by having me drive the work.

I actually just got done shipping Redux Toolkit 2.14 [1] with a massive set of bug fixes, and almost all of those were found by my agent researching the already-mature RTK codebase, at my direction, and identifying existing logic flaws or weaknesses. Once we knew what those bugs were, we could fix them.

Which, honestly, is the point of the blog post, of Replay QA as an automated testing product, and of Replay as a company in the first place.

Once you know what a bug _is_ and why it happens, fixing it is usually fairly straightforward. _Finding_ it is the hard part.

I've given a conf talk the last few years on "Debugging Software" [2]. One of the main points I make is that no one is _taught_ how to debug - we figure it out on the job as we go, because we have to ship. It's part of the job. But few people like doing it, and most people just want to slap in some console logs and call it a day. Very few people even use existing graphical debuggers (VS Code, Chrome DevTools, etc).

We built a time-travel debugger. The original idea was: make a DVR-style recording of a bug happening once, then you can dive in as deep as you need to investigate. Originally, that was supposed to be a human using the Replay DevTools UI - browser devtools with time travel debugging features built in. It's awesome, I wish I'd had it much earlier in my career :) But we found most people didn't want to spend time doing it themselves.

Earlier this year we shipped Replay MCP, which gives agents the same time-travel debugging capabilities: see hit counts for any line of code, dynamic logpoints and evaluations for every time a line of code ran, see the DOM tree or React component tree at any point in time. I built most of the React analysis features and MCP tools myself, based on my years of experience in the React ecosystem and maintaining Redux.

So, today you _could_ make a Replay recording of your app, point your agent at the MCP, and have it investigate. I've done that, and wrote some blog posts about how that helped my own agent find bugs in React itself and Next.js apps [3] [4]. I've seen my agent nail a bug from a recording on someone else's machine in <10min, starting from scratch.

We've productized that as Replay QA, so that you don't have to do any of the recording or setup - just point Replay QA at your app and repo and we do all the site analysis and recording and bug root cause investigation ourselves. Essentially, encoding our own expertise as debuggers, so you get the benefits [5]

So, back to the original point. Yeah, AI tends to crank out bad code by default, that code is buggy. We can't help your agent choose a better architecture. But we can help identify the bugs proactively, identify the root causes, and suggest solutions, based on the actual runtime behavior of the app. Up to you to get your agents to write _better_ code, but we can give your agent what it needs to fix the bugs it wrote :)

- [0]: https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-2...

- [1]: https://github.com/reduxjs/redux-toolkit/releases/tag/v2.14....

- [2]: https://blog.isquaredsoftware.com/2023/06/presentations-debu...

- [3]: https://replay.io/blog/replay-time-travelogue-how-replay-mcp...

- [4]: https://replay.io/blog/replay-time-travelogue-improving-nadi...

- [5]: https://replay.io/blog/mark-erikson-on-replay-qa-from-time-t...

Wrote up my approach recently in a blog post:

- 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...

I've tried a few. Currently settled on `grepika` and `tilth`. They're not quite as comprehensive as I imagine I would want this kind of tool to be, but my agent has been able to use them very effectively and I've seen context usage drop considerably:

https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-2...

Hi! I played a major part in getting that "installation" page rewritten to actually mention other tools like Vite :)

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.

Yup. I'm the primary Redux maintainer and creator of Redux Toolkit.

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.

Hi, I'm the primary Redux maintainer. I'd love to see some examples of what got generated! (Doubt there's anything we could do to _influence_ this, but curious what happened here.)

FWIW we do have our docs on testing approaches here, and have recommended a more integrated-style approach to testing for a while:

- https://redux.js.org/usage/writing-tests

I haven't looked specifically at Webpack's development lately, but having seen the overall activity and competition in the bundling ecosystem: no, a 6.x release seems unlikely, and also pretty irrelevant at this point. And no, I don't see Webpack becoming a default choice again.

- 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.

I used WinDirStat for years, but WizTree is _much_ better. It reads directly from the file system metadata tables instead of having to scan the whole filesystem, so the file tree loads much faster. No need to wait for all those pacmen munching their way through the whole disk :)

Completely unrelated.

- 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've never seen this kind of benchmark graph before, and it looks really neat! How was this generated? What tool was used for the benchmarks?

(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!)

Like I said above and in the post: it was an attempt to generalize the data fetching patterns developed inside of Meta and make them available to all React devs.

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:

- https://overreacted.io

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.

No, but it's primarily because Meta has their own server infrastructure already. RSCs are essentially the React team trying to generalize the data fetching patterns from Meta's infrastructure into React itself so they can be used more broadly.

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...

We actually built a full-blown time travel debugger for Javascript at Replay.io:

- https://www.replay.io/devtools

Don't think Archive links work on Substack or other similar sites like Ed's, and this link stops at the paywall cutoff (ie just the free content portion).

Hi. I'm the current Redux maintainer, and have been since Dan handed it over to me in mid-2016, one year after he created Redux. It's also worth noting that Dan never used Redux on a real app (that I know of), whereas I've spent years maintaining Redux and Redux Toolkit and designing APIs based on the needs of our users.

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-...

Because that's the responsibility we've placed on ourselves :)

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:

- https://bsky.app/profile/acemarke.dev/post/3m6defzgvcl2n

What "naming conventions and file structures" are you referring to? I don't think Dan ever really popularized anything like that for _React_.

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...

That's one of the main theses of the book "Die with Zero":

- 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).

React's bundling system and published packages has gotten noticeably more complicated over time.

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/react-dom@18.3.1/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/react-dom@19.2.0/files/cjs/react-dom.d...

- https://app.unpkg.com/react-dom@19.2.0/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)

Correct - Elm was one of several inspirations for Redux:

- https://redux.js.org/understanding/history-and-design/prior-...

Hi! I maintain Redux and am deeply involved in the React community, and have spent a lot of time both critiquing the React team's decisions and explaining their decisions to the community.

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...

I recently used https://github.com/okibcn/wslcompact to shrink a couple of WSL VHDX files, and it worked great.

Looking at the source, it seems to use a `wsl --export` option rather than `diskpart`.

I'm the primary Redux maintainer. FWIW, `connect` still exists and we have no plans to remove it, but it's also _very_ complicated internally and we honestly don't want people using it today. If I _could_ remove it without breaking user apps I would. `useSelector` is a drastically simpler implementation, better app performance, and smaller bundle size.

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...

It's ironic you say that - I wrote the post, and I _maintain_ Redux :)

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.

React's actual implementation is in the reconciler logic, which is then built into the platform-specific packages like ReactDOM and React Native.

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`.

Sounds like another one of Dan's talks, "React from Another Dimension", where he imagines a world in which server-side React came first and then extracted client functionality:

- https://www.youtube.com/watch?v=zMf_xeGPn6s

What kind of "updates"? Library versions? Code changes? What kind of types are you having to change?

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.

FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created.

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...

You can see exactly what the React compiler output is by pasting the listed code into the compiler playground:

- 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.

I got to watch Dimitri posting internal updates about his progress on this, and it has been utterly mindblowing. This is genuinely one of the most amazing things I've ever seen done with code. Absolutely legendary feat! (And also an incredible amount of persistence.)