acemarke
Joined 17 years ago
Karma
6,044
Submissions
1,994
Member since
Dec 21
Recent submissions
Comment · 5 months ago
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...
Comment · 5 months ago
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...
Comment · 7 months ago
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.
Comment · 8 months ago
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.
Comment · 9 months ago
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:
Comment · 10 months ago
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.
Comment · 10 months ago
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 :)
Comment · 10 months ago
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.)
Comment · 10 months ago
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!)
Comment · 10 months ago
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:
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.
Comment · 10 months ago
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...
Comment · 10 months ago
We actually built a full-blown time travel debugger for Javascript at Replay.io:
Comment · 11 months ago
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).
Comment · 11 months ago
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-...
Comment · 11 months ago
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:
I blog about mostly React+Redux stuff at http://blog.isquaredsoftware.com/ , and tweet at @acemarke .