The React team unveiled yesterday a new experiment called React Server Components, and I must say I'm pretty excited about it.
Thank you, Dan Abramov, for saying that GraphQL is not for everyone. Thanks to the React team for looking for solutions to build web apps without web APIs and daring to challenge the status quo.
A few weeks ago, I wrote an article to defend the idea that it is possible to create single-page apps without building a web API to connect the frontend and the backend. I believe this article was as much loved as it was hated.
On the one hand, there are all the developers who are tired of developing web APIs and welcome all the solutions to get rid of them.
On the other hand, there are many developers who think that web APIs are necessary and that it's a shame to want to do without them.
Of course, no one is absolutely right or wrong. It depends on what you build.
I think a lot of web apps can live very well without a web API. But there is also a significant number of apps for which a web API can be very beneficial.
So, congrats to the React team for considering both cases and looking for a solution for those who are in the "API-less" camp.
React Server Components allow to abstract away the runtime environment where the views are rendered. Any view can be rendered in the frontend, the backend, or both, and from the developer's perspective, it doesn't matter. The developer can write an application as if the frontend and the backend were a single entity.
This approach appeals to me because it is in line with one of my biggest obsessions. Indeed, with Layr I'm trying to achieve the same thing — to bring the frontend and the backend together.
What makes Layr and React Server Components different is the nature of what is transported between the frontend and the backend. Layr transports models while React Server Components transport views.
I think that transporting the models eventually offers more possibilities because the views remain entirely in charge of the frontend and it is, therefore, easier to create multiple frontends for different platforms (web, mobile, desktop, etc.).
However, it is possible to imagine that React Server Components could also be used to build React Native apps. We would then have a backend capable of generating views for React Native. At first glance, the idea may seem crazy, but why not?
Anyway, all this reinforces my belief that the "API-less" approach is more and more a thing.
Thank you, React, for continuing to innovate. Removing the API layer is not a small deal. It is a huge architectural shift.
Top comments (6)
I think ultimately we are going back to where we started. This is how things work / used to work in JSP with Java 😁. We are coming back to same patterns.
I'm sorry but JSP doesn't really compare to React Server Components. JSP generates the views on the server only while React Server Components reunite the client and the server so that the views can be generated on both sides indifferently.
A mix of both then.
You are absolutely right, I think your project is the key to simplifying this difficult to maintain mess of rest/gql layers (often not necessary).
Maybe adding github sportsorship button can help growing faster?
Thanks, @giub , but the problem I face now is not about money. The priority is to attract users and contributors.
GWT, Silverlight, JSF ... Experts trying to hide complexity from developers.
What's the point? Every of these fmk were adding complexity to a quite simple client/server architecture.
One question : will you take time on your roadmap to make things easier for developers struggling with bugs on their future Layr app? I wonder if React think about this too.