All the ways HTML gets to your browser

there's a lot of different ways to render your web apps it used to just be you send HTML to the user then it was you sent JS to the user and let them do everything and now we're in this crazy era where everything's kind of mangled together there are benefits there are negatives there's a lot to understand and I just spent way too much time diagramming it all out this is some of the most intense time I've spent trying to explain all of these parts I think this is one of my best videos so I

hope you stick through with it it didn't start as me trying to explain all of these things it started with this awesome article from ran carniato about how JavaScript Frameworks are changing in 2025 keep an eye out for that cuz it's going to come out soon after this sorry if the editing and orchestration of this one feels a bit weird the realization we had halfway through is this video was too good by itself to be part of that so yeah if you want to better understand all the different types of rendering how they work and

how these affect Frameworks like Astro next Nu felt solid and everything else this is one of those rare videos where you're actually going to learn a lot about how the different web Technologies fundamentally work I'm real proud of this one stick through the end if you can if you want to hear and understand what these four things are but first a quick word from today's sponsor today's sponsor is Clerk and they make more than nice charts they make the best off platform and this is coming from someone who was super skeptical I really didn't think

an O platform was something I wanted because it's not too hard to roll your own o right kind of as soon as you have to maintain it it falls apart once you start building components for it it gets annoying at best complying with Google's weird rules about the logo color matching and the size being right and dealing with policy changes from any of these companies managing your refresh tokens That Vary per there's so much and I've been to Hell in back managing o on the platforms that I did it myself on I tried clerk cuz

I needed o for react native and I fell in love really fast now it is the off platform we use for every single product that we build if I shipped it in the last 3 years and it has a signin button it's powered by Clerk and I never thought I would be here saying that and I'm far from the only one saying this we got everyone from GMO the CEO of versel CEO of bassub in here this weird Theo guy I don't know what he does or how he snuck in Paul Cobblestone from subase even

crazy because they have off built in too but he even thinks clerk is worth using especially once you need to set up stuff like SSO MFA and all the other weird regulatory crap they handle it for you they also handle the components and they are stunning it is literally just the signin component or the user profile component you just Mount those and they look great by default with ex L enough customization it's so good that it inspired us heavily with how we ended up building upload thing we provided components with upload thing because we were

so impressed with the ones that we got from clerk if you're setting up off on your application you should give clerk a shot your first 10,000 active users are free and if they turn in the first day they don't count it's so generous I've been super happy with our experience I bet you will be as well thank you to clerk for sponsoring today's video check them out today at soy. lclark so what are these two pieces here Spa influenced isomorphic and MPA influence split execution I think understanding this will help you a lot with getting

where Frameworks are and where they're going to understand this first we have to go further in each Direction full spa on the left here it will have classic MPA on the right here classic MPA uses a circle as we all know the user goes to a server it's probably going to be better if I draw lines vertically like this for like what goes where so we have the user and we have the server so the user goes to the web page we'll say they go to example.com user goes to the server the server has to

send something back what it sends back is a key distinction to understand here in the classic traditional MPA the server sends back sends full HTML for page and now if the user wants to do something else like say they want to go to a different page here they want to go to example.com slout now the server responds with the full HTML for slab and it's called an MPA a multi-page app because when the user navigates and they click a link they go somewhere it hits the server it says hey this is what I want and

the server responds with it it doesn't literally mean that the server has a file for each of these like it has an index.html it has an about. HTML but it could you could almost think of this like I go to the server it sees that I just have a slash at the end here it knows that needs the index so it goes and it grabs this file this index HTML file and it sends that back down for the user and when we go to about does the same thing it goes and it finds this about

page and it sends the results back to the user but what if the site needs to be dynamic what if I need the HTML to have like my username in or things like that then you would not have the static files instead you would have a function that does something like generate homepage and this function will spit out the HTML that we actually send to the user for that page and when you go to about it might generate about page and this will take in the request do whatever it'll take in the request object maybe

it uses that request object to figure out who the user is so that it can embed the right data in the HTML it generates the point being the HTML creation either happens ahead of time on the server where it makes the pages or on request time where it generates the page based on characteristics of the request and it has to be one or the other maybe your homepage is a static index.html so that can respond immediately but then other Pages need to be generated the point being the server needs to have a page or generate

