My Cold Take - What happened IMO was that Fully client side app's where a huge blow to the cloud/hosting providers as now all the rendering process is done on client side and no server is used, expected for just apis. So, what they do? They started creating Meta frameworks which uses Server side rendering also so that, server is also used in generating pages, and that increases their revenue.
they don't just create this meta frameworks to solve some SEO problems, but they are actually pushing hard towards SSR at the point that react docs only recommend using a SSR framework to build every application. Next, in turn, does not even support CSR officially.
There are other valid reasons for SSR. Imagine you're a facebook or a google or a twitter. Being fast actually helps a lot in maintaining market share. Increasing load times by a few hundred milliseconds tanks user interactions. Now as your site increases in complexity, and people's phones aren't always the newest of the new, it'll take up increasing amounts of their hardware to deal with your site. Which might make it slow on older hardware, and ripe for a competitor to come in. But if you do SSR you can get some big servers that are guaranteed decent response times and the customer's hardware only needs to render stuff. Now even the older phones can deal with your site in acceptable time frames. Which increases potential market share. Before you go "they can just install the app" remember that some people don't want the app that hovers up a ton of data. But the company does still want the data site users provide them.
@@slaapt with 5g incoming and ever increasing power of devices, response times will remain just fine. They wanted the servers to be used. That's the truth
I think is worth mentioning that in the SSR model, after hydratation, your page can do API calls and update the UI using the returned JSON, no need of a page refresh. Something similar to what we used to do in the old days using ajax and jquery.
exactly, MultiPage Server paradigm was is taking too much time until was generate the page; the main point was multiple Time reduce to Render the PAGE: 1) multiple API vs one huge payload. (ms vs seconds) ; is good to have multiple API calls (~`00 ms per API call) 2) Show something Fast until you load more data; MultiPage Server was waterfall wait until the page is REady and a big SPINEER to see; Which direction are we going: 1 ) SmartPhone octacore with 6 GB RAM: 2) 5G connection and you are telling me is better to have one HUGE Payload ?
Even for devs who experiment NextJs/SPA/SSR since many years, the level of understanding and the level of pedagogy is so worthfull !! Thank you very much \o/
I think there are a lot of valid use cases where SSR totally makes sense. And I am happy that we have Next and React SSC. But also in practice: a lot of React applications are behind a login mask, should never be crawled and have a lot of interaction. For this kind of app, I still prefer a fully client side rendered approach as it is much simpler to code, maintain and host. If the performance of the users devices is of no concern, I don't see any downsides. And I also prefer having a slightly longer loading time but seeing some loading spinners that tell the users what is happening instead of just having a blank page
correct me if im wrong, but SSR its a good solution for some kind of blog, where you want some kind of dynamic data in the site, but you dont need to fetch api and reach the database everytime a users enters the site, so you use next to generate a html with all the data from the api once and give this to the user instead, but you do it in some way, that when you change the content of the database, the html is regenerated with the new info, so this way you dont unecessary overload the usage of your api and db. and thats the only use i can think of, a web site where there is a lot data that only the admin changes and few to none data that the users change. please, anything that i said wrong or understanded wrong, just tell me, im just on the begining of my learning, and first saw about next last week
I agree with this, I think as engineers, we need to factor in the context in which we make certain technical decisions. What works for one use case may not be needed or good for another.
The explanation about Single Page App, is not fair. For Business Web Apps (not public facing websites), users will access the website everyday, if it takes 2, 5, 10 secs to load on the first access it is not a problem at all. Js is cached and the website is fast to load every other time. I have got webapps for which users actually never reload the page for a full day of work.
excellent, this certainly is one of your best breakdowns so far . I've been following for nearly a year now, just wanted to let you know that this kind of content is what makes you stand out (for me)
As much as there was a trend of spa, it seems that the current trend of SSR is in progress. I think the time it takes for spa to actually load is overstated. With technologies like module federation, speed is not an issue. SEO is definitely an advantage of ssr. Don't burden the server too much. The client's energy consumption is entirely up to the user, but Server usage is money. $
A very detailed video and totally on point explanation. Yes, SSR looks great and definitely improves SEO and UX. The problem now though is you totally give up all chances of page caching when under any decent load. Most apps that are behind a paywall or require mandatory user authentication and authorisation do not need to be SSR. And while nobody is considering this but when you're serving DOM from a server, you're serving a lot of redundant data, using a lot of TCP connections and burning a lot of compute and IO to read files and serve them. SSR IS EXPENSIVE AND COSTLY and unfortunately no one is saying that. For blogs, public content, etc. SSG is still the best option and in case the page requires some dynamic data to be included, make it ISR and let the client request the dynamic data that it needs. Our mobile devices aren't weak, our networks aren't unreliable but our cloud costs are always increasing. SSR, when unnecessary, just adds to this cost. Caching is your friend and caching JSON will be easier / simpler and much more scalable than SSR DOM. Even for the most data intensive applications out there, ISR + HTTP Polling / GraphQL subscriptions is still the best way to have a great UX today. SSR is a great piece of tech and React's concurrent mode along with suspense makes it very scalable too but unless you've 10k dynamic layouts with lot's of decision making and need realtime sync renders, don't use it!
So to summarize: The benefits of SSR are: - we can cache the rendered page, which only works for not personalized pages, which unfortunately doesn't apply for most pages. - we can't show loading animations even if we would like to - if we have 100 users on the page with iPhones at the same time, if our servers have more performance than their 100 iPhones the rendering would be slightly faster - instead of js files and JSON we push huge html pages to the client. Wasn't the big preformance benefit of Angular and React that after the bundles where in the browser cache the only thing we had to push to the client was some JSON data instead of the whole html? - we can deliver a small part of the page statically generated then load more data and render the rest of the page on client side anyways I have been working for 2.5 years now with SSR in my current project and researched it on the internet a lot but I have not found a reason that's worth adding the complexity yet. And for me it sounds crazy that the servers should now have more power than all of the users devices compared to actually have faster rendering. And all of this runs on node.js which scales really bad and doing actual work on node.js servers just defeats the one benefit they have of being unblocking. If I'm missing something please tell me.
@@Tikayy Yes, in fact I still do. At work we are currently removing SSR from our whole stack because we measured performance and SSR was in many cases just as fast as client side and in some cases even slower. Our setup wasn't even perfect for the tests because we delivered the bundles for the client side solution via a node server without cache because we had no CDN available yet and we did not throttle the connection. On slow internet or with bundle via CDN SSR would have lost hard against client side instead of being just a little bit slower. And I don't even want to mention the extra complexity of the stack that the teams have to handle with SSR. Btw, this is not the first project I was in where we had SSR and removed it after performance tests. In another project we had SSR and also PWA workers for "maximum performance". The test results where exactly the same. SSR was slightly slower than client side rendered and with slow internet significantly slower.
This is awesome. I’ve seen all of these models on various websites but seeing how they work out in these block diagrams makes it super easy to understand. You’re a great teacher Theo! Knowing how to break down a complicated topic into easy to understand chunks is an art and a skill and you have both.
I find it funny how we got a full circle where we started server-side rendered templates that were updated through Ajax, moved to entirely client-side rendering, and now we are returning to rendering on the server side again. I am unsure why you are saying that we re-rendered everything on a page with Ajax. While there were certainly ones who did, a significant revolution with Ajax was that you could render portions of your page and replace the result within containers. EDIT: The old solution was not ideal, but the concept worked overall. The new tools are definitely better, especially when we look at possibly the next steps with things like Qwik/Yew and similar, combining the server and client to deliver an experience.
The difference with SSR as Theo points out is now the framework, language and even components for the server and client rendering are now the same. Previously they would normally be different say PHP for initial render and JS for client updates. You can definitely do it, but it’s not as slick and integrated as the same thing for both parts.
Yes, now you can do pretty much exactly the same as you did with ajax back then, but using single programming language, single paradigm and less boilerplate.
@@romankoncek150, @Hugo Wride, Indeed. It is an improvement for sure! It just not as if we had not have the concept before, we just have better tools to execute it.
@@hugowride4582 Yea, and we're bound to return to having a different language as well, as modern PHP and Java offer better performance for SSR than Node or even Deno.
SSR is the definition of premature optimisations. There is so much low hanging fruit people could do before SSR should be considered... but it's trendy and that's enough I guess
The things PHP got right were a) didn't try to abstract away the HTTP request cycle in the way crap like JSP/ASP/JSF did, and b) easy to get going. The rest of the language and standard library is... not so good™.
Ty so much for helping me learn and grow, Theo! Love your content. Definitely subbed with notifications set to all. When I get a job I’ll be able to be a greater value to your channel but….im working hard to stay organized and on task.
This is legitimately one of the best explanations of the differences between traditional PHP vs. clientside rendered vs. SSR content serving. REALLY. WELL. DONE. 👍
In my previous React app, we cache even the index.html file, so this whole SPA model was about 1ms because the user already had everything cached in their browser, It worked like magic, no component hydration no BS, just good old React app, after each release, we clean the index.html file so it gives the headers with the new base javascript to all users, also we split our App in multiple bundles for each page, by doing this we could handle millions of request with a super cheap server because the CDN was actually doing all the work for us. PS: with HTTP/2 everything its done all at once its not like this step by step as shown in the video, this happens super fast.
Great video. As someone who is gonna start playing with next soon, i really needed the high level overview. Would help if you can make another video on how it is implemented too.
with CSR you've got fast loading too, if not fastest, on subsequent requests though and one can minimize initial rendering with suspense, fetching all the other chunks in background, while user stays on some page
ok watched a few times now and man i feel like i owe you 1000$ for this. ive been struggling with hydration too and this covered evertything so well. most people just talk about the topic, but you always talk about how the topic fits in the greater environment, and thats what i need where i dont know what i dont know. THANKS COACH
Amazing video Theo. Your videos are tidbits into tech topics that are so ideal in giving brief overviews of new trends. I really like how you took the time to graph and visualize how the flow of package load has changed over these past times. Keep up the great work
this is so clear and inspiring! the visuals are so easy to understand and i love it! i wonder what software you were using to draw these models. anyways, thanks a lot!
Awesome video. As a backend dev that has observed the cycle from the sidelines, it's funny to see that we're going back to rendering content on the backend/server side. The question that pops into my head is if embracing this will make it harder to build a pwa (mainly offline support)? Or is some caching layer enough to make this work decently?
funny is just a nice word.. call it like it is nosense. if the problem is big JS bundle the solution is to use less JS, but the brains behind react want cash so they say everythings needs to be rendered on the server and the sheps follows.
@@marlonjerezisla6496Exactly. React is a great component framework, but SSR for anything other than ordinary HTML is nonsense. Also no startups are gonna use SSR for their
Thanks I recently learned this and this was a good overview. I think it is good that we get tooling to setup the rendering and it's data-flows easily. For example in some instances I'd rather have a loading spinner than a page with buttons I cannot click.
Thanks Theo! Always great resource of information. Though I was waiting for the "oh look! it returns a JSON with the content 'users are not subscribing to your channel!'" :D
This one was helpful to understand why the freak we need SSR frameworks. It makes the Developer experience much much simpler along with the SSR model compared to the traditional server rendered model of using a server and templating engine. The last part was really informative as well, we can have blocking renders for things that are essential for our App and have Suspense states for non-essential components.
It was Gmail that changed the game when it was released, they used ajax to handle the massive data in the browser and replace part of the page without needing to refresh the whole page. You forgot to mention Backbonjs that actually started the spa framework or libraries 4-5 years before React.
The issue with this new model is state sync complexity between client and server, especially if you use a store system like redux. For complex applications, where lots of interactivity is required clientside, i still prefer the tradeoff of the spa model, where logic and store is in a single place at the costs of an initial longer load
I’m an old man now but I rememer pushing against SPAs because of how gd slow they were in most implementations For a veeeery long time after spas were the new shinys, expertly maintained multipages with selective Ajax interactions were by far way faster than any other sites. In fact, to this day, the fastest possible experiences are essentially old-style mvc/php with manual dom updates. Look I get it that server rendered sites can’t do what spas do, but having become an expert at both and the inbetween, spas were engineered by non-frontend guys to solve problems that didn’t really exist in 95% use cases. And forgive me for my smugness but I can make a website that will beat every single framework out there and give the same experience or better. The problems were always get the page down fast, fully hydrated. Yep, asp/php. Onload fetch likely/potential resources like top-level navigation templates, preload images, etc. We also did things that I still think has a place that is no longer done, and use css to show and hide modals, instead of creating and destroying html elements. There’s a lot of things we used to do with css that was just much faster than updating the dom and rerendering. JavaScript is a great tool but it’s just so overrelied on now imo. It’s just so amusing all of the technologies that are “new” that aren’t new at all. “Microfontends” that’s literally what we used to do, return small pieces of html and js as needed and insert them into the page. Technology always seems to go in circles~
Oh and selective use of templating with knockout or maybe vue if you want to get fancy. But most pages never really have much of a usecase for templating. Grids and such usually do their own templating. But for where you do need templating, it’s fine it’s an incredibly simple technology. Take the template, hydrate it, create element, register its handle with a controller, stick it in the page. And the JavaScript for all of these things are incredibly small, so you have to look at these js file sizes and wonder, Jesus h Christ in a chicken basket, wtf are the doing? Launching a satellite or rendering a website??
I never understood why people prefer SSR over an instant static response. Personalization often can't be served from the database alone but includes data in the browser (preferences, hardware info, local storage, indexeddb, ...) making SSR not feasible for a lot of things. Feature flags can be done static, too. So you end up doing SSR for 5% personalized data together with 95% of what could be static. Hydration is already slow. SSR is added on top. Potential cold starts are added on top. Higher infrastructure costs as well. Not a great recipe.
Hey Theo! Huge thanks for the detailed explanation! My concern is how w/ this RSC approach we could do real-time apps? I mean, when some component subscribes to db data in this case we propbably should avoid using RSC for this component right?
Back in the day we didn't do a whole page refresh when we needed data updated, ajax has been around since 1999. I remember aspnet update panels in 2000 that did what nextjs is now trying to do. I've been coding webapps exactly as your describing 20 years ago. What is new is actually old.
The reason SSR is so popular is that Vercel wants to sell you server compute time. That is how they make money. MOST people would be better off with static site generation and hosting on a CDN. Even the non-beta docs in NextJS recommend SSG over SSR.
SSG only works for the simplest of sites. Most businesses need content generated dynamically and often based on the user, geolocation, and other parameters.
That's not true , any reputable business that needs to rank high in Google, will undoubtedly require the website to be SSR. SEO is the main reason why SSR exists. Also this video doesn't explain well how SSR works, HTML is send from server once, not multiple times.
To be honest, I only think the SEO stuff is worth it for SSR. Else, how things are rendered can still be quite well controlled in CSR so the user experience is still very good. If you are not creating a full-stack app where the rendering server is the one making database requests, then the unnecessary mental overhead doesn't seem worth it. I may stand corrected tho. Nice talk!
totally agreed. only point of SSR is to have SEO managed. Otherwise CSR frameworks are small and optimized enough to render client app almost instantly. free rendering on client. why pay for ssr server.. crawler bots should wait for app to render.
I don't think you are getting the actual point of SSR. SEO (although one of the most important) is not the only reason to do SSR. Its also faster initial load, accessibility, less JS -> more perf, more reach to users. I agree that SPA > MPA in terms of UX. But at some degree, performance should also be taken into consideration because.. people are impatient, and if you don't load faster, people will bounce and no one is going to stick around to use the amazing UX the app will provide.
@@PranavJindal999 CSR frameworks are small and optimized is probably the biggest lie I have ever heard. You think sending 300kb of JS just to render HTML is "small and optimized" compared to sending a 50kb HTML file? Even with a highly optimized framework like Svelte, you are stilll dealing with 150kb of JS to render MARKUP. Also, the worst thing you can do is predict what your client has to run the app. And you saying free rendering on client, isn't always trusted. Many people have low powered devices (You may build your beautiful SPA on a M1 MacBook Pro, but many of your users are on low powered mobile devices), and they struggle to use your 1MB JS app just because *you got lazy to SSR your page* SSR is like build tools, if you use it, your app will have a broader rich, faster loads, and better user reviews. Also, last point I find hilarious "crawler bots should wait for app to render" You are basically telling the google and other search engine crawlers "pay my bills for more computation to render my app's markup". Also, you should not assume all your users AS WELL AS crawlers are on the same super-fast computer that you are on. They run on low powered or high-throughput devices that don't have the computation power to run an entire JS engine like v8 and give it enough memory to run your web app's supposed but misused interactive part. Using JS to enhance is better than empowering JS to make the app collapse.
@@Dev-Siri Who in their right mind would push 1MB of javascript to their client, you can split your JS files to reduce the bundle and cache the entire thing. I never understood SSR's objective, even the SEO is a damn lie, first WHY would I improve the SEO of a React app? I want to improve the SEO on the landing page which ofc is not made with React, so I still didn't find the use case for SSR, you add complexity(components hydration) to the project for what? Also, any device nowadays can handle a React app, like my phone has more cores than my PC damn, why do I need to send all the template generation back to the server? Sending to the client is WAAY more cost-efficient and once the client has cached my JS files they will only fetch the pages/files I update because I split my React app into multiple bundles. I put everything behind a CDN and voila, it's done, assets being delivered near the client location at max speed with almost zero cost, CDN saves a lot of requests to my server because it caches the server assets.
Theo, can you compare CSR vs SSR vs RSC for subsequent page loads, e.g. the user is already on one page, then navigates to a second page within the site
In other words, instead of returning an empty HTML (like with CRA), you get to return content in it and it's up to you how much content you want to return. This likely reduces the number of spinners and waterfall effects on the UX.
in CSR it's the client which makes a lot of request. in SSR it's the server which makes a lot of responses. The number of responses from the sever is same I think for both CSR and SSR
I do enjoy writing JS/TS, the language has come a long way and does a lot of stuff out of the box, especially combined with Vite or Webpack... but the framework world is akin to a backpacker that leaves on his travels with a bare empty suitcase and come back home with 3 shipping containers full of clobber from each country he visited... With each problem it solves it gets closer to where it all started only significantly heavier :D haha
Wow, this is a good refresher on javascript.. Haven't touch it in years. So much has changed. Thank you, I appreciate it. Bare with me.. I'm re-learning javascript. So I'm assuming a hybrid model would consist of some stuff loading in the background automatically and some stuff are being loaded up ONLY IF the user decide what they chooses to load up?
I remember how everyone was moving from MPA to SPA. And the idea was to change slider movies to nice interactive application experience in SPA. Now we are going back to a bit faster by still slide movie. And I wonder what will take to build same level of interactivity in MPA.
I thought this was intuitive as a good UX practice, the user wants to be up-to-date with the page rendering progress, especially on lower end devices that tend to generally lag. Regardless, it's a good concept that must be definitely adopted more on the web.
Great video, but how do I manage a multi-client solution, where I have a web app and a mobile app from the same business logic. Is there SSR for mobile app like on react native. If I have to write api for mobile app, does it not mean i am duplicating backend code with SSR?
I have a question regarding the implementation of web apps using the MPA approach, which involves utilizing HTML, CSS, JS, and server-side scripting like PHP for an example. Then I'm curious about the necessity of Server-Side Rendering (SSR) in this particular context.
Am I understanding correctly? The SSR model we've arrived at is very similar to how Laravel/RoR sites with React components are doing? I'm curious why this wasn't the approach from the beginning.
because JS likes to re-invent everything! On a more serious note, its not quite the same. I'm not sure how you're using laravel/RoR to render react components, but to do SSR the way JS frameworks define it as, you'll need to be running a node-server to render the component for the frontend to use. We initially had the SPA/Backend separation because coupling our backend with frontend HTML templates was typically a bad idea. So SPAs were created and JSON was used to communicate the data with the frontend and now the 2 were decoupled. However more complicated frontends became slower because the JS bundle it had to download and process on first load was huge. The solution? JS flavoured SSR! Well actually its more like splitting the SPA into a app-router on the client side and let most of the processing happen on the server. Then when the client requests a page, the server returns the relevant component markup in the way the framework understands. Its a good middle ground solution. So the separation is something like this: React NextJs Backend (backend could be laravel/RoR or direct to DB). This way there's still no coupling between your backend and frontend.
Watching the video, I honestly didn't hear any advantages of SSR over classic MPA with AJAX, which we have had since roughly 2005. Other than limited developer skills, I still don't understand why a dev would use interpreted JavaScript on the server instead of compiled language/framework using C#, Java, etc. Thank you for the video - well done!
Theo, I understand SSR is really nice for rendering. But CSR and SSR both should be infused in an app, by making everything SSR your cost for spinning the server processing is high. So we need to do an analysis to lower cost without losing performance. Today devices and computer have fast processor so the issue of CSR is being slow is their but we need to do cost analysis on that. Cost of running a server is always huge for small or big company. #ServerCost
SSR is a solution to a non-problem. If you're building a static site where performance and SEO are important, use pure html/SSG. If you're building a dynamic application where SEO is less of a concern, show loading spinners for an extra couple hundred milliseconds. Separate your concerns and choose the tool that excels in its domain. This is a much better solution than adopting SSR which is a half-baked solution that adds a significant mental, practical and maintenance complexity to your application. Also, don't forget the vendor lock-in that comes w/ Vercel.
Building web apps for many years I learned that there is always a tool you need, which is not cover all your requirements. SSR is a great technology when you know what you get. If there is a hot cache and proper separation on servers, good availability, this may save time for user, performance on servers, speed up CD and save a lot of money for customer. BUT, only of there is a need for this. Once I was working on video hosting service and there was a need for SSR, to make better position in Google and start video immediately after page runs (which is unrelated to SSR, but whatever). And the cheme you've showed in your example would be great solution. Unfortunately, it wasn't. Anyway, there is always a possibility to make great app using correct tools.
Yes, but you can still independent of framework choose to not show the spinners and make it look and feel like it's SSR rendered without SSR. It will be faster just to load the necessary data rather than sending chunks of html. The browser still need to render every pixel on screen. I don't think we should be afraid of DOM manipulation, I think we just need a better way of doing so.
This was an amazing video, super clear and concise. Does anyone know if there is a way to gain control of the loading state of NextJS SSR pages? I get that you gain performance because the entire page is returned, but when page loads are long in low network conditions, I've noticed theres a bit of an awkward period where youre not sure if a button press is actually doing anything while the server renders the page/component. Thanks!
Thing that i don't understand is how does next managing to do this? Like how next rendering a server component inside a client component how does this work?
My Cold Take - What happened IMO was that Fully client side app's where a huge blow to the cloud/hosting providers as now all the rendering process is done on client side and no server is used, expected for just apis. So, what they do? They started creating Meta frameworks which uses Server side rendering also so that, server is also used in generating pages, and that increases their revenue.
Dude!!!🤯🤯🤯 I know you are joking but these makes so much sense
they don't just create this meta frameworks to solve some SEO problems, but they are actually pushing hard towards SSR at the point that react docs only recommend using a SSR framework to build every application. Next, in turn, does not even support CSR officially.
There are other valid reasons for SSR.
Imagine you're a facebook or a google or a twitter.
Being fast actually helps a lot in maintaining market share. Increasing load times by a few hundred milliseconds tanks user interactions.
Now as your site increases in complexity, and people's phones aren't always the newest of the new, it'll take up increasing amounts of their hardware to deal with your site. Which might make it slow on older hardware, and ripe for a competitor to come in.
But if you do SSR you can get some big servers that are guaranteed decent response times and the customer's hardware only needs to render stuff. Now even the older phones can deal with your site in acceptable time frames. Which increases potential market share.
Before you go "they can just install the app" remember that some people don't want the app that hovers up a ton of data. But the company does still want the data site users provide them.
@@slaapt with 5g incoming and ever increasing power of devices, response times will remain just fine. They wanted the servers to be used. That's the truth
@@dipanjanghosal1662I agree with you. It always the same talk about performance and how "slow" shipping some mbs of data are bad. Come on
I think is worth mentioning that in the SSR model, after hydratation, your page can do API calls and update the UI using the returned JSON, no need of a page refresh. Something similar to what we used to do in the old days using ajax and jquery.
exactly, MultiPage Server paradigm was is taking too much time until was generate the page; the main point was multiple Time reduce to Render the PAGE:
1) multiple API vs one huge payload. (ms vs seconds) ; is good to have multiple API calls (~`00 ms per API call)
2) Show something Fast until you load more data; MultiPage Server was waterfall wait until the page is REady and a big SPINEER to see;
Which direction are we going: 1 ) SmartPhone octacore with 6 GB RAM: 2) 5G connection and you are telling me is better to have one HUGE Payload ?
Even for devs who experiment NextJs/SPA/SSR since many years, the level of understanding and the level of pedagogy is so worthfull !! Thank you very much \o/
I think there are a lot of valid use cases where SSR totally makes sense. And I am happy that we have Next and React SSC. But also in practice: a lot of React applications are behind a login mask, should never be crawled and have a lot of interaction. For this kind of app, I still prefer a fully client side rendered approach as it is much simpler to code, maintain and host. If the performance of the users devices is of no concern, I don't see any downsides. And I also prefer having a slightly longer loading time but seeing some loading spinners that tell the users what is happening instead of just having a blank page
What does SSC stand for?
@@MyPlanetIsPluto I meant React Server Components. One S to much...
correct me if im wrong, but SSR its a good solution for some kind of blog, where you want some kind of dynamic data in the site, but you dont need to fetch api and reach the database everytime a users enters the site, so you use next to generate a html with all the data from the api once and give this to the user instead, but you do it in some way, that when you change the content of the database, the html is regenerated with the new info, so this way you dont unecessary overload the usage of your api and db.
and thats the only use i can think of, a web site where there is a lot data that only the admin changes and few to none data that the users change.
please, anything that i said wrong or understanded wrong, just tell me, im just on the begining of my learning, and first saw about next last week
and if there is other solution for this "blog" problem, please tell me, i need to know how not to overload the db
I agree with this, I think as engineers, we need to factor in the context in which we make certain technical decisions. What works for one use case may not be needed or good for another.
The explanation about Single Page App, is not fair. For Business Web Apps (not public facing websites), users will access the website everyday, if it takes 2, 5, 10 secs to load on the first access it is not a problem at all. Js is cached and the website is fast to load every other time. I have got webapps for which users actually never reload the page for a full day of work.
Yeah I think there are way more Business internal production spa than public ones. Nobody cares there about 0kb js or edge
Not sure he even understands business cases for SPA.
Theo seems very ignorant of the web dev world outside of the domains he personally worked on.
excellent, this certainly is one of your best breakdowns so far
. I've been following for nearly a year now, just wanted to let you know that this kind of content is what makes you stand out (for me)
As much as there was a trend of spa, it seems that the current trend of SSR is in progress.
I think the time it takes for spa to actually load is overstated.
With technologies like module federation, speed is not an issue.
SEO is definitely an advantage of ssr.
Don't burden the server too much.
The client's energy consumption is entirely up to the user, but
Server usage is money. $
A very detailed video and totally on point explanation.
Yes, SSR looks great and definitely improves SEO and UX. The problem now though is you totally give up all chances of page caching when under any decent load. Most apps that are behind a paywall or require mandatory user authentication and authorisation do not need to be SSR. And while nobody is considering this but when you're serving DOM from a server, you're serving a lot of redundant data, using a lot of TCP connections and burning a lot of compute and IO to read files and serve them. SSR IS EXPENSIVE AND COSTLY and unfortunately no one is saying that.
For blogs, public content, etc. SSG is still the best option and in case the page requires some dynamic data to be included, make it ISR and let the client request the dynamic data that it needs. Our mobile devices aren't weak, our networks aren't unreliable but our cloud costs are always increasing. SSR, when unnecessary, just adds to this cost. Caching is your friend and caching JSON will be easier / simpler and much more scalable than SSR DOM.
Even for the most data intensive applications out there, ISR + HTTP Polling / GraphQL subscriptions is still the best way to have a great UX today. SSR is a great piece of tech and React's concurrent mode along with suspense makes it very scalable too but unless you've 10k dynamic layouts with lot's of decision making and need realtime sync renders, don't use it!
So to summarize: The benefits of SSR are:
- we can cache the rendered page, which only works for not personalized pages, which unfortunately doesn't apply for most pages.
- we can't show loading animations even if we would like to
- if we have 100 users on the page with iPhones at the same time, if our servers have more performance than their 100 iPhones the rendering would be slightly faster
- instead of js files and JSON we push huge html pages to the client. Wasn't the big preformance benefit of Angular and React that after the bundles where in the browser cache the only thing we had to push to the client was some JSON data instead of the whole html?
- we can deliver a small part of the page statically generated then load more data and render the rest of the page on client side anyways
I have been working for 2.5 years now with SSR in my current project and researched it on the internet a lot but I have not found a reason that's worth adding the complexity yet. And for me it sounds crazy that the servers should now have more power than all of the users devices compared to actually have faster rendering. And all of this runs on node.js which scales really bad and doing actual work on node.js servers just defeats the one benefit they have of being unblocking. If I'm missing something please tell me.
Just wondering, are you still having the same mindset?
Yes do you have the same mindset still?
@@Tikayy Yes, in fact I still do. At work we are currently removing SSR from our whole stack because we measured performance and SSR was in many cases just as fast as client side and in some cases even slower. Our setup wasn't even perfect for the tests because we delivered the bundles for the client side solution via a node server without cache because we had no CDN available yet and we did not throttle the connection. On slow internet or with bundle via CDN SSR would have lost hard against client side instead of being just a little bit slower. And I don't even want to mention the extra complexity of the stack that the teams have to handle with SSR. Btw, this is not the first project I was in where we had SSR and removed it after performance tests. In another project we had SSR and also PWA workers for "maximum performance". The test results where exactly the same. SSR was slightly slower than client side rendered and with slow internet significantly slower.
@@marin1419 just pinging you, so see my answer. RUclips 2024 still let's you @ only one person.
@@espendennis Amazing info, thanks, appreciated!
This is awesome. I’ve seen all of these models on various websites but seeing how they work out in these block diagrams makes it super easy to understand. You’re a great teacher Theo! Knowing how to break down a complicated topic into easy to understand chunks is an art and a skill and you have both.
which diagram app is that?
@@mythicalj891looks like excalidraw
I find it funny how we got a full circle where we started server-side rendered templates that were updated through Ajax, moved to entirely client-side rendering, and now we are returning to rendering on the server side again. I am unsure why you are saying that we re-rendered everything on a page with Ajax. While there were certainly ones who did, a significant revolution with Ajax was that you could render portions of your page and replace the result within containers.
EDIT: The old solution was not ideal, but the concept worked overall. The new tools are definitely better, especially when we look at possibly the next steps with things like Qwik/Yew and similar, combining the server and client to deliver an experience.
The difference with SSR as Theo points out is now the framework, language and even components for the server and client rendering are now the same. Previously they would normally be different say PHP for initial render and JS for client updates. You can definitely do it, but it’s not as slick and integrated as the same thing for both parts.
Yes, now you can do pretty much exactly the same as you did with ajax back then, but using single programming language, single paradigm and less boilerplate.
@@romankoncek150, @Hugo Wride, Indeed. It is an improvement for sure! It just not as if we had not have the concept before, we just have better tools to execute it.
Yeah we're going back to our roots. Building back Java but the new modern and modular Java for the web 😂
@@hugowride4582 Yea, and we're bound to return to having a different language as well, as modern PHP and Java offer better performance for SSR than Node or even Deno.
SSR is the definition of premature optimisations. There is so much low hanging fruit people could do before SSR should be considered... but it's trendy and that's enough I guess
💯. SSR is simply overkill in most cases
@@supdudd5436 Do you think Vite is enough?
SSR is the industry going back to php slowly
Php was great
Exception Object is not a Object.
This comment hurts my ego. PHP indeed seems to have had the right idea.
The things PHP got right were a) didn't try to abstract away the HTTP request cycle in the way crap like JSP/ASP/JSF did, and b) easy to get going. The rest of the language and standard library is... not so good™.
SSR was already present since a long time ago. This is SSR 2.0
Man, you are putting out some BANGERS more recently. Keep up the great work, appreciate what you do Theo!
ugh I love these excalidraw videos... thanks for the effort on these, unbelievably helpful!
Ty so much for helping me learn and grow, Theo! Love your content. Definitely subbed with notifications set to all.
When I get a job I’ll be able to be a greater value to your channel but….im working hard to stay organized and on task.
Describing the traditional SSR and next.js's SSR model separately was so helpful for me getting where I was stuck at! It was so helpful. Thanks.
Your explanations (in tandem with Excalidraw illustrations) are the best I've ever seen. Thank you.
This is legitimately one of the best explanations of the differences between traditional PHP vs. clientside rendered vs. SSR content serving. REALLY. WELL. DONE. 👍
But he thinks that PHP is faster that JS...
In my previous React app, we cache even the index.html file, so this whole SPA model was about 1ms because the user already had everything cached in their browser, It worked like magic, no component hydration no BS, just good old React app, after each release, we clean the index.html file so it gives the headers with the new base javascript to all users, also we split our App in multiple bundles for each page, by doing this we could handle millions of request with a super cheap server because the CDN was actually doing all the work for us.
PS: with HTTP/2 everything its done all at once its not like this step by step as shown in the video, this happens super fast.
Amazing content very well explained! Thanks a lot Theo! 😀
Great video. As someone who is gonna start playing with next soon, i really needed the high level overview.
Would help if you can make another video on how it is implemented too.
Many more videos coming soon
@@t3dotgg Yes pleasee
Amazing explanation, thank you for that Theo!
This is pure gold. Thx for shearing your knowledge!
Thanks so much for this explanation, just wonderfully done :)
Help me a ton, i was having the questions but didn't know where to find answer. Thanks theo
with CSR you've got fast loading too, if not fastest, on subsequent requests though and one can minimize initial rendering with suspense, fetching all the other chunks in background, while user stays on some page
ok watched a few times now and man i feel like i owe you 1000$ for this. ive been struggling with hydration too and this covered evertything so well. most people just talk about the topic, but you always talk about how the topic fits in the greater environment, and thats what i need where i dont know what i dont know. THANKS COACH
Fantastic explanation, thank you for this.
Amazing video Theo. Your videos are tidbits into tech topics that are so ideal in giving brief overviews of new trends. I really like how you took the time to graph and visualize how the flow of package load has changed over these past times. Keep up the great work
this is so clear and inspiring! the visuals are so easy to understand and i love it! i wonder what software you were using to draw these models. anyways, thanks a lot!
Thanks for posting this. Very helpful
This is the best explanation of SSR I've been able to find on RUclips. Well Done.
Awesome video. As a backend dev that has observed the cycle from the sidelines, it's funny to see that we're going back to rendering content on the backend/server side. The question that pops into my head is if embracing this will make it harder to build a pwa (mainly offline support)? Or is some caching layer enough to make this work decently?
funny is just a nice word.. call it like it is nosense. if the problem is big JS bundle the solution is to use less JS, but the brains behind react want cash so they say everythings needs to be rendered on the server and the sheps follows.
pwa's are kind of dead
for basically all usecases that pwa's were intended for, building mobile apps is the way to go
@@anyadatzaklatszjutub Seems like you missed the point of pwa then
@@marlonjerezisla6496Exactly. React is a great component framework, but SSR for anything other than ordinary HTML is nonsense. Also no startups are gonna use SSR for their
Thanks I recently learned this and this was a good overview.
I think it is good that we get tooling to setup the rendering and it's data-flows easily. For example in some instances I'd rather have a loading spinner than a page with buttons I cannot click.
Great videos,, always learning new
Really great video ! Loved it
Great entry point for people that aren't that sure about the differences between all these techniques!
Thanks Theo! Always great resource of information.
Though I was waiting for the "oh look! it returns a JSON with the content 'users are not subscribing to your channel!'" :D
Honestly one of my favorite videos you've made
This content is so insanely valuable to someone like me... thank you
Theo's channel is the missing senior devs from most companies who actually care about you and know their shit
Theo Breaks down the necessary things us develop don't investigate ourselves in depth
I never really thought about why one framework is better than the other besides ease of us, but this is just as important for performance.
Gen Z probably doesn't know what "Ajax" is.
This one was helpful to understand why the freak we need SSR frameworks. It makes the Developer experience much much simpler along with the SSR model compared to the traditional server rendered model of using a server and templating engine. The last part was really informative as well, we can have blocking renders for things that are essential for our App and have Suspense states for non-essential components.
It was Gmail that changed the game when it was released, they used ajax to handle the massive data in the browser and replace part of the page without needing to refresh the whole page. You forgot to mention Backbonjs that actually started the spa framework or libraries 4-5 years before React.
Really helpful content!
Interesting video, looking forward to more
This was great. Are you going to do more videos on this topic? And do you know of any great resources I could go to learn more?
The editor is smooth, love all the care ❤
The complexity of these models are so high
Love your contnet, hope you keep it up
The issue with this new model is state sync complexity between client and server, especially if you use a store system like redux.
For complex applications, where lots of interactivity is required clientside, i still prefer the tradeoff of the spa model, where logic and store is in a single place at the costs of an initial longer load
This was extremely helpful.
I’m an old man now but I rememer pushing against SPAs because of how gd slow they were in most implementations
For a veeeery long time after spas were the new shinys, expertly maintained multipages with selective Ajax interactions were by far way faster than any other sites.
In fact, to this day, the fastest possible experiences are essentially old-style mvc/php with manual dom updates.
Look I get it that server rendered sites can’t do what spas do, but having become an expert at both and the inbetween, spas were engineered by non-frontend guys to solve problems that didn’t really exist in 95% use cases.
And forgive me for my smugness but I can make a website that will beat every single framework out there and give the same experience or better.
The problems were always get the page down fast, fully hydrated. Yep, asp/php.
Onload fetch likely/potential resources like top-level navigation templates, preload images, etc.
We also did things that I still think has a place that is no longer done, and use css to show and hide modals, instead of creating and destroying html elements.
There’s a lot of things we used to do with css that was just much faster than updating the dom and rerendering.
JavaScript is a great tool but it’s just so overrelied on now imo.
It’s just so amusing all of the technologies that are “new” that aren’t new at all. “Microfontends” that’s literally what we used to do, return small pieces of html and js as needed and insert them into the page.
Technology always seems to go in circles~
Oh and selective use of templating with knockout or maybe vue if you want to get fancy.
But most pages never really have much of a usecase for templating.
Grids and such usually do their own templating. But for where you do need templating, it’s fine it’s an incredibly simple technology. Take the template, hydrate it, create element, register its handle with a controller, stick it in the page.
And the JavaScript for all of these things are incredibly small, so you have to look at these js file sizes and wonder, Jesus h Christ in a chicken basket, wtf are the doing? Launching a satellite or rendering a website??
😂 hh great comment, i very like it
Hands Down, best explanation by Maestro Theo.
Thank you for this ❤
I never understood why people prefer SSR over an instant static response. Personalization often can't be served from the database alone but includes data in the browser (preferences, hardware info, local storage, indexeddb, ...) making SSR not feasible for a lot of things. Feature flags can be done static, too. So you end up doing SSR for 5% personalized data together with 95% of what could be static. Hydration is already slow. SSR is added on top. Potential cold starts are added on top. Higher infrastructure costs as well. Not a great recipe.
this is a great video to learn about SSR
brilliant explanation!
Hey Theo! Huge thanks for the detailed explanation!
My concern is how w/ this RSC approach we could do real-time apps?
I mean, when some component subscribes to db data in this case we propbably should avoid using RSC for this component right?
6:21 Are first two steps cached by the browser after subsequent app visits?
great explanation.
Back in the day we didn't do a whole page refresh when we needed data updated, ajax has been around since 1999. I remember aspnet update panels in 2000 that did what nextjs is now trying to do. I've been coding webapps exactly as your describing 20 years ago. What is new is actually old.
The reason SSR is so popular is that Vercel wants to sell you server compute time. That is how they make money. MOST people would be better off with static site generation and hosting on a CDN. Even the non-beta docs in NextJS recommend SSG over SSR.
SSG only works for the simplest of sites. Most businesses need content generated dynamically and often based on the user, geolocation, and other parameters.
That's not true , any reputable business that needs to rank high in Google, will undoubtedly require the website to be SSR. SEO is the main reason why SSR exists. Also this video doesn't explain well how SSR works, HTML is send from server once, not multiple times.
To be honest, I only think the SEO stuff is worth it for SSR. Else, how things are rendered can still be quite well controlled in CSR so the user experience is still very good. If you are not creating a full-stack app where the rendering server is the one making database requests, then the unnecessary mental overhead doesn't seem worth it. I may stand corrected tho. Nice talk!
totally agreed. only point of SSR is to have SEO managed. Otherwise CSR frameworks are small and optimized enough to render client app almost instantly.
free rendering on client. why pay for ssr server..
crawler bots should wait for app to render.
@@PranavJindal999 wich CSR framework are you referring to?
I don't think you are getting the actual point of SSR.
SEO (although one of the most important) is not the only reason to do SSR.
Its also faster initial load, accessibility, less JS -> more perf, more reach to users.
I agree that SPA > MPA in terms of UX. But at some degree, performance should also be taken into consideration because.. people are impatient, and if you don't load faster, people will bounce and no one is going to stick around to use the amazing UX the app will provide.
@@PranavJindal999 CSR frameworks are small and optimized is probably the biggest lie I have ever heard. You think sending 300kb of JS just to render HTML is "small and optimized" compared to sending a 50kb HTML file? Even with a highly optimized framework like Svelte, you are stilll dealing with 150kb of JS to render MARKUP. Also, the worst thing you can do is predict what your client has to run the app. And you saying free rendering on client, isn't always trusted. Many people have low powered devices (You may build your beautiful SPA on a M1 MacBook Pro, but many of your users are on low powered mobile devices), and they struggle to use your 1MB JS app just because *you got lazy to SSR your page*
SSR is like build tools, if you use it, your app will have a broader rich, faster loads, and better user reviews.
Also, last point I find hilarious "crawler bots should wait for app to render"
You are basically telling the google and other search engine crawlers "pay my bills for more computation to render my app's markup". Also, you should not assume all your users AS WELL AS crawlers are on the same super-fast computer that you are on. They run on low powered or high-throughput devices that don't have the computation power to run an entire JS engine like v8 and give it enough memory to run your web app's supposed but misused interactive part.
Using JS to enhance is better than empowering JS to make the app collapse.
@@Dev-Siri Who in their right mind would push 1MB of javascript to their client, you can split your JS files to reduce the bundle and cache the entire thing.
I never understood SSR's objective, even the SEO is a damn lie, first WHY would I improve the SEO of a React app? I want to improve the SEO on the landing page which ofc is not made with React, so I still didn't find the use case for SSR, you add complexity(components hydration) to the project for what? Also, any device nowadays can handle a React app, like my phone has more cores than my PC damn, why do I need to send all the template generation back to the server? Sending to the client is WAAY more cost-efficient and once the client has cached my JS files they will only fetch the pages/files I update because I split my React app into multiple bundles. I put everything behind a CDN and voila, it's done, assets being delivered near the client location at max speed with almost zero cost, CDN saves a lot of requests to my server because it caches the server assets.
What's the name of the tool you use to draw the diagram?
i used ssr react components but i didnt know you could combine them with suspends, nice!!
Theo, can you compare CSR vs SSR vs RSC for subsequent page loads, e.g. the user is already on one page, then navigates to a second page within the site
Crazy details 👌
What program are you using Theo for writing and drawing on the screen?
And thanks for the amazing explanation.
Excalidraw
Great historical perspective!!
This is the channel to follow if you want to learn things from first principle.
Thank you so much ❤, and Can I know what is the software you are using here to draw those diagrams ? Is that a plugin for Obsidian ?
this has been my question in my prototype note taking app
In other words, instead of returning an empty HTML (like with CRA), you get to return content in it and it's up to you how much content you want to return. This likely reduces the number of spinners and waterfall effects on the UX.
in CSR it's the client which makes a lot of request.
in SSR it's the server which makes a lot of responses.
The number of responses from the sever is same I think for both CSR and SSR
I do enjoy writing JS/TS, the language has come a long way and does a lot of stuff out of the box, especially combined with Vite or Webpack... but the framework world is akin to a backpacker that leaves on his travels with a bare empty suitcase and come back home with 3 shipping containers full of clobber from each country he visited...
With each problem it solves it gets closer to where it all started only significantly heavier :D haha
Kudos for the videos.
wheres the video u mentioned at the end i cant see it
Wow, this is a good refresher on javascript..
Haven't touch it in years. So much has changed.
Thank you, I appreciate it.
Bare with me..
I'm re-learning javascript.
So I'm assuming a hybrid model would consist of some stuff loading in the background automatically and some stuff are being loaded up ONLY IF the user decide what they chooses to load up?
I remember how everyone was moving from MPA to SPA. And the idea was to change slider movies to nice interactive application experience in SPA. Now we are going back to a bit faster by still slide movie. And I wonder what will take to build same level of interactivity in MPA.
I thought this was intuitive as a good UX practice, the user wants to be up-to-date with the page rendering progress, especially on lower end devices that tend to generally lag. Regardless, it's a good concept that must be definitely adopted more on the web.
5:04 Won't CDN's inline the JS into script tags in the original index.html file so that the second round-trip to the CDN to fetch the JS isn't needed?
Great video, but how do I manage a multi-client solution, where I have a web app and a mobile app from the same business logic. Is there SSR for mobile app like on react native. If I have to write api for mobile app, does it not mean i am duplicating backend code with SSR?
I have a question regarding the implementation of web apps using the MPA approach, which involves utilizing HTML, CSS, JS, and server-side scripting like PHP for an example. Then I'm curious about the necessity of Server-Side Rendering (SSR) in this particular context.
Nice video, thx man
ne bazar' shlyapik
Am I understanding correctly? The SSR model we've arrived at is very similar to how Laravel/RoR sites with React components are doing? I'm curious why this wasn't the approach from the beginning.
because JS likes to re-invent everything!
On a more serious note, its not quite the same. I'm not sure how you're using laravel/RoR to render react components, but to do SSR the way JS frameworks define it as, you'll need to be running a node-server to render the component for the frontend to use.
We initially had the SPA/Backend separation because coupling our backend with frontend HTML templates was typically a bad idea. So SPAs were created and JSON was used to communicate the data with the frontend and now the 2 were decoupled. However more complicated frontends became slower because the JS bundle it had to download and process on first load was huge.
The solution? JS flavoured SSR! Well actually its more like splitting the SPA into a app-router on the client side and let most of the processing happen on the server. Then when the client requests a page, the server returns the relevant component markup in the way the framework understands. Its a good middle ground solution. So the separation is something like this:
React NextJs Backend (backend could be laravel/RoR or direct to DB).
This way there's still no coupling between your backend and frontend.
Watching the video, I honestly didn't hear any advantages of SSR over classic MPA with AJAX, which we have had since roughly 2005.
Other than limited developer skills, I still don't understand why a dev would use interpreted JavaScript on the server instead of compiled language/framework using C#, Java, etc.
Thank you for the video - well done!
Theo, I understand SSR is really nice for rendering. But CSR and SSR both should be infused in an app, by making everything SSR your cost for spinning the server processing is high. So we need to do an analysis to lower cost without losing performance. Today devices and computer have fast processor so the issue of CSR is being slow is their but we need to do cost analysis on that. Cost of running a server is always huge for small or big company. #ServerCost
What diagramming tool is that? Looks awesome
ACKCHYUALLY...React is a library. Not a framework.
frameworks are collections of libraries!
Not even React creators believe that anymore lol
But everyone uses it inside a framework for the most part
It's a framework, they're not fooling anyone
@@austincodes You can use it inside an OS. Does that make it an operating system? No, still a library.
SSR is a solution to a non-problem. If you're building a static site where performance and SEO are important, use pure html/SSG. If you're building a dynamic application where SEO is less of a concern, show loading spinners for an extra couple hundred milliseconds. Separate your concerns and choose the tool that excels in its domain. This is a much better solution than adopting SSR which is a half-baked solution that adds a significant mental, practical and maintenance complexity to your application. Also, don't forget the vendor lock-in that comes w/ Vercel.
Building web apps for many years I learned that there is always a tool you need, which is not cover all your requirements.
SSR is a great technology when you know what you get. If there is a hot cache and proper separation on servers, good availability, this may save time for user, performance on servers, speed up CD and save a lot of money for customer. BUT, only of there is a need for this.
Once I was working on video hosting service and there was a need for SSR, to make better position in Google and start video immediately after page runs (which is unrelated to SSR, but whatever). And the cheme you've showed in your example would be great solution. Unfortunately, it wasn't. Anyway, there is always a possibility to make great app using correct tools.
I like that Freddie Mercury, after an outstanding career as a rockstar, started to help me on my software engineering path!
SSR sounds great if you deploy to Vercel/Netlify. What if you have requirements to deploy on AWS/MSFT/GOOL cloud ?
Yes, but you can still independent of framework choose to not show the spinners and make it look and feel like it's SSR rendered without SSR. It will be faster just to load the necessary data rather than sending chunks of html. The browser still need to render every pixel on screen. I don't think we should be afraid of DOM manipulation, I think we just need a better way of doing so.
This was an amazing video, super clear and concise. Does anyone know if there is a way to gain control of the loading state of NextJS SSR pages? I get that you gain performance because the entire page is returned, but when page loads are long in low network conditions, I've noticed theres a bit of an awkward period where youre not sure if a button press is actually doing anything while the server renders the page/component. Thanks!
Thing that i don't understand is how does next managing to do this?
Like how next rendering a server component inside a client component how does this work?
Web dev roadmap going absolutely crazy.
Wouldn't it be a good reason to use "mfe" architecture to help/complement/replace some of the "component" architecture?
Brilliant!