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:
Unfortunately I think I cleaned up the code before committing it, so I don't have an exact example! I did actually read that usage page though after looking at those tests, and that helped me in fixing the tests (maybe in retrospect I should have pointed the AI at the docs page first).
I think the main issue I was having with it was reusing the store object instead of creating a new one for each test. The other issue I was seeing was that it was creating mock objects and API's for things that weren't even being tested (lot of scope creep), and one of those API's was basically copy-pasted between two files (code duplication). It was also just testing things that weren't really necessary (ie, testing Redux itself, instead of my usage of it).
Another issue was just taking a complex approach to fixing something that could be more easily solved. For instance, I had debug: true turned on for redux-undo so I was seeing some unnecessary log messages in the test. Codex identified this, and asked if I wanted to disable them, so I said yes. What it did though, was instead of setting debug: false, or disabling it on tests, it patched console.log to look for redux-undo prefixes. Technically worked, but kind of byzantine!
None of this was a terrible disaster or anything, especially since I started pretty small, but I think what made me miss some of the issues at first glance is this is my first usage of Redux in a non-toy project so while I understand the fundamentals fine, it was easy to sneak working-but-bad stuff past me until I sat down with the code to write a test on my own and started to see the issues.
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
My worry isn't so much about the tech itself, but rather the governance issues—and it's not about "Make Webpack Great Again."
1. I genuinely like Vite's design and UX (I actually started my frontend career with Vite + Vue). My only concern is the ecosystem getting vertically integrated under a single commercial roadmap (Oxc => Rolldown => Vite). It feels like shifting from a community-driven ecosystem to a VC-driven product suite. I am worried about vendor lock-in, especially with commercial suites like "Vite+" existing.
2. Regarding Rspack/Rsbuild, I do treat them as one of the Webpack alternatives. Although ByteDance doesn't rely directly on build tools for profit like Vercel or VoidZero, and Rspack/Rsbuild reuses community results, I feel the vendor lock-in risk isn't that high. But Rspack/Rsbuild's current volume isn't huge -it's obviously much smaller compared to Webpack/Vite. So I think I might need to wait and see.
3. I previously valued Webpack 6.x mainly because of the governance structure. Like Node.js, it belongs to the OpenJS Foundation after all. I guess I feel that for such critical infrastructure, neutrality is quite important. When choosing tech for frontend projects, I also focus heavily on community governance. The only regret is that it's a bit old and has performance issues. So, I was kind of hoping it could solve some of its downsides.
I'd love to hear your thoughts on what I said above. Also, I am curious about your take on the current shift in the JS ecosystem. I think in the current JS ecosystem, commercial companies are increasingly dominating core infrastructure *directly*, and using that infrastructure as a core part of their business plans. Objectively speaking, this leaves *less and less room for neutral, community-driven governance*.
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 :)
- 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!)
It's in essence a histogram for the distribution, with smoothing, and mirrored on each side.
It looks nice, but is not without well-deserved opposition because 1) the use of smoothing can hide the actual distribution, 2) mirroring contains no extra information, while taking up space, and implying the extra space contains information, and 3) when shown vertically, too often causes people to exclaim it looks like a vulva.
Sure. Very few distributions have lovely square edges, which otherwise indicate some very high frequencies in the distribution, or quantized values.
But that also means we are used to seeing histograms and their bin count and widths in order to estimate possible variances from the true distribution;.
While it's much harder to do the same with violin plots.
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:
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.
Yeah the "just" is doing a lot of things, nobody asked for a react server but it turns out it could be the base for a $10B cloud company. Classical open source rugpull.
Replay is really impressive - having a record/replay runtime that can capture all the inputs to the JS engine and reproduce execution deterministically is in a completely different category from what CDP exposes. That’s what enables true time-travel debugging.
Wirebrowser sits at the other end of the spectrum: it attaches to any unmodified browser that supports CDP and works directly with the live runtime. The workflows end up being very different, but it’s fascinating to see what becomes possible when the runtime itself participates in the recording.
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:
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:
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:
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:
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
reply