a page and it needs to do the entire page at once let's contrast this to Classic Spa One Click clarification here before we go further though I'm going to draw a line I'll draw a red line and this is the user clicks a link so the diagram is done here effectively like we've stopped until the user does something else this page will do nothing else until the user clicks something submits something does something no additional traffic happens the user goes to the server they get the HTML they now see the page that's the whole thing

classic Spa a little bit different with the classic Spa we have this index HTML but instead of that index HTML having everything in it it's just going to have a very minimal scaffold usually it's going to look something like head script Source equals app.js title example.com JavaScript is disabled please fix so if you go to a website doing a traditional spa and you go look at the HTML at sending it's going to look something like this I am currently live streaming on Twitch and if I go to my stream here I go to the network

Tab and I disable JavaScript and I reload the page this is all we get this is the entire twitch site until the JS loads I can even copy this HTML and show you just how simple it is so I just went through and deleted a bunch of giant script tags that weren't really necessary they have this inline one for prefers dark mode I'll even get rid of that if you get rid of all the script tags the entire HTML for twitch is 70ish lines of code this is literally 100% of the HTML twitch gives you

minus the JS so what's going on because I go to Twitch and it doesn't look like this what happens is those script tags tell the browser to go grab more JavaScript that does the actual work the page itself has almost nothing on it it has an incorrect title of twitch even though I'm not on Twitch I'm on my channel page here/ Theo the HTML doesn't even have the right tag there which is hilarious because it means if I tweet the link somewhere it has to do extra work to figure out what metadata exists it's just

not there it's hilarious and I know people saying you delet the metatags I didn't delete many of them it does have OG title there but the page title is still twitch which is funny to me you get the point the actual HTML twitch gives you is effectively a static file regard of which page you go to so it doesn't matter if we go to twitch.tv or twitch.tv/ thee primagen or t.tv Theo all of these URLs resolve to the same HTML file that's the key every different page that exists on your single page app that's why

it's called the single page app they're all resolving the same page the same HTML so it doesn't send the full HTML it sends a skeleton HTML and that skeleton HTML it might have literally nothing in the body at all it might have a loading state it might have a no script tag to tell you what's going on when you don't have JavaScript enabled but the key is that it has this script tag so once the response has gotten to the user we then have to make another request we have to go get the JavaScript you

know I'm going to do it in line here go get the JS I like these inline arrows a lot so we go to Twitch tv/ Theo it Returns the static HTML that's basically empty with a JS tag and now your browser has to go get the JavaScript script in order to actually generate the page so then it sends down JS received now the browser to do some things it has to process that JavaScript so browser has to parse and run the JS and we're going to have to make these lines longer and hopefully you're starting

to see why single page apps aren't the right tool for a lot of stuff so the page has to pars and run the JS it then has to hit api. twitch.tv/ get some info this API then goes and hits some other crazy service twitch has the this case it's going to be the graph ql Edge this graph Q Edge is going to do a lot of other crazy we don't need to go into that you could do anything like this with any stack the point being we go there we get the Json response the user

wants this then sends after some amount of time sends Json back I'll move it up a little so it doesn't look quite as brutal so this then sends Json back that goes to the user not as HTML but as a Json blob now the client theoretically finally has the stuff that it needs so the client then uses the Json to create the correct HTML and now finally page is loaded you might look at this and be like Oh Theo you're exaggerating it can't be that many steps I am exaggerating but the other way I'm exaggerating

the other way because in reality you're not only doing one API call here hell you're not only fetching one JS file chances are you fetch those JS files it checks what URL you're on it says oh this URL needs more JS so it goes and fetches even more JavaScript then it has all the JS it needs then it starts to do the things it has to do which is go get the data from the apis and it's not going to do that once either it's probably going to make multiple calls if we again go to

Twitch and I reenable JavaScript did it reenable itself okay it Reena itself the key here is we're going to go to the network tab I'm going to clear it and we're going to God you can't even clear it fast enough I cleared it we're reloading see all the that comes in when you load twitch do you understand how insane that is going to pause the stream even with the stream paused you see all the stuff coming in even if we limit this to just xhr requests which are things that hit endpoints these are all the

APA I calls being made and all of these ones are made before the page has finished showing you things literally dozens of requests have to be made before the user could see things and that's just how a lot of the web works right now and people don't seem to understand that's the the react bad that needs to be understood and it's not because react as a framework is fundamentally flawed it's because when you have the ability to do everything on client you start to but this sucks for so many reasons so many reasons and hopefully

