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.
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 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 ?
If the return on subsequent requests is just data (say in JSON) and not in a rendered HTML then doesn't that mean that those pages are not SEO friendly as they're also not rendered on the server Sure the transition to that page will be smooth as it just swaps out the data in current page like a SPA, but doesn't that mean that when you use Next.js that only the first page is SEO friendly and everything else isn't
@@adityaanuragi6916 probably, but does it really matter? Maybe for your application SEO is important... but id argue for lots of single page webapps it doesn't matter
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. $
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)
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.
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.
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
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.
our B2B web app has a average heap size usage of 400mb+ lol. most people don't give a shit about performance and optimizations when using b2b apps. it's mostly the data/insights and value you get from what they app shows.
I think you point out the reason for ssr here. It's meant for public sites where initial page load should be complete and fast and also where seo is bettered by having search engines see the full render
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!
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
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.
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.
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™.
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
This is legitimately one of the best explanations of the differences between traditional PHP vs. clientside rendered vs. SSR content serving. REALLY. WELL. DONE. 👍
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.
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.
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
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.
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 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
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.
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.
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??
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.
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
What about T3 stack? It's means that after Server Components will be stable, then we will not need any typesafe connection between our backend and frontend, so no need to libraries like react-query or trpc?
While you did mention SEO with MPAs and SPAs, you completely left out the part when talking about SSRs and RSCs. SSR loades and sends the whole page to the client so the SEO is exactly the same as MPAs. RSCs can be problematic when it comes to SEO.
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!
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.
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
Did you leave out of the most important reason why SSR (espescially for buisneses) on purpose? It's for crawlers like Google and Bing as they arent really able to read javascript values so they can't properly index you.
@@nikko590 You don't need to do anything, every build of the same page have different js\css . But dont think you can't be indexed, al be it by other means.
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.
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
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 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.
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.
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.
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.
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?
Do you think that SSR (either page or component based) is mainly useful for the first load? Or is this useful for the entire app rendering process? My thought is that once the JS is loaded, cached and parsed, it's wat better to still using CSR for the updates and new data since it consumes less resources and bandwidth to return a JSON than the actual HTML (fetching + rendering server side) than hydration. So my take is to use SSR on the first load, and then CSR on subsequent updates, turning the app in a SPA. What's are your thoughts on that ?
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.
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
I know it was just an aside comment, but I liked it when you mentioned a performance improvement that could come from PHP. Too much nowadays people are too quick to belittle other technologies (especially "uncool" things like PHP) instead of recognizing that everything has advantages and disadvantages. Was nice to hear a good word about PHP from a JS channel.
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
how much would SSR affect the server performance comparing to SPA? Servers will now have to run React for each request, wouldn't it increase our AWS bills?
After knowing Primeagen, I also moved from 3 monitors to a 14-inch macbook screen. You don't need anything else if you have a proper windows manager tool
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.
Can somebody explain me something? Everybody is going crazy with react server components. So you basically get html page with first request, and then react takes over. This is the same thing Angular has done for years with Angular Universal. It gets you your html page and takes over and you basically get SPA. What is new?? Am I missing something? I feel like I don't understand some brand new feature, everyone is so exited about.(((
The level of hype is a function of React's large userbase. It's good that React users are getting useful features that others have enjoyed. Developer experience is a purely subjective measure, but familiarity with a particular framework does make you more productive. Switching frameworks for the sake of new features would lead to a decrease in developer productivity (at least initially).
Yes, it's the same. React people love to think that everyone they're not familiar with is automatically a shit "developer experience" but... it just makes my eyes roll.
im not entirely sure what the takeaway of this actually is. all of the stuff you talked about kinda sounds like a massively over-complicated way of making websites. the web is quite literally designed for the server to provide the correct html on the first request. am i wrong? the fancy self-updating content is all basically just workarounds that developers came up with to avoid having to refresh the page or redirect the user. personally, i think most html ought to be generated by the server. however, i also believe that the majority if that html should NOT be generated in real-time (on request) if it can be avoided. and if you can generate any of the additional html on the server instead of the client, you should also do that. but sometimes, a programmer may find it more convenient to generate that html in-browser using js instead of asking the server to do it. i really believe it depends on the app. sometimes it doesn't need to be fast, sleek, or fancy.
Make some videos about how to optimize a nextjs project, plz! I start to work with a wiki-like platform for company usage and nextjs just render everything really slow and even lighthouse show the lowest performance i ever seen
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!
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.
For the diagram at 15:48, does have to be hydrated in order to fetch the HTML for ? You're not talking about streaming a single index.html file in stages, right? That would only allow you to append new content at the bottom of the page. Each component couldn't have its own SSR model.
I am a bit biased against react. I'd pick angular for many reasons (one of which is the ease of use). But, even then, I'd say that while fat-client SPAs do put more stress on end user devices, that is the computational power that is already there and to most degree is not used. Why to take all that computations back to the server? Providing that after the first load all the static content will stay in cache, the differences will become fairly small. SSR is cool and all, but SPA is easier to work with.
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.
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 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 ?
If the return on subsequent requests is just data (say in JSON) and not in a rendered HTML then doesn't that mean that those pages are not SEO friendly as they're also not rendered on the server
Sure the transition to that page will be smooth as it just swaps out the data in current page like a SPA, but doesn't that mean that when you use Next.js that only the first page is SEO friendly and everything else isn't
@@adityaanuragi6916 probably, but does it really matter? Maybe for your application SEO is important... but id argue for lots of single page webapps it doesn't matter
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. $
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)
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. UA-cam 2024 still let's you @ only one person.
@@dennis_benjamin Amazing info, thanks, appreciated!
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.
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
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.
our B2B web app has a average heap size usage of 400mb+ lol. most people don't give a shit about performance and optimizations when using b2b apps. it's mostly the data/insights and value you get from what they app shows.
I think you point out the reason for ssr here. It's meant for public sites where initial page load should be complete and fast and also where seo is bettered by having search engines see the full render
@@JamesOfKSat that point why not just use Wordpress or a cms for your seo needs and core react for your actual internal application
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!
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?
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.
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
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
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
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...
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.
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
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
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.
The complexity of these models are so high
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
ugh I love these excalidraw videos... thanks for the effort on these, unbelievably helpful!
Man, you are putting out some BANGERS more recently. Keep up the great work, appreciate what you do Theo!
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.
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 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
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.
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.
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.
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
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.
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
What about T3 stack? It's means that after Server Components will be stable, then we will not need any typesafe connection between our backend and frontend, so no need to libraries like react-query or trpc?
While you did mention SEO with MPAs and SPAs, you completely left out the part when talking about SSRs and RSCs.
SSR loades and sends the whole page to the client so the SEO is exactly the same as MPAs.
RSCs can be problematic when it comes to SEO.
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!
6:21 Are first two steps cached by the browser after subsequent app visits?
great explanation.
What's the name of the tool you use to draw the diagram?
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
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.
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
Your explanations (in tandem with Excalidraw illustrations) are the best I've ever seen. Thank you.
What program are you using Theo for writing and drawing on the screen?
And thanks for the amazing explanation.
Excalidraw
This is the best explanation of SSR I've been able to find on UA-cam. Well Done.
Did you leave out of the most important reason why SSR (espescially for buisneses) on purpose? It's for crawlers like Google and Bing as they arent really able to read javascript values so they can't properly index you.
Newbie in web dev field. So if I don't want to be scraped/indexed I use client side rendering and change it around a lot?
@@nikko590 You don't need to do anything, every build of the same page have different js\css . But dont think you can't be indexed, al be it by other means.
This is pure gold. Thx for shearing your knowledge!
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.
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.
wheres the video u mentioned at the end i cant see it
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
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.
In the examples, why do we have to make a second request to fetch the javascript? Can't we include it directly in the html?
Amazing content very well explained! Thanks a lot Theo! 😀
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.
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.
Help me a ton, i was having the questions but didn't know where to find answer. Thanks theo
SSR sounds great if you deploy to Vercel/Netlify. What if you have requirements to deploy on AWS/MSFT/GOOL cloud ?
For a 4chan-like imageboard would you go with ISR or full SSR?
Great entry point for people that aren't that sure about the differences between all these techniques!
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.
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.
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?
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?
Thanks so much for this explanation, just wonderfully done :)
Do you think that SSR (either page or component based) is mainly useful for the first load? Or is this useful for the entire app rendering process? My thought is that once the JS is loaded, cached and parsed, it's wat better to still using CSR for the updates and new data since it consumes less resources and bandwidth to return a JSON than the actual HTML (fetching + rendering server side) than hydration. So my take is to use SSR on the first load, and then CSR on subsequent updates, turning the app in a SPA.
What's are your thoughts on that ?
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.
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
Web dev roadmap going absolutely crazy.
Amazing explanation, thank you for that Theo!
Wouldn't it be a good reason to use "mfe" architecture to help/complement/replace some of the "component" architecture?
Please, what is the name of the drawing software you are using ? Thanks
Honestly one of my favorite videos you've made
So, ssr is old and bad and now react will become ssr with extra step?
Tell me if I missed something, over the infinte amount of js to be runner
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 ?
Cool scribbles while you are talking. What program is it you are using for that? Edit: Saw it at the beginning, Exkalidraw!
This is the channel to follow if you want to learn things from first principle.
I know it was just an aside comment, but I liked it when you mentioned a performance improvement that could come from PHP. Too much nowadays people are too quick to belittle other technologies (especially "uncool" things like PHP) instead of recognizing that everything has advantages and disadvantages. Was nice to hear a good word about PHP from a JS channel.
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
Fantastic explanation, thank you for this.
awesome video, thank you!
Please enlighten me as to why we prefer using Next.js instead of something like Laravel?
how much would SSR affect the server performance comparing to SPA? Servers will now have to run React for each request, wouldn't it increase our AWS bills?
After knowing Primeagen, I also moved from 3 monitors to a 14-inch macbook screen. You don't need anything else if you have a proper windows manager tool
Theo or some hero, how can i work with t3 stack with tRPC and also do ssg or isg?
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.
Can somebody explain me something? Everybody is going crazy with react server components. So you basically get html page with first request, and then react takes over.
This is the same thing Angular has done for years with Angular Universal. It gets you your html page and takes over and you basically get SPA.
What is new?? Am I missing something? I feel like I don't understand some brand new feature, everyone is so exited about.(((
You’re looking at the spec sheet and not the actual developer experience
The level of hype is a function of React's large userbase. It's good that React users are getting useful features that others have enjoyed.
Developer experience is a purely subjective measure, but familiarity with a particular framework does make you more productive. Switching frameworks for the sake of new features would lead to a decrease in developer productivity (at least initially).
Yes, it's the same.
React people love to think that everyone they're not familiar with is automatically a shit "developer experience" but... it just makes my eyes roll.
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?
All of this doesn't really matter, if the page loads sub 1 sec. Even 2 or 3 sec for some cases.
im not entirely sure what the takeaway of this actually is. all of the stuff you talked about kinda sounds like a massively over-complicated way of making websites. the web is quite literally designed for the server to provide the correct html on the first request. am i wrong? the fancy self-updating content is all basically just workarounds that developers came up with to avoid having to refresh the page or redirect the user.
personally, i think most html ought to be generated by the server. however, i also believe that the majority if that html should NOT be generated in real-time (on request) if it can be avoided. and if you can generate any of the additional html on the server instead of the client, you should also do that. but sometimes, a programmer may find it more convenient to generate that html in-browser using js instead of asking the server to do it. i really believe it depends on the app. sometimes it doesn't need to be fast, sleek, or fancy.
Make some videos about how to optimize a nextjs project, plz! I start to work with a wiki-like platform for company usage and nextjs just render everything really slow and even lighthouse show the lowest performance i ever seen
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!
I can't help thinking of SSR as reverting back to the days of LAMP.
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.
For the diagram at 15:48, does have to be hydrated in order to fetch the HTML for ? You're not talking about streaming a single index.html file in stages, right? That would only allow you to append new content at the bottom of the page. Each component couldn't have its own SSR model.
Does not have to be hydrated, that's the whole point of streaming
Yeah I don't really know what I was thinking. Sorry for the stupid question
I don't like how you mostly gave credit to React. React was nowhere when JQuery or Knockout where already running SPAs. Heck, even AngularJS.
Idk, i just use next js and leave it at that.
.this can all be done with next js 12? or just next js 13 with server components?
i used ssr react components but i didnt know you could combine them with suspends, nice!!
Really great video ! Loved it
I am a bit biased against react. I'd pick angular for many reasons (one of which is the ease of use). But, even then, I'd say that while fat-client SPAs do put more stress on end user devices, that is the computational power that is already there and to most degree is not used. Why to take all that computations back to the server? Providing that after the first load all the static content will stay in cache, the differences will become fairly small. SSR is cool and all, but SPA is easier to work with.