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:
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.
Mainly just when adding new features. For example, updating a trpc endpoint to return an additional field often requires updating other unrelated prisma queries just to satisfy the return types.
I get types are necessary, it just seems to me that they should only ever be defined once and in one place rather than defining any type you need anywhere you need it.
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:
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.)
- The React team finally took action to fix the CRA breakage, then wrote the blog post, updated the setup docs page, and redid the docs SEO to get Google to stop showing the legacy docs as a search result.
So, kudos to the React team for making meaningful changes here!
(It's not _exactly_ what I was hoping for, and I gave them some additional review feedback that they didn't include, but gotta give credit for the actual changes and steps forward!)
They are still going out of their way to not say Vite or similar SPA tooling is a completely viable path for a lot of projects. SEO is not critical for all projects like they make you think it is. I’m pretty disappointed by the direction they took in this post.
I was given word back in 2019 while I was working on CRA that the React team was cozying up to the Next team and was going to be pushing Next as the future of React. That never sat well with me and I stopped contributing the following year.
This post took way too long to be sent to the community, but I’m glad they finally did something. It’s been dead for years.
- At least _mentioning_ Vite directly on the "Create a Project" page _is_ genuinely a step in the right direction. That said, they're going out of their way to still not just directly say "creating a basic SPA with Vite is a valid option for using React", and at this point it just looks pretty ridiculous. (Someone pointed out that the Svelte docs start with "Use SvelteKit"... and then the very next thing is "or add Svelte to a basic Vite project with this template". That's what's needed here.)
- I get the _intent_ of the "Build Your Own Framework" phrasing (ie, "choosing to self-install a router, data fetching lib, etc, results in a poor self-created framework"). That said, the "BYOF" page is the opposite of what's needed. It needs to be concrete steps to guide beginners into setting up an app with Vite or Parcel and recommending specific tools to add and techniques to use. Instead, it's "Step 1: Install Vite or Parcel"... and then multiple sections of "Look how hard routing, data fetching, and rendering are, you'll _never_ get this right yourself, use an existing framework instead, DON'T DO IT YOURSELF!". The content would be great if it was on a page titled "Web App Perf Basics", or "Framework Capabilities". But given that this is linked from the "Create" page with the hint of "follow steps here to get going DIY", this is the wrong content entirely.
- Similarly, the repeated use of "framework" to mean "a pre-existing thing someone else built" vs "a set of libs you added yourself" is confusing. Along with that, the overall tone generally comes across as "we don't want to acknowledge the breadth of ways that people use React in practice, and we're going to keep repeating the word 'framework' because we don't trust users to know how to make decisions themselves and we know what's best for you".
- I understand why they tried to emphasize "Next/RR/Expo can all export plain SPAs with no server needed!". That knowledge is genuinely not widespread. But, I don't think a bright green callout with that info should be the _first_ thing on the "Create a Project" page. _Somewhere_ on the page, sure, but it's not the most critical thing to show right away.
So, actual genuine improvement... and yet still kinda frustrating to read and see the phrasing and messaging so far off from what it _ought_ to be.
The React team really does not like SPAs, which I think is a bit of a shame. I'm not a big fan of the mish-mash approach of client and server components that Next et al now encourage.
For the type of app that React excels at, or at least the type I like to build, the performance issues with a SPA aren't a big deal.
The hybrid server render, then hydration step is too magical for my liking. There's a bunch going on in there that would be very difficult to debug, if some mysterious error at this stage of the app were to present itself. I prefer either wholly SPA or serverside, can debug and understand the whole thing.
This perfectly captures my thoughts about the situation.
I don't know why they're so resistant to do treat SPAs as a completely valid way to use React in 2025. The majority of devs still use React primarily as a SPA. Recent State of React has it at 85% for SPA and 63% for SSR (1). Probably they know their answer is unpopular and thus we get a lot of deflection and phrases like "you should only consider a SPA if you have unusual constraints" whatever that's suppose to mean.
I've said it before, but changes don't happen when random devs like me complain, because I'm easy to ignore. So I really appreciate you specifically bringing this topic up, it really helps to get things going.
You can say it in 10 threads if you want, that’s still not true. CRA is a template using React. The team working on React can work on a React template, that doesn’t mean they’re the same thing. It doesn’t even make sense.
This is true throughout the React universe. React itself does almost nothing useful. In order to build an app that does anything, you need routing, state management, API connections, etc. etc. Reactland is all just a grab bag of random half-maintained unofficial libraries that sort of work with each other.
Compared to Angular or Vue, it's the wild west. I don't understand why anyone puts up with it.
Modern Yarn (currently on 4.x) works great. We use it in the Redux library repos. I don't think it ever hit a majority of usage, but the tool itself is solid. That said, yeah, PNPM has gotten more popularity lately.
I know Chris well enough from his writing and some conversations that I can vouch that "resume-driven development" is absolutely _not_ his motivation here.
Chris is one of the most thoughtful and insightful engineers I can think of. He has a love of actual programming, but also deeply cares about how programming and technology have an influence on us as programmers and the rest of the world.
Given that, this post is him expressing his interest in learning technologies because they look interesting and potentially useful, but also giving reasons to _keep_ learning over the course of your career rather than getting stuck in a rut.
I probably didn’t even need the personal vouch to realize I likely read this with a lens of heavy disdain for rdd.
I whole heartedly agree that it’s important to keep learning over the course of your career. And I believe you that the author is aware of the nuance. But I think it’s also incredibly easy to read this piece as “add rust to your .net shop because it’s good for your career”.
I don’t know the author. But if I had to pull numbers out of thin air and take a guess, I’d venture 95% of .net shops where an engineer said “let’s do this new thing in rust” was overall a terrible decision for the team and a good decision for the individual engineer, everyone else be damned.
It’s wholly unfair of me to criticize the author specifically without knowing the context of the problem he was solving. My original comment was not worded well, but it was not as directed towards the author as it reads as, but more as a general counter commentary to the point the author was making.
I think you read into the article some things that weren’t there. The question from the colleague was why I was even interested in learning something we all knew (me included!) we wouldn’t use there. At no point did I propose using Rust at that .NET shop! The whole point was that I was curious about and enthusiastically learning—on the side, on my own time!—a technology that was totally unrelated to my job. Pretty sure the closest that shop ever got to Rust was when I shared interesting bits about it in the company’s wide-open tech talk series, but that series also included folks sharing things like “this cool thing I did with a Raspberry Pi” and “look at what cool hacks you can do with Amazon Alexa” and so on. Long story short, you’re not even responding to what I actually wrote, but to something else that you (probably for good reasons in your own experience) get button-mashed by! (Me too, for what it’s worth!)
I keep collecting more links and more points that I need to add in an update to that post. The latest thing we're running into is a conflict between the `browser` field in `package.json`, which some tools look at to find an artifact that can be served from CDNs like Unpkg _or_ an ESM artifact in general, vs Webpack 4 looking at that field first but not accepting `.mjs` artifact extensions. Still trying to sort that one out.
- https://www.youtube.com/watch?v=zMf_xeGPn6s