you can see here that it takes this many steps before we can even do a navigation so here we'll have user clicks a link and admittedly this is where single page apps start to be a little bit better because when the user clicks a link we don't have to go anywhere to start showing something else start showing new UI I almost wish I had put another line here for the browser because when the user clicks a link as long as the JS is already loaded for that new page you instantaneously see something you have to

wait for a server the important thing that I want to emphasize here that is hard CU I'm missing a line I really should have put a browser line in here to help indicate this you know what I'm going to do the annoying thing and do that we're going to change this to brow and I'm going to move we're going to make the new line of user I'll put this back here so the user types in twitch.tv Theo user types that the browser then goes to the server gets the mty HTML goes to get the JS

downloads the JS parses and runs the JS goes and makes the API calls gets the Json back Json blob gets rendered and I guess the thing I would draw differently here is after that the Json is used to create the HTML which was results in the page finally being shown to the user and then the user clicks a link the thing that is cool is previously if we were to do the same diagram above the browser would have to go to the server to get something and even though I drew these gaps the same realistically

speaking this one is a lot more so like here way closer and the server is way further so if you don't have to go to the server to do something it feels better there's a lot of ways having everything locally benefits you greatly so when you click a link the user is sending navigate to slash the prime engine if this was built with a multipage app we would have to wait for the server to find the right HTML or generate it send it back and then you will see something but until that moment you get

the little loading bar at the top of chrome like the blue bar that slowly goes across and you don't actually have any feedback that you clicked something until the server is done with a single page app it is different though now weate to the prime engine the browser is going to instantaneously generate a new page it's not an actual new page it's going to change the HTML because again we're in a single page app nothing has changed the HTML that the server sent is still the same so we're going to generate this new page based

on the URL if you're using react router you'll have a certain URL bound to a certain part of the UI and this is how when you change the url it knows which components to render it starts to render those components you see the new UI but one of those components needs some data so after we've generated this we noticed we need more data so request new data for/ the prime this is probably going to be like api. twitch I'll say I'll just put the API call api. twitch.tv getet slthe primagen so now we're going to

the twitch server again to get this data I'll copy paste this part it be exactly the same sends some Json back Json goes to the browser and then the browser uses that Json to generate correct state so up until until then you would probably show like a loading spinner or something and then once you get that Json back now you have all the fun powers to get the right content to the user but what's cool here is you get something immediately the user sees something and it could possibly be everything it's possible you have the

data that's needed cached and now when you click and go to that page everything loads immediately it's really cool for that but it's not for everything it is not for everyone again to compare to Classic MPA I'm going to add that same breakdown here user goes to a link example.com server sends the HTML down now the user sees the result great awesome fun but then the user clicks a link the thing to be considerate of is anytime you cross this Chasm between browser and server you're now waiting so when you go to example.com you now

have to wait a while to get everything back so I send the request and I get the HTML back but I don't have any indication that something's going on other than that loading bar at the top in that time not great and if this was for twitch for example like we on twitch.tv Theo and we go to twitch.tv thee primagen after I click the link I'm still watching Theo's stream for a while up until I get everything back it doesn't change the page I'm on until the server is done and if the server takes a

while to do those things you're screwed this has a lot of catches which is where we're going to start getting into these new models I'll get to those in a bit but first we need to talk about here because the biggest problem in my opinion is this top chunk I would hope we agree the bottom chunk is actually nice it's better in a lot of ways than the traditional multi-page app way of doing things the problem here is the user doesn't see the right content for a while and it has to do all of this

stuff before they actually get the data this is where we get back to these two key parts that Ryan included in the article the spa influenced isomorphic and the mpa influence Ed split execution model the first solution we had to this single page app chaos is actually pretty intuitive when you think about it we'll say SSR Spa what we do differently here is instead of going to the page sending this empty HTML file with a JS tag and the client does all the work we do something quite different we now run react on the server

react server runtime why would we ever want to run react on the server it's actually a pretty simple reason we don't want empty HTML we want complete HTML which now allows us to send that back to the user immediately what's interesting is in parallel while the user is getting that HTML right when they get it we now also know that it has a JS tag still and we can go get that JS tag receive the JS parse and run the JS if it required an API call we can do it but there's a good chance

that your server runtime actually embedded the data in the HTML if you go to something like Ping for example and you look at the HTML Ping's a video call service that I built to make it easier for live streamers to do collabs if we hop in here and we look at nextore data here are the properties that nextjs used to render the page on the server and it embeds them in the HTML so that you don't have to go refetch them once the react code takes over it does a thing called hydration what hydration means

