I want to believe that this is the start of dying for a hype "let's run everything on a server!". Suppose, OpenAI looked at a Vercel's bill and started to pull their hair off.
Kind of interesting move since ChatGPT needs to render all kinds of stuff on the client and needs a package for each complex type. Syntax highlighting for example - some good demos where you just send back the highlighted HTML and don't need to load the highlighter package on the client.
In my experience with several large frontends, Vite is extremely slow compared to a compiled production webpack build. Like, so bad it's not even funny. The time you think you are saving with a "faster" dev server (all it does is move compilation work to the browser so you are staring at a white screen in Chrome instead of a loading progress in the console) is actively harming your end users.
@@gamechannel1271 Did you configure your Vite prod build wrong? It’s using Rollup to build for prod. They are very fast and typically much smaller bundles than webpack. So far Vite outperforms webpack in both dev and prod at my work.
@@gamechannel1271 Intesting. In my case, I wish all of my projects (regardless of size) were using Vite. I don't think the prod build of Vite is that much a different than Webpack (both bundled everything)
@@gamechannel1271vite was always faster for me Webpack was always slow for me We have been delivery medical software serving 10 of thousands of users doing heavy image processing for many hospitals and universities Difficult for me to see how in the world webpack is faster
@@Riverhill-AI I didn't say that. I said Vercel's latest creation serves to make more money for the company by consuming more bandwidth, and OpenAI doesn't need to use it on any other hosting service while they can achieve the same without it. Also... this is an SPA, they don't need an SSR first framework.
I built my first chat ui several years ago. The changes in the Next.js ecosystem towards ssr are completely useless for chat bot stuff. It makes more sense to do client side to have streaming directly to the client from the inference services. I would imagine next to be total overkill for them.
If the stuff you stream is just text, then you are probably right. If you have a bunch of components that can be rendered based on the response (e.g. v0), then RSCs really shine
That's pretty smart! On CSR, sending a JSON to configure a new view, when all the JS needed is already downloaded, makes it the most minimal amount of info you can send back. I like it!
I made the move from Next to Remix a while ago. Because I have to maintain Next projects that are live, I can tell the difference and I absolutely love Remix. Slightly different paradigm, but I fully appreciate it.
If you're building a giant application like ChatGPT you still benefit from traditional patterns like having a more separate backend and frontend, otherwise you'll be maintaining multiple backends. Next definitely has its place but that's with medium to small sized applications.
As you mentioned, using NextJS for such a client heavy application is like battling against its core idea of server first. I would say that if a web app is super interactive - consider going client side. Great video!
remix is simple and fun, you can do a lot of things with it, you dont need to kown hundreds of concepts to launch a website, i mean I really apreciate that, is the unique JS framework that i love, although I am using htmx with go, but if I have to came back to use JS frameworks, Remix will be my weapon indeed.
The thing I really like about Remix is that you can have your own custom server and they make it really easy to do so, so you can have a simple light-weight monorepo.
I feel so old. I have been on the information super highway since the XMosaic days (1994). I have never heard of remix. Every other month there is a new/best/final/GOAT framework, I have lost track. :-(
@@WesBos the loader function is embedded in the route children for createBrowserRouter. Honestly, I absolutely love it. Despite the file routing structure being somewhat complicated, it works very well.
You can already do this on Next. Not everything is server side on a next app. I have a client side only video editor app built on next and hosted on cloudflare
I really enjoy this type of videos. Would be cool with a series of "Dissection of services" where you highlight the gems (like the blocking script for the theme).
Really good explanation of tradeoffs in frontend frameworks in this case Next js vs Remix. I think they choose Remix for easier refactoring. It will be interesting to see if they will use signals from Angular or Solid
Videos like this show that sometimes big corporates themselves don't actually go with the "in thing" - using remix not next.js, using express which was supposed to have died a few years ago, CSR not SSR, no SEO, using electron which is supposedly bloatware, etc. And in some of those instances they actually make sense. For me SSR is really just transferring the burden of rendering web content from the client back to the server. This either translates into a hefty bill from my host, or a heavy load on my servers which also translates into hefty bills in the form of extra CPUs or higher power bills. So not everything needs to be "next", sometimes a "remix" is better.
I have been using Next.js in production (self hosted, not Vercel) for multiple years now, mostly in client-side apps. I don't get the comments saying Next.js is not recommended for SPAs. The new app router defaults to server components, but it does not force you to use them. "use client" is fine if you don't want SSR. Server actions are not mandatory as well. Am I missing something?
@@OrigamiSage not all components. You can use dynamic import then use other component that you want to prerender instead. Or use page router if you dont want prerender.
@@iamZBRais Yes and no. According to Next.js documentation, both server and client components get pre-rendered on the server for the initial page load, however on the subsequent navigations they get rendered on the client only. And as @edgardevelops pointed out, there are ways to opt-out of the pre-rendering behaviour.
Great video! I have two Next.js app router applications running in production. The app router is quite good but as it renders everything on the server first and then hydrates the client is annoying. This leads to a lot of hydration errors resulting in app crashes even if you mark the component with "use client" directive. Remix on the other hand does it pretty well by exposing actions and loaders (btw next.js pages router was also good at this). Plus next.js is not pretty good with graphql backends specifically where there is a custom authentication system with token rotation and all. The middleware just suck in next.js app router it is worst and can hit the rate limit pretty quickly. Good they moved to remix!
You bought me over immediately saying Next.js should just run on Vite. They've given years to Turbopack and it still slow and has a lot of issues whereas Vite has never had any of them
I've done both. I've done same apps in both, and I can tell you. Remix is much easier to maintain and reason about. But that isn't enough of a reason to move the entire codebase I guess :)
I've seen this comment a million times, Next.js !== Vercel. Of course it's easiest to host with Vercel, but very doable to host on your own servers or other hosts - especially with OpenAI's Engineering team. I've have apps running on Cloudflare and Render Droplets.
@@WesBos Vercel does so much magic behind the scenes. We have a mem leak and it doesn't happen when deployed with Vercel, but happens when deployed in k8s.
@@WesBosNext on CF is not the same as Next on Vercel. I have an app hosted on CF which runs well but doesn't have all the features of running it in a node environment
@@clamentjohn which features? It's pretty close - even the RSC revalidation stuff works really well. Plus cloudflare's node compat is very close to node as well
Is that not just stateful vs stateless? I don't think is vercel magic, more like different architectures. If you have a memory leak in vercel it may be fine because the functions are serverless and only ever live for a few minutes, while if you are using next js with a long living server, a memory leak will only get worse. I agree that vercel does a lot of magic but this is not a good example imo. @@carlosdubon8539
One thing people might not realise is that while ChatGPT moved to remix and they do CSR, they still have a server that runs the server loaders and actions. As shown at the start, the loader data was in the html that was provided by the server. Only the rendering is done on the client.
Big reason is the router. You *can* use react-router + vite standalone, but at that point... you're just using Remix with a 10% worse experience. Remix adds a bit of structure with file-based routing and data loading you can reach for even in a client SPA
They are using the Remix server though: Data Loaders, Hydration, routing, URL hooks, hosting adapters, 404 pages, etc... you lose most of that going 100% SPA without a JS server
I didn't think my fav takeaway would be the theme set to avoid flash lol. Tho I think I did similar thing already in sveltekit but I'll still compare notes with open ai. Reputable source to copy lol
This is just a confirmation to let you know that next js is good, chat gpt has become a very big thing and maintainance would definitely become a very crucial stuff. Unless you have another chatgpt you don't have to worry about this.
Sounds like a case of honing the idea of "the right tool for the right job", as in "a better tool for THIS job" I guess as a brutal simplification, Next.js and leaning more toward Server rendering is best for static data - big information heavy websites - very little "application". Remix is hotter on WebApps - I mean, it's a weird split, right? - Is it a website or is it a WebApp - it's kinda obvious though. ChatGPT is an app. UA-cam? - yeah, it's an App. Wikipedia? - big old static website. It's great we have these tools that can do both, but maybe do one aspect better. I guess you choose based on how much of your web presence is application focused (real time data) and how much is static?? content focused (long living immutable?? data) Great video, BTW. Made me think.
Because they do not know that Remix announced it would stop being maintained for a looooong time. If they're aware of that, then they didn't migrate to Remix, they effectively pre-migrated to React Router v7.
i will try not to make too grandiose a statement, but from a philosophical data and computational perspective client side rendering seems much better. Since so much resources go into building distributed systems, and every computer and smart phone now is at some relative stand point a "super computer", why would you not offload rendering to those willing computers? Data is harder to argue one way or the other, because client rendering can requires X amount of js before it can render json. There's the classic example of parsing/rendering markdown saves X amount of data with RSC. But I think it's actually edge cases where that is the case. So many sites are just basic skeletons that need some json to hydrate, and I can't understand how streaming html pages after most clicks is somehow less data than json payloads for client rendering. That's not even to say RSC is without merit, but I'd imagine the cost of development far exceeds the benefit in most cases.
SSR just looks visually eye pleasing, that is why it has been popularized, and search engines like Google demand better rendering for SEO. However with suspense in React now, making visually pleasing client-side loading is much easier than it used to be. Also, companies like Vercel make an ass load of money from anything done server side, so they obviously encourage it. The actual React team has been focused on more client-side features, lately, which shows some of the disconnect and why vendor lock-in can suck. Personally, I try to stick to statically generated for things that need SEO, and client-side for internal apps.
I bet they got tired of having to rewrite their app to keep up with Vercel's endless paradigm shifts and experiments in developer lock-in... sometimes even with minor release versions. NextJS is fast to spin up mostly thanks the templates freebies but on projects that need to be maintained and keep current to the ecosystem for longer than 6 months the regret starts building VERY quickly. No regrets prioritizing Vite + Astro depending on the project. Especially Astro for all the major big additions and improvements I have been able to upgrade MAJOR versions 2 -> 3 -> 4 on projects with almost no code changes.
Let me reword this crazy hype new terrifying mega news shock omg for you lot: "Company changed framework from a great one to another great one more optimized for their use case"
They likely got a surprise larger bill of Vercel. Move their complete platform from Vercel in response including got rid of Next.js because Vercel was using the fact that open ai was running on Next.js in their marketing 😅 sometimes the reason are not that complex
Good Move! 👍🏻Though never used remix at all. But NextJS really disappointing despite it's developed by such big commercial organisation. Frequently dramatical changes in APIs, poor and confused documentation, hardly find answers from their official document. Just like in each version, they "suddenly figure out" something and then in the next version they change their mind again. Time use to debug the framework itself far more overweight the time you spend on your own code🤷🏻♂
Speaking in a professional opinion Next js is do do. There is a lot more better ways of doing things. In all regards there is a reason why the choice was made. If you do use next js and works for you that is great. It's better to have options instead of being forced to an option not of your liking.
Looks like they are still using NextAuth for authentication thou. I've an extension for chatgpt to upload large PDF files to the chat, and none of my features are broken. Impressive integration haha
What's more horrific than knowing humanity will be subverted by the AI that it built is that it'll be run generally by self-generated JavaScript, a language needing to be compatible with 1995 web browsers.
remix just let react do what react can and they do the additional thing needed to build full app while next use react just for templating and do everything themselves it would haven been better if the renamed react-router to remix-router that might cause some confusion so they gave up their branding for the greater good
So if you're not using next, and going for react vite + react router, is it just better to use remix than ? Currently I'm using next, more jobs around my city. But i should check out Remix as well
It’s a lot simpler than you’re making it. It comes down to money. It always does. This is way more obvious than it’s made out to be. There was a deal somewhere that someone pitched. They accepted it. They all win.
I always said SSR is mainly for SEO purposes, it's enough to do some SSR on meta tags. Doing SSR for internal tools are a waste of server resources (this is what Vercel wants with Next.js). But people keeps doing SSR for admin panels xD
Saying that SSR is just for SEO clearly means you don't understand SSR. There is a clear benefit in rendering html server side as it's closer to the database and will result in faster load times. Especially for "admin panels".
yep exactly, plus no need to load deps or do logic on client. Lots of good reasons to do it on the server - and I think it's the future for most apps. ChatGPT just has their own set of problems to solve and made this decision
@@o_glethorpe depends - on my site I have a syntax highlighter than is several megs. The bandwidth for that would be huge, cheaper to compute once on the server and cache the HTML
@@hello19286 "faster loading time" for the first render. And for apps, where people spend hours, first render does not matter nearly as much. So he's right and you're wrong.
Actually I found remix is good in concept, exhausting to prepare a project, also in my case I had to create a custom server to meet my requirements, but once done its can be good, note that there is no more "Remix" since it will be "React Router" only , it will be more like a set of components instead of a framework, I guess Remix is dying :)
No - they are still using the server part of Remix to collect the page data with loaders for a fast initial load, auth, routing, caching, etc.. A lot more than CRA
Wait!! The whole point of switching to Next.js was it was offering Server side rendering. Now again client side rendering will not hinder the efficiency?
Plot twist. Chat GPT wrote itself in Remix. Open AI devs don't even know.
😂
I want to believe that this is the start of dying for a hype "let's run everything on a server!". Suppose, OpenAI looked at a Vercel's bill and started to pull their hair off.
Kind of interesting move since ChatGPT needs to render all kinds of stuff on the client and needs a package for each complex type. Syntax highlighting for example - some good demos where you just send back the highlighted HTML and don't need to load the highlighter package on the client.
@@WesBosopenai is the kind of app that can takes even a 5sec splash screen and cache the huge bundle chunks, and nobody would call it slow
@@JagaSantagostino and then users leave it open for 9 days straight - kinda like desktop/mobile apps.
@@WesBosLol that's what I always do I always have a pinned chatgpt tab at least in one of my browser windows
Odd flex. Client heavy UI isn’t good design unless absolutely necessary.
Remix is simply great, happy to see big companies adopting it!
It is merged with React Router. Do we know if there gonna be new versions of it?
Bell curve meme, "just use express and react router / (one billion libs and frameworks) / just use express and react router"
😆
Sample repository
i am proud to announce that i can visually imagine this meme in my head and understand it (:
go back to PHP plus FTP
“just query a database and print to the screen” / (one billion libs and frameworks) / “just query a database and print to the screen”
Vite is SO fantastic. Yeah remix makes sense more than next in their situation for sure
I didn’t know Remix run on Vite.
I might ditch Next.js just for this
In my experience with several large frontends, Vite is extremely slow compared to a compiled production webpack build. Like, so bad it's not even funny. The time you think you are saving with a "faster" dev server (all it does is move compilation work to the browser so you are staring at a white screen in Chrome instead of a loading progress in the console) is actively harming your end users.
@@gamechannel1271 Did you configure your Vite prod build wrong? It’s using Rollup to build for prod. They are very fast and typically much smaller bundles than webpack. So far Vite outperforms webpack in both dev and prod at my work.
@@gamechannel1271 Intesting. In my case, I wish all of my projects (regardless of size) were using Vite. I don't think the prod build of Vite is that much a different than Webpack (both bundled everything)
@@gamechannel1271vite was always faster for me
Webpack was always slow for me
We have been delivery medical software serving 10 of thousands of users doing heavy image processing for many hospitals and universities
Difficult for me to see how in the world webpack is faster
because Vercel bandwidth charges are outrageous and latest Nextjs is very hard on the bandwidth. like an ELEPHANT.
Why do you think OpenAI is hosting ChatGPT on Vercel? I am a little confused.
@@Riverhill-AI I didn't say that. I said Vercel's latest creation serves to make more money for the company by consuming more bandwidth, and OpenAI doesn't need to use it on any other hosting service while they can achieve the same without it. Also... this is an SPA, they don't need an SSR first framework.
I'm not freaking out. Remix is great.
I built my first chat ui several years ago. The changes in the Next.js ecosystem towards ssr are completely useless for chat bot stuff. It makes more sense to do client side to have streaming directly to the client from the inference services. I would imagine next to be total overkill for them.
except Vercel has a large chat product called v0 where the server rendered parts really shine
@@WesBos Hit the nail on the head
@@WesBosI’ll take another look then. I feel like I’m missing something cause your example and the shining aren’t immediately clicking with me
@@WesBos This is interesting
If the stuff you stream is just text, then you are probably right.
If you have a bunch of components that can be rendered based on the response (e.g. v0), then RSCs really shine
That's pretty smart! On CSR, sending a JSON to configure a new view, when all the JS needed is already downloaded, makes it the most minimal amount of info you can send back. I like it!
Been using Nextjs for a while and glad to see alternatives getting the spotlight.
what you came here for is at 7:35 🤦♂
I made the move from Next to Remix a while ago. Because I have to maintain Next projects that are live, I can tell the difference and I absolutely love Remix. Slightly different paradigm, but I fully appreciate it.
All projects are live. What do you mean ?
oh first time I get recommend for your content, I've seen you trending on my twitter a lots.
Just saw Ryan Florence post and find this video Thanks for explaining the reason ❤
If you're building a giant application like ChatGPT you still benefit from traditional patterns like having a more separate backend and frontend, otherwise you'll be maintaining multiple backends. Next definitely has its place but that's with medium to small sized applications.
As you mentioned, using NextJS for such a client heavy application is like battling against its core idea of server first. I would say that if a web app is super interactive - consider going client side.
Great video!
remix is simple and fun, you can do a lot of things with it, you dont need to kown hundreds of concepts to launch a website, i mean I really apreciate that, is the unique JS framework that i love, although I am using htmx with go, but if I have to came back to use JS frameworks, Remix will be my weapon indeed.
The thing I really like about Remix is that you can have your own custom server and they make it really easy to do so, so you can have a simple light-weight monorepo.
I feel so old. I have been on the information super highway since the XMosaic days (1994). I have never heard of remix. Every other month there is a new/best/final/GOAT framework, I have lost track. :-(
remix is not new .
@@musashi542 remix is 2020. next.js is 2016. I bet there is a new one around the corner
@@michaelraasch5496 Tanstack start just went alpha so...
@@michaelraasch5496 You were right, now we have TanStack as well
All few months there is a "new hot shit" and everyone goes like "forget everything you've done and learn this new shit because otherwise you're lame".
the most hilarious part is that Remix has already said its "going away" and turning back into react router
@@WesBos they might then look into Sveltekit
@@WesBos the loader function is embedded in the route children for createBrowserRouter.
Honestly, I absolutely love it. Despite the file routing structure being somewhat complicated, it works very well.
Incorrect. They said it will take a nap until RR7, but it is def not going away😂
React router is not new hot shit, it is a very stable and robust solution, that reduces some complexity in comparison of next
They propbaly wanted to mvoe some computation to the client-side and use the server less
and use 'less server'
You can already do this on Next. Not everything is server side on a next app. I have a client side only video editor app built on next and hosted on cloudflare
The incremental step to rendering HTML on the server vs JSON isn't much, and if anyone has the compute for it, it's OpenAI.
@@WesBosidk man, they are kinda burning through billions very fast. Everyone’s optimizing costs in this economic environment 😂
@@weiSane soon they will just run the models on our computers instead
I really enjoy this type of videos. Would be cool with a series of "Dissection of services" where you highlight the gems (like the blocking script for the theme).
Imagine being in the middle of a nextjs project with openAI, and something new comes along. This is exhausting
Really good explanation of tradeoffs in frontend frameworks in this case Next js vs Remix. I think they choose Remix for easier refactoring. It will be interesting to see if they will use signals from Angular or Solid
Videos like this show that sometimes big corporates themselves don't actually go with the "in thing" - using remix not next.js, using express which was supposed to have died a few years ago, CSR not SSR, no SEO, using electron which is supposedly bloatware, etc. And in some of those instances they actually make sense. For me SSR is really just transferring the burden of rendering web content from the client back to the server. This either translates into a hefty bill from my host, or a heavy load on my servers which also translates into hefty bills in the form of extra CPUs or higher power bills. So not everything needs to be "next", sometimes a "remix" is better.
I have been using Next.js in production (self hosted, not Vercel) for multiple years now, mostly in client-side apps. I don't get the comments saying Next.js is not recommended for SPAs. The new app router defaults to server components, but it does not force you to use them. "use client" is fine if you don't want SSR. Server actions are not mandatory as well. Am I missing something?
Clearly
You still get SSR, as all components get rendered in the server first regardless of “use client”.
@@OrigamiSage not all components. You can use dynamic import then use other component that you want to prerender instead. Or use page router if you dont want prerender.
@@OrigamiSageNo, break into components which needs to be rendered on client side and "use client"
@@iamZBRais Yes and no. According to Next.js documentation, both server and client components get pre-rendered on the server for the initial page load, however on the subsequent navigations they get rendered on the client only.
And as @edgardevelops pointed out, there are ways to opt-out of the pre-rendering behaviour.
Great video! I have two Next.js app router applications running in production. The app router is quite good but as it renders everything on the server first and then hydrates the client is annoying. This leads to a lot of hydration errors resulting in app crashes even if you mark the component with "use client" directive. Remix on the other hand does it pretty well by exposing actions and loaders (btw next.js pages router was also good at this). Plus next.js is not pretty good with graphql backends specifically where there is a custom authentication system with token rotation and all. The middleware just suck in next.js app router it is worst and can hit the rate limit pretty quickly.
Good they moved to remix!
Haven't watched the video yet cause busy. Just wanted to quickly chime in that Remix is awesome! Love the emphasis on working with web standards.
This is the video preview I was waiting for.
why is this a concern man????
because chat gpt itself recommends it
Marko are doing the same thing. Facebook and Whatsapp both use Marko now. It's kind of like Astro, but even more minimal with less code
wow... so they switched from react, thats wild
On which platform they use Marko.js?
You bought me over immediately saying Next.js should just run on Vite.
They've given years to Turbopack and it still slow and has a lot of issues whereas Vite has never had any of them
remix is just beautiful. I highly recommend it.
Recently Netflix moved thier login page to vanilla js from react, now this. What's going on?
I've done both. I've done same apps in both, and I can tell you. Remix is much easier to maintain and reason about. But that isn't enough of a reason to move the entire codebase I guess :)
Think they also just want to get off of Vercel's books.
I've seen this comment a million times, Next.js !== Vercel. Of course it's easiest to host with Vercel, but very doable to host on your own servers or other hosts - especially with OpenAI's Engineering team. I've have apps running on Cloudflare and Render Droplets.
@@WesBos Vercel does so much magic behind the scenes. We have a mem leak and it doesn't happen when deployed with Vercel, but happens when deployed in k8s.
@@WesBosNext on CF is not the same as Next on Vercel. I have an app hosted on CF which runs well but doesn't have all the features of running it in a node environment
@@clamentjohn which features? It's pretty close - even the RSC revalidation stuff works really well. Plus cloudflare's node compat is very close to node as well
Is that not just stateful vs stateless? I don't think is vercel magic, more like different architectures. If you have a memory leak in vercel it may be fine because the functions are serverless and only ever live for a few minutes, while if you are using next js with a long living server, a memory leak will only get worse. I agree that vercel does a lot of magic but this is not a good example imo. @@carlosdubon8539
whoa my eyes! light mode Wes!
ExpressJs FTW! Remix - The VC in your MVC app.
Hydration with a bunch of data reminds me on Inertia.js with Laravel. Works seamlessly.
One thing people might not realise is that while ChatGPT moved to remix and they do CSR, they still have a server that runs the server loaders and actions. As shown at the start, the loader data was in the html that was provided by the server. Only the rendering is done on the client.
If you’re not using server actions, why not just use Vite directly? What benefits does remix offer?
Gives you the option to use server actions in the future + gives you a router and a bunch of other things
Big reason is the router. You *can* use react-router + vite standalone, but at that point... you're just using Remix with a 10% worse experience. Remix adds a bit of structure with file-based routing and data loading you can reach for even in a client SPA
seo
They are using the Remix server though: Data Loaders, Hydration, routing, URL hooks, hosting adapters, 404 pages, etc... you lose most of that going 100% SPA without a JS server
EVERYTHING 😂
Loving your content... Cheers!
why everybody making hype about it??? i don't understand, like marvel just announced some movie, or am I missing somethinh
everyone is leaving Vercel now?
Not me and my projects with 3 users
Once you hit scale its worth re-evaluating, but there is a reason Vercel is so popular - its just so dang easy
@@WesBosAnd also so problemstic especially when they force you to upgrade your next version, which can be tough so often for huge apps especially
@@WesBoswhich alternative cheaper we have? Thanks you
MASTERCLASS
I didn't think my fav takeaway would be the theme set to avoid flash lol. Tho I think I did similar thing already in sveltekit but I'll still compare notes with open ai. Reputable source to copy lol
For the frontend, Remix feels like react with ssr, next feels like ssr with react
I just love thumbnail!
This is just a confirmation to let you know that next js is good, chat gpt has become a very big thing and maintainance would definitely become a very crucial stuff. Unless you have another chatgpt you don't have to worry about this.
Sounds like a case of honing the idea of "the right tool for the right job", as in "a better tool for THIS job"
I guess as a brutal simplification, Next.js and leaning more toward Server rendering is best for static data - big information heavy websites - very little "application".
Remix is hotter on WebApps - I mean, it's a weird split, right? - Is it a website or is it a WebApp - it's kinda obvious though.
ChatGPT is an app.
UA-cam? - yeah, it's an App.
Wikipedia? - big old static website.
It's great we have these tools that can do both, but maybe do one aspect better.
I guess you choose based on how much of your web presence is application focused (real time data) and how much is static?? content focused (long living immutable?? data)
Great video, BTW. Made me think.
First time looking at literally any SPA application made since the dawn of SPA? "running remix on Express". :) dude!?
I always wander why SPAs don't do exactly this 3:28 to provide better UX and better perception of speed. Remix move might actaully be the right move.
Because they do not know that Remix announced it would stop being maintained for a looooong time. If they're aware of that, then they didn't migrate to Remix, they effectively pre-migrated to React Router v7.
i will try not to make too grandiose a statement, but from a philosophical data and computational perspective client side rendering seems much better. Since so much resources go into building distributed systems, and every computer and smart phone now is at some relative stand point a "super computer", why would you not offload rendering to those willing computers? Data is harder to argue one way or the other, because client rendering can requires X amount of js before it can render json. There's the classic example of parsing/rendering markdown saves X amount of data with RSC. But I think it's actually edge cases where that is the case. So many sites are just basic skeletons that need some json to hydrate, and I can't understand how streaming html pages after most clicks is somehow less data than json payloads for client rendering. That's not even to say RSC is without merit, but I'd imagine the cost of development far exceeds the benefit in most cases.
SSR just looks visually eye pleasing, that is why it has been popularized, and search engines like Google demand better rendering for SEO. However with suspense in React now, making visually pleasing client-side loading is much easier than it used to be. Also, companies like Vercel make an ass load of money from anything done server side, so they obviously encourage it. The actual React team has been focused on more client-side features, lately, which shows some of the disconnect and why vendor lock-in can suck. Personally, I try to stick to statically generated for things that need SEO, and client-side for internal apps.
More Remix content please!
For the past month i have been getting lag spikes when sending prompt, let's see if this migration fixed it
Biggest flex is you haven’t used chat GPT since may
Claude Sonnet 3.5 has been killing it to be honest
@@justin.johnsonYupe but recently I paid for it and the quality is so bad
So I see a switch ChatGPT free is better
Llama 3.1, Claude 3.5 Sonnet, even Claude 3 Haiku,
all were delivering better results than GPT...
Is Claude good enough for code now? I haven't used it in over a year, but willing to give it a shot.
Lmaoo aged horrible
great vid, thank you!
I bet they got tired of having to rewrite their app to keep up with Vercel's endless paradigm shifts and experiments in developer lock-in... sometimes even with minor release versions. NextJS is fast to spin up mostly thanks the templates freebies but on projects that need to be maintained and keep current to the ecosystem for longer than 6 months the regret starts building VERY quickly. No regrets prioritizing Vite + Astro depending on the project. Especially Astro for all the major big additions and improvements I have been able to upgrade MAJOR versions 2 -> 3 -> 4 on projects with almost no code changes.
That thumbnail UA-cam face tho 😅
Let me reword this crazy hype new terrifying mega news shock omg for you lot:
"Company changed framework from a great one to another great one more optimized for their use case"
Can you give the new angular a shot please?
Chatgpt seems to get worse every day. It constantly freezes, conversations are not found or uploads fail.
exodus of talent, and they began bringing in pre-Musk/ex-Twitter folks
Makes sense, they don't really need server rendering for ChatGPT. Cheaper to run too.
I can't imagine it makes a big difference cost wise tbh
They likely got a surprise larger bill of Vercel. Move their complete platform from Vercel in response including got rid of Next.js because Vercel was using the fact that open ai was running on Next.js in their marketing 😅 sometimes the reason are not that complex
Why do you think OpenAI is hosting ChatGPT on Vercel? I am a very confused.
Just because Vercel developed next js, which is open source btw, doesn't mean that you have to host it on Vercel cloud.
@mateidumitrescu238 self-hosting Next.js for years. But they were hosting their frontend on Vercel earlier this year... so something has changed 🤔
Self hosting nextjs is actually easier than say pure react.
Me not even noticing anything changed apart from some highlighting on text lmao
Only because they use next.js does not mean they are forced to host on vercel they can do it on azure which is what they are probably doing anyways.
Good Move! 👍🏻Though never used remix at all. But NextJS really disappointing despite it's developed by such big commercial organisation. Frequently dramatical changes in APIs, poor and confused documentation, hardly find answers from their official document. Just like in each version, they "suddenly figure out" something and then in the next version they change their mind again. Time use to debug the framework itself far more overweight the time you spend on your own code🤷🏻♂
Speaking in a professional opinion Next js is do do. There is a lot more better ways of doing things. In all regards there is a reason why the choice was made. If you do use next js and works for you that is great. It's better to have options instead of being forced to an option not of your liking.
Wait wait wait wait wait you are the guy from Syntax
Looks like they are still using NextAuth for authentication thou. I've an extension for chatgpt to upload large PDF files to the chat, and none of my features are broken. Impressive integration haha
What's more horrific than knowing humanity will be subverted by the AI that it built is that it'll be run generally by self-generated JavaScript, a language needing to be compatible with 1995 web browsers.
The next step is moving to htmx
yeh i dont get turbopack either. Vite has been the way to go for some time now.
remix just let react do what react can and they do the additional thing needed to build full app while next use react just for templating and do everything themselves
it would haven been better if the renamed react-router to remix-router that might cause some confusion so they gave up their branding for the greater good
So if you're not using next, and going for react vite + react router, is it just better to use remix than ?
Currently I'm using next, more jobs around my city. But i should check out Remix as well
It’s a lot simpler than you’re making it. It comes down to money. It always does. This is way more obvious than it’s made out to be.
There was a deal somewhere that someone pitched. They accepted it. They all win.
Why does ChatGPT need server-side rendering? It's not like they are cashing the interactions with users.
I always said SSR is mainly for SEO purposes, it's enough to do some SSR on meta tags.
Doing SSR for internal tools are a waste of server resources (this is what Vercel wants with Next.js). But people keeps doing SSR for admin panels xD
Saying that SSR is just for SEO clearly means you don't understand SSR. There is a clear benefit in rendering html server side as it's closer to the database and will result in faster load times. Especially for "admin panels".
yep exactly, plus no need to load deps or do logic on client. Lots of good reasons to do it on the server - and I think it's the future for most apps. ChatGPT just has their own set of problems to solve and made this decision
@@WesBosif this logic could be done on the client you are just waisting money doing on the server
@@o_glethorpe depends - on my site I have a syntax highlighter than is several megs. The bandwidth for that would be huge, cheaper to compute once on the server and cache the HTML
@@hello19286 "faster loading time" for the first render. And for apps, where people spend hours, first render does not matter nearly as much. So he's right and you're wrong.
The triangle company would not like this
No seo required so why all the pain points next.js brings....
Angular, React, Vue, Nest.js, Next.js, Remix... what will come next week?
30MB just for pure text site :D:D
Nextjs is Remix in disguise
Haven't they heard of something called "Nuxt"? 😊
Are they confused? Didn't they use Nuxt prior to using Next?
Finally! Sanity
what chome dev tools customization is that. which lets you hide tab names like elements,sources,network,performance etc?
MS Edge - its the Chrome dev tools but they skinned them so nicely
but now I prefer to use fasthtml that's the most crazy framework
Client rendered but needs Remix? Interesting
Express is back babe ☺
Actually I found remix is good in concept, exhausting to prepare a project, also in my case I had to create a custom server to meet my requirements, but once done its can be good, note that there is no more "Remix" since it will be "React Router" only , it will be more like a set of components instead of a framework, I guess Remix is dying :)
So essentially they're using Remix as a replacement for CRA? Its nothing to do with Next, but making a SPA
No - they are still using the server part of Remix to collect the page data with loaders for a fast initial load, auth, routing, caching, etc.. A lot more than CRA
So this was all to move to Azure.
Next js is also really good at being a spa and client rendered javascript on the client. Its not that hard to set up.
Wait!!
The whole point of switching to Next.js was it was offering Server side rendering.
Now again client side rendering will not hinder the efficiency?
I'm waiting for the day they migrate to sveltekit
Remix is ❤
their sever load went from 100 to 10
What software did you use to record this?