React, where are you going?

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 like Tanner Linsley, Laurie Voss, Cassidy Williams, Michael Jackson, Mark Erikson, Kyle Mathews, Sophie Alpert and many others.

In the past few months I’ve been feeling conflicted about React. It started with the days when server components were essentially announced at a framework conference, and the React documentation began suggesting the use of an external framework for React development. After reading Cassidy's post last night and sharing her vision, I felt the urge to express my concerns as well.

I fell in love with React in 2016 when Angular announced Angular 2 and we were worried about the breaking changes. I immediately fell in love with the React community, even though I never actively participated.

I remember the tweets between Sophie Alpert and Dan Abramov. I also remember the first talk at ReactJsDay (Italy) by Michele Bertoli in 2016, which made my eyes sparkle. And I can't forget the 2018 edition of ReactJsDay when Michael Jackson recreated much of React Router live coding in front of us - those were great days!

React has been a winning choice for us, both as a web development agency and now as a product company. I still get emotional when I think about the day (I believe it was January 2nd, 2020) when I showed the first MVP of React Bricks to Guillermo Rauch, who was the first to believe in the project and gave me the confidence to go on.

However, today I see two problems that make me enjoy React a little less and make me worry that new developers might be intimidated by it: ownership and complexity.

Ownership

As for ownership, I don’t particularly like that:

1. React suggests using a framework to start a project, suggesting to use one of the three main open source frameworks, instead of just React.
2. During a framework's conference, new React features such as React Server components are introduced to a large part of the community for the first time, as if it was just a framework achievement.
3. The most popular framework, which has hired some people from the React core team (which is not a bad thing, but certainly provides them with privileged insight into development) uses canary releases, while the last release of React (18.2) is of June 2022. In this way canary features enter the codebase of many new React projects, becoming the “de facto” stable release, but just for the users of a framework that can feel safe leveraging canary features.

Furthermore, features like Server actions, which trigger metered serverless function calls when hosted on cloud platforms, may potentially increase hosting costs for frontend applications in the future. While this is not currently a problem since there is no monopoly and we have the freedom to choose, I would like a way for the community to be guaranteed that tomorrow there will still be multiple choices available. Please understand that I don't see anyone as being "evil" in this regard. Great things can come from the collaboration between a private company and the community. It's simply a matter of separating concerns and responsibilities.

Complexity

I started creating websites in 1996, when I was 17 years old. At that time, you created HTML files and uploaded them to an FTP server to a folder served by a web server. I managed my own physical server (a Pentium 120), housing it at a local Internet Provider. It ran on Windows NT4 IIS as webserver, BIND for DNS, and IPSwitch IMail server for email. Everything was simple and clear.

Nowadays, web development has become more powerful, but also much more complex. We have lost touch with what's happening under the hood, with the introduction of transpilers, bundlers, and frameworks. However, React stands out with its clean one-way data flow. Things got a bit more complicated with hooks (which have some behind-the-scenes black magic :), but it was manageable and, in the end, a good choice.

With Server components, everything is much more complex to grasp. And, the fact that they are the default choice in the most widely used React framework, somewhat forces newcomers to also learn this new paradigm. I understand the advantages of RSC, but now we have two different ways of building things even within the same React framework.

We have recently completed the task of making the React Bricks library compatible with RSC. This required a month of work and thousands of lines of code. However, as a result, the final API for developers is not as clean as before. I am uncertain whether sacrificing simplicity for a slight performance boost will truly benefit our customers. Nevertheless, since it is both the "default" and the shiny new thing, we have to have it.

Meanwhile, there are many interesting things happening outside of the React world, with the new frameworks. I wouldn't like to be a new programmer trying to choose their first framework right now, as the decision is really tough. React is the most popular, Vue is easier to use, Svelte is a cool idea, Astro is really great, and then there are signals and SolidJS by the very smart and humble Ryan Carniato. Qwik is also very smart, I love the approach (it was created by competitors of React Bricks… but I hold them in high esteem :). So… the choice of a base framework is already so complicated!

A dream?