is we have this JavaScript on the client but we also already have HTML written normally what react does is it writes all the HTML for you but if the html's already written how does the react code know which button to trigger the onclick for it figures that out by rerunning the same react code on the client and that's the key the react code runs once here so I'll say I'll I'll label these green first react run so react runs first on the server it might run at build time so it only runs once when you

deploy it might run dynamically so when a user makes a request we generate new HTML with new embedded data the HTML embeds the data needed for this run the Js goes and gets that and then we have the second react run all the way over here in browser land so it runs once on the server either during build or during request embeds all the HTML that is needed including that data and now once we parse and run the JS we can just skip this step we can get rid of all of these things assuming the

server did them anyways like realistically speaking what is actually happening is the server during this react run either goes and hits an external service like your graphql Edge or maybe just hits your database directly so the server hits the database gets the Json back or whatever the server is returning sends that down as HTML to the user with the data embedded the browser then has to go get the JavaScript that it needs once it receives it it runs the JS it has access to all the data and everything it needs and that is hydration hydration

is when you rerun the same react code so that your react can link up to the right places in the HTML and now we're done that's it so what's the catch like this has to be bad in some way right like this just sounds too too good to be true there are catches catch one what happens if I click a button here if I have a button that has an onclick that doesn't alert and I click it before the JS has loaded and before it has parsed and bound to the button what happens when I

click it doesn't know what on click is bound because when you write button onclick in react equals like this the actual HTML doesn't have an on click on it like that react is handling all of that itself in its virtual Dom so the button doesn't have the onclick function embedded in it in the HTML it has to attach to it properly the onclick isn't there until this JS is run and it has been parsed by the browser and that sucks because if the page loads you see it and you click a button immediately it won't

work because you have to wait for the button to be hydrated by that JavaScript so that's the biggest catch is button won't work yet and then afterwards once this is loaded now everything works this is a really good model and it solved a lot of problems but this isn't the only catch and also to be clear there are solutions to this most of the time what they'll do is in this HTML they'll send a really minimal JS tag that just creates a cue of all the events for when you click buttons and then once the

JS is loaded we just replay the things that you had done which works fine it solves the problem most of the time depending on who you talk if you talk to the quick guys like qwi the framework they think that this hydration thing is the root of all evil and they're trying to destroy it I think they're overreacting but whatever I'm the react bro of course I think everyone's overreacting there's another catch though the amount of data that is being sent when you build things this way you have to send a lot of data multiple

times my favorite example for this is again on PING the privacy policy on PING is a great way to Showcase another one of the problems with this model here I have the HTML for the page and if I go to the network Tab and we load it hard refreshed we can look at the response there we go cool so here's the HTML from that page and as we can see in here all of the text for all of that privacy policy is in here if this was a single page app it would be empty you

have to load the page load the JS fetch the data or embed it in the JavaScript and then finally you would see the content so what's the problem that seems ideal right I'll show you see this JS file privacy policy random name. JS let's take a random chunk of this we'll say a particular service command f look at that we have this nested child P children o strong cool here is that exact same text the entirety of the text for this privacy policy is sent down twice it is sent once as HTML because we have

now sent the correct HTML to the user but is sent again is Javascript because this is the JavaScript that created that HTML in the first place and we need to run the same js on the client and on the server in order for things to behave and for react to know what is where because if I had a button in this paragraph for for some reason and that button had an onclick and we didn't have all the text to render this to put the button there and put the onclick there it wouldn't work but that

means that not only are we double sending the data where we're sending it as HTML and we're sending the exact same content as JS it also means that the JS is full of all of this stuff that we don't actually want to have fogging down our JS I don't care if the privacy policy can be updated or not on the client it won't be it doesn't matter but it sucks that we have to send all this cont content down twice and that now it exists in the JS VM and runtime it's just more data that

doesn't need to be there so that's not fun it also kills your search engine optimization because the browser crawlers aren't going to download the JS and run it and generate the page they just want to look at the HTML and see what's in it so there's a lot of benefits to the HTML having the content but if it has a ton of content that doesn't change while you're on the page you're just loading a bunch of things that don't belong in JS and that's a tough balance to strike one last detail about SSR single page

