so chat GPT um they moved from Next.js to Remix um and they announced that yesterday and everybody's freaking out because oh wh why what's going on um and the biggest question is like like why why are they doing this type of thing why are they moving from Next.js so I spent the last hour or so sort of digging in I downloaded the entire codebase um and I sort of just sniffed around and looked at the dev tools to figure out how they are using Remix um and that gives me a pretty good idea as to why they've moved the switch and again this is just a guess um I haven't heard I've certainly asked but I haven't heard any uh any inside scoop from anybody in there so first let's take a look at the application itself so the application is almost entirely client-rendered so it is not a server-rendered application that just sends HTML to the browser most of the interaction most of the rendering all happens on the client so what I did is I went ahead and

downloaded the initial when you visit a page fresh like you. You type in chat gp.com or you go to a link. Um, what you get is some HTML, and I have that here. And inside of that, we've got some meta tags. They have a whole bunch of Link tags that will preload some images for you. Um, and then they also have a bunch of pre-loading of their JavaScript because this is all the JavaScript that is needed to run it on the client. So, um, whereas Next.js, they're very heavy on server, uh, and Remix can certainly do that as well, but Remix is also very good at doing SPAs or client-side applications that are client-side entirely. So, what they're doing here is they are server-rendering this part, this HTML, but there is no, like, there's no HTML being rendered on the server aside from all of these preload links and a little bit of JavaScript. Actually, I thought this little bit of JavaScript was pretty nifty. Um, if you have a color scheme set in local storage, you can get this flash

of unstyled or flash of light mode before you hit dark mode. So, what they do is they just put the script here before they run any of the other JavaScript so that this is a quick blocking script so that you don't get that flash of dark mode, but that's besides the point. Then, I went and downloaded the Manifest right here, and they have about 60 different routes on there. So, that's another really good look at it, is that Remix is from the React Router folks. In fact, Remix is going back to being React Router, and at the core of Remix and at the core of any good web framework is a really good router. So, they have about 60 routes on there, and it actually gives you a little bit more information about each of the routes and what they do. So, lots of them have these things called loaders, and what a loader is, is the ability to provide data to a route when it goes ahead and renders. And if we take a look at that page that you initially hit, you're

going to see a massive JavaScript object inside of here window doore remix content, and this provides it with all of the data. So, on the server, on the first render, they are collecting absolutely every single piece of data that is needed for that initial render. So, what's not happening is that you're loading the application, the JavaScript runs, and then it realizes, Oh, I need to go off to an API and fetch some data, and then come back and then render. That's what gives slow initial load time. So, your options there are you can either give it all of the data it needs for its first client-side render, or you can even just go one step further and render all of the HTML on the client and then pick it up, sorry, all of the HTML on the server and then pick it up on the client. They're not doing that in this case; they're simply just providing all of the data that is needed for this hydration. You can see here it's got my email address, my user ID, and some session tokens, and it's...

many, many, many lines here. If I close this up, you'll see what 7,000 lines of JSON that's being hydrated, and quite honestly, it's pretty fast for that initial load. But what ChatGPT knows is that when you are now switching from page to page, like if I click on this explore GPTs here and we go to all, you're going to see. Actually, we go to fetch. There we go. This is the route, and the route now is not returning HTML like it was on that first one, but it is simply just returning some JSON that is needed for the next route. So now, we're entirely client-side. Switching pages is done entirely client-side, and they're simply just hitting an API server for the data that is needed. And if you take a look at the headers right here, you'll see that they often will point towards a backend API here, which I'm assuming is a totally separate server. They're not running the API out of Remix. Remix is simply just hitting the API itself and collecting the data.

that it then needs um. What other information did I find out here? So, their backend API is running. If we take a look at the headers here, you'll often see like an X to see what sort of server it's running on. Here we go, X Envoy Upstream. So, that is a proxy server that will generally sit in front of uh. They probably are hosting their own servers uh in their own data center since they're OpenAI, and they use Envoy to be able to distribute it and proxy it through to the different. They also do have Cloudflare in front of that as well um. So, that's the API server. But if you actually look at the initial request of going to one of these URLs, so if we click on document and go to one of these pages, you'll see that the remix server itself is running on Express, which I found pretty surprising. So, they probably have a very lightweight server that runs remix server-side. It's running on Express on a whole bunch of different servers um, and then we'll send that data.

up to the client side. What else did we find out about it? They are using Azure for their CDN to send everything on up. So, I do not think they were running on Vercel previously, but I do not see any of the little sniffing that I usually see when something is running on Vercel. They are using Tailwind for styling. They are not using any actions as far as I can see. So, in Remix, the ability to submit data via a form or run a server function from the client is called an action. And as far as I can see via this manifest, you can often see this has action false. There is nothing there that says has action true or has client action true. So, it doesn't look like they are using too many of the other features of Remix except for the initial rendering in the fantastic router. So, the big question is why did they move to Remix? I think that they did that because, A, they have a fantastic router in Remix that lets you do things client-side if you want to.

Next.js can do stuff client-side, but it really doesn't make that much sense, and honestly, you're going to be battling against Next.js to do everything client-side if that's what you want. We are seeing most applications swing to the server, which is why I thought this was interesting. But, uh, OpenAI is not just a website; it's not just a Next.js application. They have their own server, they have iOS apps, they have a desktop application that's built in Electron. So, in most of their heavy lifting, it's done via the API, and the Remix application is a way to interact with that type of thing. So, I think that building this type of thing in Remix is probably a lot easier. Um, and then second, the loader API in Remix is very good for being able to collect the data that you need for that initial render, dump it into the document via this window Remix, uh, not Remix manifest, but the window.Remix content variable, and then you can pick it up on the client side and quickly do a render. This

application. It doesn't need any of the benefits of like there's no SEO that needs to be done. There isn't a ton of heavy server rendering. There's no database querying. Again, that's all being done via the API. The auth is taken care of via remix, though you can log in, and it sends the cookies on over. There's lots of streaming, lots of streaming back and forth, which is done via websockets or server-sent events, so that's not even something that they need to worry about. Lastly, remix runs on Vite, and Vite is freaking fantastic. It is so lightweight. You're able to bring a remix app into Vite instead of the other way around. Next.js runs on Webpack, and they've been working for many years to write the next generation of Webpack to make it faster, to make the dev server even better, and they're working really hard on that thing called Turbo Pack, which I'm excited for. But there's lots of special sauce in the Next.js dev server, and I have hit so many

issues where this works in V just fine. This works in regular JavaScript just fine, but as soon as you have to introduce it to the webpack flow, you start getting into trouble. You get all these errors, and it's honestly quite exhausting. And this is, I'm saying this, as somebody who loves Next.js. I think I have four or five production Next.js applications. I'm still going to use Next.js. I use Remix as well, but I just wish that Next.js ran on V. V is so fantastic. I just think Remix is probably a much more flexible thing for what they're trying to do here, and that's why they made the migration. So hopefully, you hear a little bit more information from them as to why this happened, but that's my two cents.

Why did OpenAI move from Next.js to Remix?

Scripts