Matteo FranaI'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:
- React suggests using a framework to start a project, suggesting to use one of the three main open source frameworks, instead of just React.
- 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.
- 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:
- 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, 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