In this complex scenario, it would be beneficial to have a "default, official" React framework that covers the basic needs of building a SEO-friendly website, with routing, SSG, SSR, ISR (and all the permutations of these letters ;). I know the Remix team would not agree on the need for SSG, but I think it has valid use cases. And I would like it to always be self-hostable on a Linux box.

I envision this default framework being developed by the React community, with a steering committee consisting of recognized contributors from the React ecosystem (through a voting process?). I know that usually open source doesn't work in this way, but... I dream of this "probi viri Fellowship of the Ring" making decisions.

This default framework should not aim to include all the shiny new things out there, found in other frameworks like Remix or Next.js, which I use and love. I believe it should serve as a solid starting point created by the community. And I think we have already some great stuff available today to start with (Tanner?).

As for RSC, I think the concept of avoiding hydration is great, but we need a new kind of server-client integration to make them easy to use. If they remain complex, with the current constraints, trading simplicity for performance would not be beneficial for most websites. And probably RSC is losing in terms of performance compared to something like Qwik, anyway, because they are performing the same work twice, processing chunks from serialized JSON on the client. However, this is material for a separate discussion.

Open Questions

So, after this long stream of consciousness, I would like to pose some questions to the community:

1. What are your thoughts on the future of React?
2. Do you believe it is feasible to have a community-driven framework without a sponsoring company, but with a sort of elected steering committee? How could this independent steering committee be financially supported by the community or corporate users, in order to maintain its independence?

Matteo Frana
Jan 16, 2023

Comments

[Mark Erikson]

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 :)

[Matteo Frana]

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.

[András Tóth]

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.

[Damian Płaza]

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.

[Sang]

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.

[Yusuph Idris Olatunji]

Okay. Nice

[Nico Prananta]

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.

[Joshua Amaju]

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.

[Nico Prananta]

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.

[Joshua Amaju]

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.

[Nathan Heffley]

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.

[Rense Bakker]

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...

[Saurabh Prakash]

I personally like the direction Remix is going, not overly abstracting the web platform. There are no deployment constraints either.

[Paweł Ciosek]

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 🥳

[Rense Bakker]

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.

[José Muñoz]

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.

[Akindejihill]

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.

[Ashish Khare😎]

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. ;)

[Cagdas Ucar]

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.

[Ruaidhri Lumsden]

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'.

[Corners 2 Wall]

Great article. Thanks

[Yusuph Idris Olatunji]

Cool

[Ej]

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.

[Jon Nyman]

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-form as 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.

[András Tóth]

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).

[Adaptive Shield Matrix]

"What are your thoughts on the future of React?"

• Looks messy, but interesting.
• My personal advice would be to wait 1-2 years until Next.js stabilizes and all the edge cases are ironed out. Currently there is to much noise, unstable APIs, wrong interpretations and expectations. As a dev you have to pay for all the increase in complexity, while only getting very minor performance benefits (and framework vendor lock-in).

"Do you believe it is feasible to have a community-driven framework without a sponsoring company?"

• No
• Take a look at Nodejs. Why do you think Bun blows away Node.js in all kinds of metrics ? Not only in performance, but in ease of use, developer experience and new features / development speed as well. The difference? Bun has funding, Nodejs has not. Without corporate funding you cease to exist, because you do not have the means to. The best way have corporate backing is having diversity / many different firms funding your work to not be overly influenced by one (like React is by Vercel).
• Any kind of steering committee always ends up in endless discussions on that to do, instead of outright doing it. Take a look at politics in the EU or any other parliamentary democracy - nothing ever gets decided or done, and if something bad happens no one is accountable for it (because it was a majority decision). Having the requirement to have lengthy discussions of something first instead of outright doing it -> kills motivation and/or drives away your most productive devs. Having a benevolent dictator is the best form of ruling system (if you find the right one).

[András Tóth]

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.

[Adaptive Shield Matrix]

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.

[András Tóth]

BTW, what's up with plans for newer releases? I started reading about useEffectEvent and 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 like create-react-app: waiting half a year to fix a simple webpack misconfiguration and then deprecating it?

[Ted Johansson]

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. 🙂