React Ecosystem
Why OpenAI switched from Next.JS to Remix?
The most important point here is that the React ecosystem is not just ServerSide or RSC, but also an indication that SPA and Client Side Rendering continues.
The ecosystem is constantly RSC-React Server Component, SSR- Server Side Rendering and we see a React Ecosystem that acts as if there will be no SPA in the future.
Of course, Vercel pioneered this, and the biggest reason for Vercel to act this way is to increase the use of Next.JS and the Vercel platform and to generate revenue from it. This part is already a very natural behavior.
What is not normal here is that many people in the React Core team move to the Next.JS team and give direction to React, and while giving this direction, Vercel’s priorities become React’s priorities.
React becoming a framework is not only the Meta team but also Vercel, Shopify, Netlify, Expo, etc. The benefit of the formation of framework structures to the ecosystem is very high, but a wrong perception is being tried to be created here.
Now the interest in SPA has decreased? SPA is not in our area of interest at all. Just as Class Components were abandoned with React Hooks, the SPA approach will be completely abandoned with RSC.
Consider Zero JS and the following propositions that have been often stated recently.
- React Class Comp → React Func Comp + Hooks
- SPA → RSC
While the first premise is a concept that only affects the React Developer Experience within the React ecosystem. That is, when the developers in the React ecosystem converted their open source libraries to the Hooks structure (Hooks usage was very convenient for the libraries). Many developers in the ecosystem slowly adapted to this structure.
Now the RSC issue is very complex Bundling + Fetching + Routing. It changes the methods we have used so far in the Network layer where we communicate with the server. It kind of isolates you from the Network.
Fetch, GraphQL, OpenAPI, etc. on the server side… is a new application model that aims to change the methods of using the server, server, cloud.
In summary, RSC requires serious changes in your existing architecture, tech stack.
For example, while SPA is a server that provides .NET, Python, Java, Ruby APIs in its development, with RSC, it is aimed to have a layer where React runs on Node.JS in between, and they call these .NET, Python …. APIs on the back end. This is a very serious and architectural change.
Because of this, Enterprise is not able to make this change in the short term, which is why the Remix team brought SPA Mode.
OpenAI Next.js → Remix
ChatGPT → All rendering is done client-side.JS is server-heavy; instead, Remix strikes a good balance, and with React Router, ClientSide Routing and Rendering are better realized.
In this part, ChatGPT works very fast because it brings all the data with JS during the initial load, then it brings JSON data when clicking on the links, which are rendered on the browser with ClientSide Rendering.
- It uses EnvoyProxy on the front part of it.
- Remix Server is running on Express on the server side.
- They use Azure on the CDN side.
ChatGPT webpage is not running any ServerAction in the background. Here you can see that OpenAI is not a website but an application. Structures that provide intensive service and interaction over APIs on both Web, Desktop and mobile devices need SPA and ClientSide Rendering model.
Likewise, React/TanStack Query is utilized during Server Caching management in communication with the server.
Seeing all of this demonstrates that my blog post on where to do HTML rendering is still relevant.
If you create an Enterprise Toolkit and want people to use it, you should make advantage of as many of the browser’s features and capabilities as feasible. When required, utilize WASM (Web Assembly), such as Figma.
The Enterprise React Toolkit I designed for OnurDayibasi.dev is aimed at this. To offer components, pages, and architectural frameworks for Enterprise Web Apps.