apps I think it's actually really cool when the user clicks a new link the client still can do the generate a new page thing so it will immediately start showing you something if you set it up that way but it can also go to the server and ask for something so we go to twitch.tv/ the prime instead of the server generating a whole new page again like it did here cuz like it could just do this again but it doesn't instead what it does is it just grabs the data part so the first time you

load the page the react Ser runtime has to generate the HTML that the user sees from that point forward you can just grab this Json blob for a given page and since that has all the data and the JavaScript already exists on the client you have everything you need to render the page correctly now which means you're getting a lot of the benefits of both parts here you get the instant new page experience where you see something immediately and you get the ability to control those loading States and just fetch the Json you need instead

of having to wait to get a whole new HTML page that re-renders everything one more catch by the way is let's say I was on Twitch and I have a video playing and I click a link to the about page if we have an MPA then the player no longer exists but if it's a single page app now since the browser isn't navigating it isn't changing pages I can have the player move down to a little like picture in picture like popup thing in the corner as they continue to explore the site it is effectively

impossible to do that with a traditional multi-page app there are some API proposals that will make it more viable but having elements that are persistent while the rest of the page changes like that isn't really a thing that the browser does great it's part of why single page apps are so cool and you're getting all of those benefits with this model you get the correct HTML sent to the user you get better immediate navigations as you explore and do other things and now you have a way better experience to get the right content to the

user where you're just fetching the Json blob and can show a loading state in the interim really cool stuff sadly the way next works is that it blocks the whole page load in navigation until it has gotten that Json blob so if you used next in the traditional Pages directory so the old router which was SL pages instead of SL apppp the traditional single page app SSR story with something like OG nextjs doesn't give you a new page as soon as you navigate because it has to wait for the server to generate that data blob

and you're just stuck waiting until that happens but at the very least you can have things persistent on the page so it has benefits and negatives but you don't get the thing I really wanted which was the immed mediate navigation I wanted a click to show the user something new instantaneously so what I had to do is take all the data that requires This Server trip and not do it before the page loads so if you go to like the dashboard on PING you'll see something interesting you'll see a loading State the moment I click

I'll do this I am clicking now instantly you got a page see that time it was it loaded away faster because the data was cached but when I don't have it cached I just hard refreshed and I click clicking now you get that loading State initially and the reason you get that loading state is because I don't want to have any data block the navigation I want to click to immediately show you something and then go fetch the data you need from the API so despite how cool this model is for generating the right HTML

initially it has the catch of if you use it for everything then every navigation gets slow again so in some ways it is the best of traditional single Page Apps and the best of multi-page apps but it's also the worst of both where you're getting way too much data being sent down to the client and relying on the client way too heavily like single page apps do but you're also blocking navigation the way that multi-page apps do how the hell do we solve these problems finally after this wonderfully long tangent we're back to the two

key points that Ryan called out in the article there are single page app influenced isomorphic and then multi-page app influenced split execution these are evolutions of the two different strategies and this isn't an evolution of standard single page app because we went from Spa to full SSR is what I'll call it full SSR is what I just showed where we run the exact same react code in both places yeah good not great we now have isomorphic SSR isomorphic SSR is code that behaves differently on the server versus on the client it means I can do

something like a loading wrapper or a suspense wrapper and instead of having to wait for the server to send all the HTML I can show something immediately if I have this page page of HTML has a body has a nav has a div ID equals sidebar it has div ID equals content let's say this is our HTML this is the HTML for SL Theo on Twitch twitch.tv Theo I'll say ID is content well we'll give it even an actual content says Theo obviously the HTML for a different page like the primagen it's going to be

different the problem is it's not that different that's not great it's not fun it sucks that we have to wait for the server before the user sees anything when we do this navigation when I click a link in nav to go to this other page I'm waiting until the server finishes it why div ID and cotent instead of main I'm lazy but whatever you get the idea what if we change this up a little bit so right now this is HTML imagine this is jsx and we put some indicator here that's um don't wait for

this we'll say end there we do the same thing over here we wrap this with an indicator of some form that we don't want to wait for that part now it's theoretically possible when you do the navigation since we know everything else is the same to leave those parts do something here and then go get that extra data we even go a step further well again pretend this is jsx It's a Wonderful component called suspense so if we wrap this part here in a suspense give it a loading state or a fallback equals loading now

what will happen is when the client gets the page initially it can wait and not render this part cool awesome we hopefully get how suspense Works where if you wrap something in suspense it no longer blocks render and you can get stuff quicker cool where this gets way cooler is on navigation because if I go to a different page and the only things that have changed are the things that live inside of these boundaries when I click the link in the nav we don't immediately get back this with the primagen what we get back it's

going to be the loading thing there and now while we wait we get to see something we get to see that loading State as soon as we click and the server is going to get what it needs for us to put the correct content there super super cool where it gets even cooler is what if we don't send Json down that then has to render the right State what if we just sent the right HTML down so let's diagram this one out isomorphic SPI so realistically speaking top half here can mostly be treated as the

same there are benefits like if you have a component like a server component in react now that only runs on the server you don't have to send that same Json like data down as part of the JavaScript anymore kind of it does have to know where elements are and it serializes in a weird way so it's not fully removing the double data problem but at the very least it's not quite as bad and it doesn't live in the JS runtime the same way it's it's different but for the most part it's fair to say with

the isomorphic model the first page load has not changed much but the key with isomorphic is that it means it runs differently in the different places so if we have the same code some of it runs only on the server some of it only runs on the client some of it runs differently between the server and the client that's where the magic starts because when we navigate to the primagen when we go to that other page that has the different content instead of waiting for the server like we did here we can do two things

at once we can immediately kick back instead of showing the new state well immediately show loading State because the suspense boundary running on the client tells the browser and tells react hey when we go to this new page just show a loading State here while we're waiting for the rest of the data to come through as long as any data request is under a suspense boundary or a loading indication of some form we no longer have to wait for the browser to get the data before showing the user something so we can immediately show them

the loading State while at the same time the server is going to generate the element that we need to put there instead so we are now doing the thing we weren't before I showed before that we wouldn't run the react server runtime on further request we would just generate the Json no longer the case now we're doing this again ignore the first react run cuz no longer the case we no longer think about the number of times react runs kill that too for the same reason so now we go to this page server runtime and

generates the new page sends the new Json back to the server run time and then this now can send the changed HTML now now the server can send the things that were under those suspense tags to the browser browser gets new HTML chunks and then once the browser has those it can fill in the loading States so replace loading states with correct content I don't know how to explain this other way to say it's awesome it's so cool that we can have the single page app benefit of clicking something and immediately getting to see the

result as well as the benefit of not having to send Json and all the different ways to render to the client like let's say theoretically we had a bunch of different svgs depending on which person you went to like Prime and I have different svgs and they're both big and there are hundreds of thousands of them if that was all encoded in the JavaScript on the client then we have to have a giant JS file for all the possible States the UI could be in if you have HTML on your page in a traditional react

app the react code to render it has to be in that JS bundle with isomorphic single page app server component style development you now have this magical ability to have a ton of JavaScript that renders different states in instead of setting all the JS down and the Json down to create that HTML that giant typescript file can just live on the server and only send down the HTML so instead of sending this giant pile of JS that has every possible State your UI can be in combined with the Json that actually has the data you

need to do that render you can just send the HTML this is also what makes something like HTM X so magical is it's not sending Json down to the browser to transform into HTML it just sends the right HTML that's really cool and you're actually starting to get the benefits of all of these Solutions here because you get the immediate navigation of an Spa you get the HTML first development of an MPA and you get a developer experience where you don't feel like you're fighting between those two different things there are catches though as there

always are the biggest catch is you can't have that HTML file come from a static CDN anymore you can't have a static HTML file the same way that we did all the way back up here with a classic SPI where every page on Twitch resolves to the same index HTML file which means when you go to Twitch the latency to download that file instantaneous you don't have to wait any amount of time for it which is really really cool so we can't have the static HTML that's cached on a CDN now every single request ever

be it a web scraper or a traditional user anything between the all of them have to run serers side JavaScript to generate the page and to generate whatever content needs to be filled in and it is not easy to set up there are cool platforms like for cell and I'm pretty sure nlii starting to do similar stuff where they'll have an edge that they run in front so instead of going straight to the react server runtime you'll have a step in between like an edge of some form we'll put in the edge worker what I'll

call this The Edge worker will check the URL you're trying to go to and see if it has a cached HTML file for it or not if it does it'll grab the HTML file and send that if it doesn't then it goes and kicks the work back off to that server runtime to do the actual page generation and send that back there's a whole additional layer here of partial pre-rendering where it gets both a static part to start and the server runtime code to finish up so you can get something quicker and the rest later

