Why Did OpenAI Move from Next.js to Remix? A Deep Dive into the Switch

OpenAI's recent decision to migrate its frontend framework from Next.js to Remix has sparked curiosity and conversations across the developer community.

With both frameworks being popular choices for React-based applications, many are left wondering why OpenAI would make this move. After spending time analyzing the change, digging into the application, and exploring how Remix is being used, it seems there are several plausible reasons for this switch.

In this post, we'll break down the technical differences, architecture, and specific advantages that Remix brings to OpenAI’s platform. Let’s dive in.

1. A Shift Toward Client-Side Rendering

One of the most prominent changes in OpenAI’s architecture is a stronger emphasis on client-side rendering (CSR). While Next.js is well-known for its server-side rendering (SSR) capabilities, Remix offers flexibility for developers to build applications that are almost entirely rendered on the client side.

When analyzing OpenAI’s application, it becomes clear that much of the interaction happens in the browser. The initial page load sends a basic HTML skeleton to the client, with JavaScript handling most of the dynamic behavior afterward.

Instead of rendering full HTML on the server and sending it to the client (as Next.js often promotes), OpenAI is relying on client-side rendering for its interactivity. This shift makes Remix a more attractive choice, as it’s designed to excel in this exact environment.

2. Efficient Data Fetching with Loaders

One of Remix’s core strengths is its loader API, which provides a clean, efficient way to fetch data that a route needs before rendering. When you visit OpenAI's site, the initial HTML load includes a huge JavaScript object (around 7,000 lines of JSON in some cases) containing all the data required for the first render.

Remix's loader system allows OpenAI to load all the necessary data upfront without having the client continuously fetch APIs after the page renders. This leads to faster initial load times and a smoother user experience. Instead of having to wait for each API call to complete and load content incrementally, all the data is fetched server-side and passed to the client in one go, ready for rendering.

This approach minimizes "waterfall requests," where one API call depends on the completion of another, slowing down the entire experience. With Remix, OpenAI can handle the data fetching more efficiently, improving overall performance.

3. The Power of Remix’s Router

At the core of Remix is a robust routing system, inherited from its origins with React Router. OpenAI’s application has approximately 60 different routes, and managing this complexity with smooth client-side navigation is critical.

Remix’s router is designed to handle client-side transitions seamlessly, without needing to reload the entire page. When switching between routes, Remix fetches only the data needed for the next page via API calls and updates the UI. This is a big win for OpenAI’s dynamic application, where the focus is on delivering content quickly and keeping users engaged without the delay of full-page reloads.

While Next.js also supports client-side rendering, it’s more tuned for server-rendered content by default. Remix, however, shines when building fully client-side experiences, which aligns better with OpenAI’s needs.

4. Why Remix and Vite Make Sense

A crucial advantage Remix offers is that it runs on Vite, a modern build tool that’s known for its speed and simplicity. Vite provides a much faster development experience compared to Webpack, which Next.js relies on.

For OpenAI, using Vite means quicker builds, faster Hot Module Replacement (HMR), and overall a more lightweight and performant developer workflow. The frustrations that developers sometimes face with Next.js’s Webpack build pipeline — including slow build times and confusing errors — can be avoided by adopting Remix, which seamlessly integrates with Vite.

Vite’s ability to handle client-side rendering at speed further justifies OpenAI’s decision, making Remix the more suitable framework for an application that is less reliant on server-rendered content.

5. API-First Architecture

A significant portion of OpenAI’s heavy lifting happens on the backend, with APIs powering much of the application logic. Authentication, data fetching, and other functionalities are handled through separate API calls, with the front end acting mostly as a thin client that interacts with these APIs.

This API-first approach means that Remix’s role is primarily to fetch data via its loaders and render the content while leaving backend logic and database interactions to separate systems. By separating concerns in this way, OpenAI’s application can remain lightweight and modular. Remix fits into this architecture perfectly because it doesn't enforce backend logic the way some other frameworks do — instead, it allows developers to fetch data and handle it in a highly flexible way.

6. Tailored for OpenAI’s Infrastructure

Previously, OpenAI’s application may have been hosted on Vercel, which is deeply integrated with Next.js. However, as OpenAI scales, they are likely running much of their infrastructure on Azure, using their own servers and proxies such as Envoy to manage traffic.

Remix allows OpenAI to self-host their application on their own infrastructure without the deep dependencies that Next.js has on Vercel. Remix runs on Express servers in this case, giving OpenAI the control and flexibility they need to tailor their hosting environment as they see fit.

7. Minimal Use of Server-Side Features

Another observation from the move is that OpenAI isn’t heavily using features like server-side actions (a feature in Remix that allows server-side processing of form submissions). Instead, most of the app’s interactions are happening on the client, with data being fetched from APIs. Since OpenAI doesn’t require complex SSR or SEO optimizations, the need for Next.js’s server-side power is diminished.

Conclusion: Why Remix Is a Better Fit for OpenAI

To sum up, the switch from Next.js to Remix likely comes down to a few critical factors:

• Client-side rendering is a better fit for OpenAI’s needs, and Remix offers more flexibility here compared to Next.js.
• Efficient data handling with Remix’s loader API allows for faster initial renders, avoiding the delays of API calls after page load.
• Remix’s routing system is more suited for applications with many dynamic client-side routes, like OpenAI’s.
• Vite integration offers a faster, more lightweight development experience, improving build times and debugging.
• API-first architecture means Remix’s flexibility with data fetching is a perfect match for OpenAI’s setup.
• Infrastructure independence allows OpenAI to self-host on Azure, rather than relying on Vercel’s platform.

In the end, Remix provides OpenAI with the speed, flexibility, and simplicity they need to continue building a highly interactive and scalable platform. While Next.js is a powerful framework, Remix simply offers a better fit for OpenAI’s client-side rendering and API-heavy architecture.

Refs: