Hi! I'm rather amused to be included on the list at the top of the post.
I've been thinking about a lot of these topics lately. I've had side discussions, private complaints, interactions with the React team on Twitter, and passed on community feedback to the React DevRels .
I have a number of gripes and concerns about a lot of the development process, communications, docs work, etc.
But I also continue to feel that React as a technology is a solid and reasonable choice.
Community Concerns
I think the biggest problem, in posts like yours and Cassidy's, and all the ricocheting discussion on Twitter and Reddit and elsewhere, is that there isn't one problem. There's several dozen overlapping concerns: technical directions, communications mis-steps, framework favoritism, etc.
The result is that there's a lot of conflation of concerns. "When will the next React version be released?" is a totally different question than "React recommends use of a framework in the docs", is a different question than "can we still use React on the client side?", is a different question than "can there be an 'official' React framework separate from a company", is a different question than "can there be a non-corporate React foundation or steering committee".
I've honestly been trying to avoid getting drawn into a lot of the discourse and arguing, both because I just got done with a year-long effort to ship Redux Toolkit 2.0 and am trying to rest and recover from that, but also because I have "real work" that I want to do and getting caught up in the debates isn't going to help me be productive.
But... given these posts and the recent discussion, I'm starting to feel like it would maybe help if I wrote a giant post just trying to list all the accumulated concerns the React community is debating right now, clearly name them and separate them, and hopefully make it easier for us to collectively discuss these individually. (Frankly I don't want to spend time writing this post, but I'm also getting frustrated watching the debates go in circles.)
Responses
For your specific points:
Ownership
I agree that the issue of "ownership" is a general point of concern, although tbh it's always been that way. The community didn't like it when React was only "owned" and worked on by Facebook/Meta. I agree that Vercel announcing new React features is obfuscatory, and that there's a lot of concern with Vercel and hypothetical "framework lockin" scenarios. That said, Vercel has also put their money where their mouth is, and is paying several developers (Sebastian, Andrew, Josh, etc) to specifically build these features into both the actual React packages and the Next framework that layers on top of those core reusable packages. The community doesn't seem happy about that, either. Sort of a no-win scenario. Either it's just Meta that owns React and there's complaints, or Vercel and Meta are both heavily involved in React's development and people complain.
Build Tooling
As a fellow library maintainer, and one that's been impacted by RSC-related build issues, I'm also highly sympathetic to concerns about complexity. Dan and Ricky are right when they say that RSCs are "just extending React's data flow model to the server, and it's still just React". But it's also true that this introduces tons of mental overhead and complexity for ecosystem maintainers, and for app developers, who now have to figure out how these additional pieces fit together and expand the mental model.
I disagree that all the complexity is brand-new. CRA came out in 2016, and that was in response to how every React tutorial started with "first, let's spend 20 pages explaining how to set up Babel and Webpack". The build tooling has always existed in the React ecosystem. There's more of it now, yes. In some ways it's simpler to use. In some ways it's more complex because there's more layers, and with RSCs that build tooling is now somewhat more visible at the app layer. But it's always been there.
I'll also note that the phrase "just React" is interesting and maybe just a bit misleading. Sure, you've always been able to use React as a script tag, but in practice it's always been with a set of build tools. It's just that there was less opinion in which build tools you used, and that React was limited to the client side. There's nothing preventing you from doing that today. You can still use React + Vite, or React + CRA5, or React + plain ESBuild, or React + a script tag, or React + your bespoke Webpack config. Nothing about React's client-side usage patterns has been taken away. I agree that the React team's emphasis on "frameworks" in the docs (and the way CRA got dropped and Vite got hidden down in a details section with the phrase "we can't stop you if you want to use this") has been frustrating. But it literally does not stop you from using React with the build setup and config that you want to use, in exactly the same way that nothing is stopping anyone from still just FTPing an HTML file to their static file host of choice. Yeah, I know - as things change in a technical ecosystem, there's pressure to keep up, and sometimes options do get taken away from you as tools change. In this case, though, nothing has been taken away at the technical level. (I will also obligatorily note that I am very tired of the phrase "should I use Next or React?", which is a related issue - the assumption that Next is a different thing than "React" because "React" implies CRA or something.)
A Community Framework
There's nothing stopping you or anyone else from building new RSC frameworks. Seriously :) Yes, Next.js is the big one, and it's got corporate backing. Remix got bought out by Shopify, but it did start as a community-driven tool (in the form of Ryan and Michael deciding to build it). But while RSCs are absolutely still under-documented for framework devs, there's enough explorations out there to A) show how they work and how you'd integrate them into a framework, and B) show that anyone can play with building their own framework.
So, if you want a new framework that makes use of RSCs in a "default" way, the right answer is to create that project, start working on it, and gather fellow contributors (and I would advise doing that rather than trying to set up some kind of a "steering committee" right off the bat).
Summary
If someone is concerned about the technical or social directions of the React tooling and the community, by all means, go find a tool and community that works better for you! (That's not an insult, that's a genuine "please use what makes you happy" suggestion.)
I'm still very involved in React and the ecosystem, and I have no plans to switch.
I don't know if I'll end up writing that "why is everyone upset" blog post. I'd rather be trying to relax or working on Redux tasks. Don't know if folks would actually find it useful.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
I think people forget about how taxing is to work on your spare time and provide maintenance for stuff heavily used. One of my favorite redux alternatives is just barely hangs on (overmindjs, I recommend it to everyone as a more ergonomic way of working with a store), because the 1 guy who was responsible for 99% of the code had no more spare time.
So either we find ways of funding projects without the Evil Corporation that distorts the Pure Thing, or we won't have entirely Pure Things, but at least they will work.
Overmind.js user here - I have a similar experience - the tool is awesome - both when it comes to concepts (aka building blocks) and ergonomics of usage - still "maintainer needed" makes "big brains" (wink wink grugbrain.dev/) scared.
Hi Mark, thank you for your thoughtful and inspiring answer. BTW, I really admire the work you are doing with Redux and Redux Toolkit.
I also believe that React is a solid technology and probably the best choice for most projects today. I also agree that there isn't just one problem, but many different ones. I attempted to highlight two, but I hope you will write that “giant post”, clearly separating them in a much better way than I could.
As for “complexity is not brand-new”, you are right. I also used to configure Webpack before CRA. I also created a full SSR framework in 2016, before the advent of Next.js (still used today by hundreds of pharmacy e-commerce websites in Italy), solving complex issues now hidden by frameworks. The fact is that, with complexity hidden by CRA, and then frameworks, you don’t have to cope with it during development (let’s say after the first period when you had to “eject” CRA for anything…). Now with RSC, the complexity becomes an ongoing challenge throughout the entire project development.
I also agree that nothing has been taken away. You can use React with Vite, or you can use Next.js with Pages. However, I can assure you that many potential customers, especially digital agencies, have expressed that they would not even consider using our React Bricks library if they couldn't use it with the Next App folder. So, the FOMO pressure is high.
For the Community Framework, I personally would never take on such a project :) It’s far beyond my capacity and time. Considering the magnitude of the effort, I believe that a stable steering committee setting goals is needed, and it should be financially supported. Without a big sponsoring company, financial support from the community would be needed. Projects like TanStack have multiple sponsoring companies, but I envision it more like a legally constituted no-profit association with its steering committee, where anybody in the community could become a Member of the association, paying a small annual fee, which would cover the expenses associated with the committee. Does it make any sense? Is it utopian?
I am also completely involved in React and the ecosystem with absolutely no plans to switch. And I am positive about the future.
Dan and Ricky are right when they say that RSCs are "just extending React's data flow model to the server, and it's still just React"
I do not think this is correct. RSC involves more problems than what your mentioned statement says.
Problems involved with RSC are way different from the existing "several dozen overlapping concerns".
Before RSC, react promoted it as a library, not a framework. All it needs is just a file-to-file transpiler to convert JSX syntax to javascript.
After RSC is introduced, react requires a framework to enable RSC.
The official docs now promote several frameworks (how about other frameworks? what decides the appearing orders of those frameworks which are associated with private companies), and there is no more setup instruction with general tools like webpack, babel.
For me, who maintains an internal webpack setup, a private framework based on react which relies on renderToString/useSyncExternalStore for SSR support, integrating RSC is likely impossible with the current state of the document (and the current vision?).
What is my expectation?
For me, RSC would be ok if React document starts with the setup by more general tools like webpack/babel and move the framework promotion below this section.
It is best to stay away from "react is a framework", and stick with "react is a library".
I think this will less likely happen in the near future because it "hypothetically" conflicts with the business of some of these frameworks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi! I'm rather amused to be included on the list at the top of the post.
I've been thinking about a lot of these topics lately. I've had side discussions, private complaints, interactions with the React team on Twitter, and passed on community feedback to the React DevRels .
I have a number of gripes and concerns about a lot of the development process, communications, docs work, etc.
But I also continue to feel that React as a technology is a solid and reasonable choice.
Community Concerns
I think the biggest problem, in posts like yours and Cassidy's, and all the ricocheting discussion on Twitter and Reddit and elsewhere, is that there isn't one problem. There's several dozen overlapping concerns: technical directions, communications mis-steps, framework favoritism, etc.
The result is that there's a lot of conflation of concerns. "When will the next React version be released?" is a totally different question than "React recommends use of a framework in the docs", is a different question than "can we still use React on the client side?", is a different question than "can there be an 'official' React framework separate from a company", is a different question than "can there be a non-corporate React foundation or steering committee".
I've honestly been trying to avoid getting drawn into a lot of the discourse and arguing, both because I just got done with a year-long effort to ship Redux Toolkit 2.0 and am trying to rest and recover from that, but also because I have "real work" that I want to do and getting caught up in the debates isn't going to help me be productive.
But... given these posts and the recent discussion, I'm starting to feel like it would maybe help if I wrote a giant post just trying to list all the accumulated concerns the React community is debating right now, clearly name them and separate them, and hopefully make it easier for us to collectively discuss these individually. (Frankly I don't want to spend time writing this post, but I'm also getting frustrated watching the debates go in circles.)
Responses
For your specific points:
Ownership
I agree that the issue of "ownership" is a general point of concern, although tbh it's always been that way. The community didn't like it when React was only "owned" and worked on by Facebook/Meta. I agree that Vercel announcing new React features is obfuscatory, and that there's a lot of concern with Vercel and hypothetical "framework lockin" scenarios. That said, Vercel has also put their money where their mouth is, and is paying several developers (Sebastian, Andrew, Josh, etc) to specifically build these features into both the actual React packages and the Next framework that layers on top of those core reusable packages. The community doesn't seem happy about that, either. Sort of a no-win scenario. Either it's just Meta that owns React and there's complaints, or Vercel and Meta are both heavily involved in React's development and people complain.
Build Tooling
As a fellow library maintainer, and one that's been impacted by RSC-related build issues, I'm also highly sympathetic to concerns about complexity. Dan and Ricky are right when they say that RSCs are "just extending React's data flow model to the server, and it's still just React". But it's also true that this introduces tons of mental overhead and complexity for ecosystem maintainers, and for app developers, who now have to figure out how these additional pieces fit together and expand the mental model.
I disagree that all the complexity is brand-new. CRA came out in 2016, and that was in response to how every React tutorial started with "first, let's spend 20 pages explaining how to set up Babel and Webpack". The build tooling has always existed in the React ecosystem. There's more of it now, yes. In some ways it's simpler to use. In some ways it's more complex because there's more layers, and with RSCs that build tooling is now somewhat more visible at the app layer. But it's always been there.
I'll also note that the phrase "just React" is interesting and maybe just a bit misleading. Sure, you've always been able to use React as a script tag, but in practice it's always been with a set of build tools. It's just that there was less opinion in which build tools you used, and that React was limited to the client side. There's nothing preventing you from doing that today. You can still use React + Vite, or React + CRA5, or React + plain ESBuild, or React + a script tag, or React + your bespoke Webpack config. Nothing about React's client-side usage patterns has been taken away. I agree that the React team's emphasis on "frameworks" in the docs (and the way CRA got dropped and Vite got hidden down in a details section with the phrase "we can't stop you if you want to use this") has been frustrating. But it literally does not stop you from using React with the build setup and config that you want to use, in exactly the same way that nothing is stopping anyone from still just FTPing an HTML file to their static file host of choice. Yeah, I know - as things change in a technical ecosystem, there's pressure to keep up, and sometimes options do get taken away from you as tools change. In this case, though, nothing has been taken away at the technical level. (I will also obligatorily note that I am very tired of the phrase "should I use Next or React?", which is a related issue - the assumption that Next is a different thing than "React" because "React" implies CRA or something.)
A Community Framework
There's nothing stopping you or anyone else from building new RSC frameworks. Seriously :) Yes, Next.js is the big one, and it's got corporate backing. Remix got bought out by Shopify, but it did start as a community-driven tool (in the form of Ryan and Michael deciding to build it). But while RSCs are absolutely still under-documented for framework devs, there's enough explorations out there to A) show how they work and how you'd integrate them into a framework, and B) show that anyone can play with building their own framework.
So, if you want a new framework that makes use of RSCs in a "default" way, the right answer is to create that project, start working on it, and gather fellow contributors (and I would advise doing that rather than trying to set up some kind of a "steering committee" right off the bat).
Summary
If someone is concerned about the technical or social directions of the React tooling and the community, by all means, go find a tool and community that works better for you! (That's not an insult, that's a genuine "please use what makes you happy" suggestion.)
I'm still very involved in React and the ecosystem, and I have no plans to switch.
I don't know if I'll end up writing that "why is everyone upset" blog post. I'd rather be trying to relax or working on Redux tasks. Don't know if folks would actually find it useful.
So, take that all as you will :)
Okay. Nice
I think people forget about how taxing is to work on your spare time and provide maintenance for stuff heavily used. One of my favorite redux alternatives is just barely hangs on (overmindjs, I recommend it to everyone as a more ergonomic way of working with a store), because the 1 guy who was responsible for 99% of the code had no more spare time.
So either we find ways of funding projects without the Evil Corporation that distorts the
Pure Thing, or we won't have entirely Pure Things, but at least they will work.Overmind.js user here - I have a similar experience - the tool is awesome - both when it comes to concepts (aka building blocks) and ergonomics of usage - still "maintainer needed" makes "big brains" (wink wink grugbrain.dev/) scared.
Hi Mark, thank you for your thoughtful and inspiring answer. BTW, I really admire the work you are doing with Redux and Redux Toolkit.
I also believe that React is a solid technology and probably the best choice for most projects today. I also agree that there isn't just one problem, but many different ones. I attempted to highlight two, but I hope you will write that “giant post”, clearly separating them in a much better way than I could.
As for “complexity is not brand-new”, you are right. I also used to configure Webpack before CRA. I also created a full SSR framework in 2016, before the advent of Next.js (still used today by hundreds of pharmacy e-commerce websites in Italy), solving complex issues now hidden by frameworks. The fact is that, with complexity hidden by CRA, and then frameworks, you don’t have to cope with it during development (let’s say after the first period when you had to “eject” CRA for anything…). Now with RSC, the complexity becomes an ongoing challenge throughout the entire project development.
I also agree that nothing has been taken away. You can use React with Vite, or you can use Next.js with Pages. However, I can assure you that many potential customers, especially digital agencies, have expressed that they would not even consider using our React Bricks library if they couldn't use it with the Next App folder. So, the FOMO pressure is high.
For the Community Framework, I personally would never take on such a project :) It’s far beyond my capacity and time. Considering the magnitude of the effort, I believe that a stable steering committee setting goals is needed, and it should be financially supported. Without a big sponsoring company, financial support from the community would be needed. Projects like TanStack have multiple sponsoring companies, but I envision it more like a legally constituted no-profit association with its steering committee, where anybody in the community could become a Member of the association, paying a small annual fee, which would cover the expenses associated with the committee. Does it make any sense? Is it utopian?
I am also completely involved in React and the ecosystem with absolutely no plans to switch. And I am positive about the future.
I do not think this is correct. RSC involves more problems than what your mentioned statement says.
Problems involved with RSC are way different from the existing "several dozen overlapping concerns".
Before RSC, react promoted it as a library, not a framework. All it needs is just a file-to-file transpiler to convert JSX syntax to javascript.
After RSC is introduced, react requires a framework to enable RSC.
The official docs now promote several frameworks (how about other frameworks? what decides the appearing orders of those frameworks which are associated with private companies), and there is no more setup instruction with general tools like webpack, babel.
For me, who maintains an internal webpack setup, a private framework based on react which relies on renderToString/useSyncExternalStore for SSR support, integrating RSC is likely impossible with the current state of the document (and the current vision?).
What is my expectation?
For me, RSC would be ok if React document starts with the setup by more general tools like webpack/babel and move the framework promotion below this section.
It is best to stay away from "react is a framework", and stick with "react is a library".
I think this will less likely happen in the near future because it "hypothetically" conflicts with the business of some of these frameworks.