that's going to make this way too long a video go check out any of my partial pre-rendering content if you want to better understand that part the point here is simple though when you have a model like this you no longer get to just send a static HTML file you now have to have backend code not just running JavaScript but running react you cannot do this model if you're not running your react code on the server that resolves the entire website in every URL so if twitch was to move to this model they wouldn't be

able to serve static HTML files and then have every endpoint running via go code you'd have to have at the very least twitch.tv the site itself get resolved by JavaScript and I understand why a lot of people are hesitant to do that there's even companies that won't let you do that because the frontend team's the front end team they're not allowed to go spin up apis and do those things and that's where this fourth very compelling option comes in MPA influenced split execution this model is actually very similar to the isomorphic model we just did

I'm going to grab these parts again remember when I said we had this HTML page that had the suspense and that allowed for react to know where to put the loading Spinners and what to wait for and not wait for the way that isomorphic mpas work is a little bit different instead of resolving via one request and sending down the dynamic data when it's ready or just blocking until the whole thing is done this element is an island and this island has some indication of what it needs to do we'll just pretend it has your

element we'll say Island Source equals SL content SL Theo so what the hell does this do what this does first and foremost is it lets you host this in a static CDN you can take this file and throw it in S3 and you're good to go that is really really cool so now we get to host this the way we're actually used to with both single Page Apps and traditional static multi-page apps where we have a bunch of HTML files just sitting on a static thing like S3 just some CDN that when you go to

a URL gives you HTML immediately what does this island thing do then this is where the pattern we're talking about it's really cool chances are this isn't going to source to the same place it's probably going to source to like api. example.com or Astro example.com or something like that to indicate this isn't the static CDN that just sends HTML this guy is going to make a network request to get the new HTML it needs so the page can load statically without using a real server it can be cached it can do all the things you

would expect from traditional HTML where you can just go to the page and it loads any parts that are Dynamic so if this island isn't the content for Theo it's my shopping cart all the page around my shopping cart might be the same for every user but that shopping cart part is personal it's for me and I shouldn't have to wait for the whole server to render the whole page before I can see something so if we have static pieces and the individual parts are indicated of this is dynamic go get some js for this

and then go get the actual data for it we've kind of inverted the model where we have these islands and this is where the term comes from it's islands that are Dynamic and interactive the rest is all static every user going to in this case twitch. TV thought the let's change this to like amazon.com cart up until this island every single user sees the exact same page the only part that's different is the part in this island and when you use something like Astro for this serers side Island creation what it does is once the

page is loaded it runs a tiny tiny bit of Js that will go to this URL it will use your cookies and all of that on the server side to generate the right content to them Ed into this part so let's diagram it so the user goes to amazon.com cart Amazon has this pre-generated C.H HTML file sitting on the server waiting for you to go to it so it loads effectively immediately this isn't complete HTML it's mostly complete HTML get sent to the user and as soon as this loads there's a tiny bit of JS

that has to run so I'm going to indicate that it almost feels unfair to because it's so little but I am going to indicate it here run embedded JavaScript and it's embedded JS goes through the page looks for any islands and it will find the island that we had drawn here with whatever the source is to get the shopping cart content so here it will now go to the server again and say hey I need SL content shopping cart I need the HTML to put into empty piece that isn't ready yet in this time user

sees renders everything but the islands so the user sees everything but the island and then we go run this embedded JS it hits this end point with the shopping cart data in it it does all the fun things we had done up here I'll just grab this it can run the react server run time if you want because something like Astra supports whatever framework you want it to but realistically speaking chances are when you do a server Island like this you're just going to do it through Astro so I'll say Astro server runtime now the

Astro server runtime will hit the database get some Json back and then here Island HTML content here we are the Astro server now creates that remaining HTML content which can be sent pretty much directly down no JS back and forth none of that we just send the content to the browser remaining HTML and then the browser uses that tiny bit of JS to figure out where it goes put it in the island we're done so what really cool about this solution is you don't have to do some weird to get the static CDN benefit for

that first load one of the most painful things I accepted when I moved to the server component model when I moved from ping being traditional spa for the most part over to upload thing which was very much the new server render first methods is that the HTML had to either be fully static with no Dynamic Behavior at all or it had to be fully Dynamic which means you're waiting for the server before the user sees a single thing I hated both of those compromises and what I found myself doing was just generating a static mostly

done HTML file with a giant loading spinner and then do everything on the client from there and that's why ping still feels really fast like once the Ping page is loaded navigating flies it feels even faster than stuff I've built like upload thing but upload thing uses way less resource and sends wayless stuff back and forth because it is using the new paradigms there are a couple benefits that I am aiming for when I build benefit one users clicking links should change the page instantly I don't want a user to ever click something and not

