I'm writing these random notes as an open letter to the people I deeply trust in the React (and more generally, the open-source) community. People ...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
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 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.
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.
Okay. Nice
Hi Matteo, I just want to add my 2 cents from the perspective of someone who uses React (and Next.js, Remix, React Native) to build websites and apps, not in the business of making libraries (like Tanstack, etc).
I feel like people are making too big of a deal of the new features, especially RSC and Server Action. As mentioned by the React team and Next.js team, the new features are opt-in. You can still use the old way of using React. It is understandable that the team promote RSC and server actions because I'd like to believe that they think it's better way to make web apps. And I agree too. When I made web app using create-react-app, I needed to do a lot of things that is now completely handled by the frameworks like Next.js and Remix, which means less code to write for me!
I've been playing and using RSC and server actions in both my hobby projects and production websites. And I love it! And I'm pretty sure I'm not the minority. When Remix was released, I played around with it and thought that it was better than Next.js (Pages). But then Next.js released RSC and server action and I changed my mind again. Once Remix supported RSC, I might change my opinion again.
Even without the frameworks, new programmer already would have a hard time to choose which tech to use to build web apps: Angular, RoR, React, etc. It's already complicated enough as you said. We all went through that phase, at least I did. I tried Angular, jQuery, Vue, etc, but ended up with React because it was the one that resonated well with me. New programmers these day actually are lucky because the documentations (Next, React, Remix, etc) are very good!
I like how React is making new features even by collaborating with external frameworks. It actually is kinda cool cause that means React team focuses on the core while still assisting the frameworks to build additional features around React.
Anyway, basically I just want to say that changes in software development is inevitable. New ideas keep coming. New tools will be built. It's all part of development life.
I think the whole "you don't have to use it" argument misses the key point that after a couple of years, nobody would hire a developer that doesn't use those tools.
You don't have to use React, Typescript etc, but good luck find a job without knowing those these days.
You don't have to use it, but doesn't mean you cannot learn it 😁
When I was developing iOS app with Objective-C, so many people still choose to use Obj-C even when Swift appeared because many apps were already built with Obj-C, and we didn't have to use Swift.
My point is, you can still use existing features in React, but it doesn't hurt to learn the new stuff. There will always be new stuff anyway, that's what make developer life exciting.
I get that part, but there's still the effort you have to put in to learn. I thinks that's where people are complaining.
You don't want someone creating unnecessary complexity and you then have to put in that effort to learn the new thing when that energy could have been directed into something productive.
Many businesses want experience actually using the parts of the tool too. Saying "you can learn it and just not use it" is only marginally better than not learning it all. Unless you lie about having actual experience with it.
A lot of people chose to not use React 🤷 React still is what it is. Now there is just also Nextjs and if you want to move in a different direction than Nextjs, you have a lot of work to do to match the same features that Nextjs offers out of the box. That's why a lot of people chose to use Nextjs, but you are still completely free to use React without Nextjs and do everything yourself like before when there was no Nextjs...
I personally like the direction Remix is going, not overly abstracting the web platform. There are no deployment constraints either.
I feel really concerned, that the core team has neglected the community in order to develop features that only really benefit Vercel. And while I am personally a customer, not everyone needs a frontend framework that has fullstack aspirations.
And the new docs, doesn't it feel like a slap in the face that React has decided its too good for us mortals and we need to use a framework to be able to digest it. Large part of the appeal that React had is that it was flexible enough to Frankenstein it into an existing project and gradually migrate.
I love React, I really do but I personally don't feel like it is future-proof anymore, and its becoming harder to recommend for people just getting started. React has made a clear turn to stop being a standalone library and to become a framework dependency. And this is not just the React/Next affair, Expo has become synonymous with React-Native too.
Concurrent mode was supposed to make React competitive in the benchmarks against competing frameworks like Svelte that were taking the lead in performance, but we never got what was promised at ReactConf 2018. Now we have Solid, Qwik, Preact, and others that bring the old react mental model with serious performance gains and it becomes harder and harder to justify starting a new project with React.
Great post! 👏👏
Thank you for your perspective 🙏
Personally I like React direction. RSC seems right for me. You can just add „use client” at the top of the tree and opt out 🧹
We should have remember that RSC is still react API, not next.js specific feature. So all frameworks will benefit from it, we should appreciate it 🥳
Actually RSC is really complicated to implement yourself. It's not something that works out of the box when you install React. You need a bundler that can deal with RSC and you will have to build your own server that understands RSC. To my knowledge NextJS is stil the only framework that supports RSC. None of the others have managed to get it working.
To provide a perspective of a bran new developer, switching careers just out of boot camp-- We learned to make sites with CRA and then I immediately learned that is already outdated, and so I turned to Vite. It concerns me that Vite and other methods of creating pure react apps are barely mentioned as an option, and I had to piece together the knowledge to use it from several clunky youtube videos and one nearly outdated $12, four hour class on Udemy. I would really like to see more promotion, support, and instruction/documentation for these frameworkless methods because I like the idea of having a separate frontend and backend. However it looks like that paradigm is being brushed aside or even hidden from the view of new developers who would just like to master the basic concepts before being ushered into a large framework. I feel like if I hadn't come across Vite, nearly on accident, then I would be jumping into Next.js et al despite them possibly being overkill for many projects, without even being aware that other paths exist. I will definitely learn Nextjs, however I feel that it is important to gain experience developing projects without large frameworks first.
React is completely amazing, so thank you to all of you who have made these things possible.
I think top players would never work together unless it is for money. I never see top tech giants playing together.
Our main bets are on NextJS, nothing compares to the dx it delivers. Open source can be greatly depressing at start.
React is outsourcing the work. They are taking the responsibility of maintaining the core. While brilliant minds are crafting wrappers for various purposes in open source.
I believe the ecosystem is working fine. Only improvement could be that if we can take slices of different frameworks and make things work. Interoperability.
I acknowledge the ongoing chaos, and everything is fine.
[Fire everywhere]
Great article!
I like that every closing parenthesis is prefixed with a semi-colon. ;)
100%! Exactly what I was thinking! Glad to know I'm not crazy. Thank you. I also don't like NextJs new routing. I really like Remix. I feel it's continuing the development of React in the right way. RSCs are just glorified APIs that return HTML.
Hi Matteo,
Interesting that you brought up SSG in Remix; I just watched the latest Remix roadmap stream where Ryan and Michael outlined there plans for introducing SSG - or 'prerendering'.
Great article. Thanks
Cool
Why are we trying to solve everything within the bounds of what we currently have? I hope you guys can try HTMX for a month and see that not everything has to be a complex hellscape. My issue with most frameworks is that they try to do everything in the front end when the back end would have been better suited for it.
I love HTMX. It's extremely composable and easy to work with and easy to reason about. I'm looking for a job right now and it is extremely frustrating hearing, "We are getting off our legacy code and migrating towards .NET 8 and to React." And it's like, "Guys, React is legacy, use HTMX or Unpoly."
I've even built a simpler HTMX called
html-formas it focuses on forms. I wouldn't use it at a company as it is missing much of the functionality that HTMX has. But it's amazing how far you can get with this simple pattern. I've even built SPA-PWAs with it.Is there a more complex example that can convince me that is enterprise application ready? (In other words you can have 50k lines of code and still make sense of what's going on).
"What are your thoughts on the future of React?"
"Do you believe it is feasible to have a community-driven framework without a sponsoring company?"
I think we slept on the open source crisis, but for good reasons: who should fund important projects? We can't ask the developers to pay for libraries from their own salaries which they get to make someone else's company successful. The companies depending on these free packages? Why would they pay for something that was free so far?
Unless we can fund things based on usage technologies will be vulnerable for corporate interests over community interests.
On the benevolent dictatorship; I don't agree with. Dictatorships are generally bottleneck: until the Supreme agrees you can't really do anything. Maybe you have also heard about the 200$ (or whatever number it was) pen: employee wants to buy a pen for their work, so first spends work-time on filing a request, that gets read by another employee, forwards it to whatever manager, who needs to read and decide during their work-time to pay for it or no.
I'll correct myself, I find a "High Trust Society" better. Second best would be "Benevolent Dictatorship".
The problem with a high trust society is its even harder to implement than the "Benevolent Dictatorship" model.
Obviously if you can trust everyone in your team/corp then no one needs to ask for permission for anything. I think Valve implements it and does not have any hierarchies (early days Google seemed to be similar).
A good manager will not make you to ask for permission for 200$ work related expense. He will maybe ask about it after you already ordered it to justify it.
Picking specific examples: it's always a question if the idea/model is bad or is it's implementation?
The same discussion happens countless times about agile methodologies.
BTW, what's up with plans for newer releases? I started reading about
useEffectEventand it is indeed a thing we really need in our code, but there's no release since 2022. Is there a React 19 coming? Or is it going to be likecreate-react-app: waiting half a year to fix a simple webpack misconfiguration and then deprecating it?Interestingly we started web development in the same year. I am surprised you gravitated towards the SPA side of things. If you ever feel like it, come join us for a Ruby on Rails conference. We're a bunch of happy, grateful, and productive people, and we don't have any of the problems causing people grief in the front-end industry. Rails incorporates all the lessons learned since the beginning of web development, and feels like a natural progression from there. 🙂
To me React is going to the recycle bin, htmx ftw
Here, here!
Would react we the best option for us building Earthday.ai domain re the Eday Token, NFT's Wallet and broader ecosystem. I've also bought Earthdayofficial.eth but still completely in the dark as to how it can help!
Isn't the whole core team Facebook's employees?
Sophie Alpert said that there are about 15 devs from Meta and 3 devs from Vercel working full time on React.
Main problem is that React want to implement RSC by default close to CSR in one bundle? Right?
Is react able to make the best websites? What so different with React than other website builders?