be sure if stuff is changing or not I also want to be able to do things on the client like have a popup video player that doesn't go away when you're moving from one place to another I also don't want to wait for a server for first page load if the server has to generate the page before the user can see it there's an inherent penalty every time you navigate especially when you first open the page especially if you're using serverless and you're hitting a cold start it can take seconds before you even start getting

a response from the server because it has to spin up connect to your database and start generating stuff just to realize it's sending you a static asset anyways it sucks so I don't want to have to wait for the server to generate a full page before the user sees anything the third thing really want is I want Dynamic parts to be generated on server Parts generated on server I don't want to have to wait for the page to load HTML load imp parse JavaScript run the JS go hit a server render a component once it

gets the data back realize it needs to go fetch five more and that back and forth the thing I spent the whole first third of this talking about with the traditional Spa all the way up here I want to avoid all of that blocking the user seeing the real content and these three things don't play together nice because if you're generating a response on the server that response has to come from the server which means if the page came from a CDN that is static but it has Dynamic Parts on it you're now inherently blocking

the whole page on that Dynamic part of the server so it almost feels like inherently that when we do the dynamic part generate on the server that we're hurting our goal here where you can't click a link or go to a link and immediately see the content because the server has to generate the whole thing even if most of it is static I hinted at partial pre-rendering earlier and this is why I think it's really cool it lets you have the static Parts respond pretty much instantaneously and the dynamic Parts get generated dynamically on the

server on request time it's kind of the best of both but it comes with a catch and the catch I detailed earlier where did I put that diagram here you need an edge worker that can go grab the static part out of a CDN for you so you don't have to wait for something to generate it you don't have to wait for your server to generate that first part we can grab the initial HTML out of the CDN send that back immediately and then stream the rest down when it's ready that is a really cool

thing but it requires you to have very smart infrastructure that has this Edge worker that does the initial resolution to pull from a CDN and this would require your frontend devs to be experts in all things infra or go pay for sell and move their back in there which you know how the backend teams are going to feel about that these features they're not exclusive in the sense that for cell has lock them down and won't let anyone else do it they're exclusive in the sense that for cell's one of the few places that has

built it but that is what makes the mpa solution here the split execution server Island model so cool is you don't need to have that resolution layer you can think of this like where does the static HTML get the dynamic Parts added to it with the new nextjs for cell model the static part and the dynamic part the difference is identified on that edge worker the static comes through the CDN and goes back to the user the dynamic gets forwarded onto the server and goes back the effective only difference here is instead of that edge

worker being a thing that is run on versell there is no Edge worker anymore now it is run on your device the difference here is previously where we had the edge worker we now have this little bit of embedded JavaScript it is doing the exact same thing we get that static CDN HTML from the server then this JavaScript identifies the dynamic parts and then kicks that off to the server to generate and instead of that like box running behind doing that work now your client is instead the cost here is that you don't get to

kick both off at the same time so if you go to SL cart in the other model the user starts getting the HTML and the server starts generating the rest at the same time because they're both being hit by the same thing here we have to wait for the user to get stuff before it kicks off the next part the benefit is your infrastructure that handles this is significantly less complex and can be hosted in all the old traditional ways you're used to where this part is just S3 and this part is just a dumb

node server or Lambda if you do it the other way your infrastructure has to be more complex so there's benefits and negatives to all of these strategies and it's really cool to see us moving as an industry towards a place where you can have Dynamic parts that are server rendered static parts that are instantaneous first page loads that feel great and navigation that feels like the code is running on your machine that is the win I want to see I want all of these parts to come together in a way where the tools we use

just kind of work right and we don't have to think about the dynamic versus static parts anymore problem we have right now is that other than Cloud flare most reprovisioned Edge services like netlify and verell have to Route traffic through their main service before back to the edge making the edge slower yep absolutely there are a lot of catches to all of these models but there's a lot of benefits too as I mentioned at the beginning this video was kicked off by this article by Ryan carniato JavaScript Frameworks headed into this video is going to

be a fast follow so if you haven't subbed already please do all of this comes together in the end really excited for it thanks again to Ryan for writing this and thanks to you for sticking through the chaos that was getting through all this seriously though go watch that JavaScript framework a 2025 video it's it's going to be a banger anyways peace narts