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/
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
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
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.
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!
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)
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
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 legitimately one of the best explanations of the differences between traditional PHP vs. clientside rendered vs. SSR content serving. REALLY. WELL. DONE. 👍
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™.
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.
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
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.
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.
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??
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.
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
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
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.
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.
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.
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
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.
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
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.
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
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.
SSR is almost never a good solution for apps that doesn't need to be SEO friendly like dashboards. By doing CSR, you ship the client code once, and then on it's just Ajax requests. If cache is implemented properly, reloading the whole page will be instantaneous. Moreover CSR can reduce load your server because it doesn't have to render HTML, which can reduce your cost. Takeaway: SSR for public facing websites that need to be indexed by Google and other search engines. CSR for web apps which are usually behind a login page and that don't need to be indexed by Google.
This is exactly what me as total newbie trying to get an overview was wondering. When to use what principle. Thank you for your comment! Just to clarify: If I don't want to be scraped or indexed I use client side rendering and change it a lot around. if I want to be found (i.e. I want to sell something) I use server side rendering?
And now we’re reimplementing functionality the browser already does, but this time with JavaScript sprinkled on top of it. It’s silly how the browser, a perfectly valid and capable client, is being used to load another client. The browser is already a hypermedia client, best to use it as such.
@@Htbaayes but keeping state in the DOM, and mutating said state directly, is slow and expensive at anything beyond moderate scale. Executing state transitions in-memory is still much more performant, hence why so many JS solutions exist IMO, HTML and the DOM were never suitable abstractions for highly interactive web apps. They were really just designed to render static content, a sentiment that still holds true to this day
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!
I have been watching your SSR knowledge sharing videos for the past couple of months now. They are very helpful in trying to make sense of all this and I am very grateful that us developers have a resource like your channel for current and future reference. Thank you for that. That being said, I find that this new direction, that the React ecosystem is pushing so vehemently towards, feels very unnatural and over-engineered. I understand that there are cases where this kind of optimisation makes sense, but it is making it the default that worries me the most. Because React has such a huge user base, this new paradigm is essentially going to be shoved down their throats. I believe there is a sweet spot in API design, where you can obtain a reasonable amount of user guidance without being too opinionated. If there's one thing that was definitely not missing in React, that thing is more complexity. I know lots of smart engineers are putting huge efforts into this and I have a huge amount of respect for their work. I very much hope I'm the one who's wrong here.
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.
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.
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've been extremely opinionated all through the entire fad of offloading template rendering to the clients' devices. I grew up in circumstances where I didn't always have blazing fast internet that could load a chonky javascript framework in (comparatively) no time flat, nor did I always have devices with enough compute power for such websites to not be a complete draaaaaag on the entire system while I waited for upwards of a minute or two for everything to _eventually_ fully load in. I've always been firmly in the camp of shipping fully-rendered documents to the client, with only enough javascript attached to add the necessary interactivity, and even THAT javascript needs to be MINIMAL. To the point that I would literally implement my own polyfills and ship only the polyfills I needed to ship to get the functionality I wanted out of a page, instead of just falling back entirely on jQuery or similar and shipping a humongous universal polyfill with way more functionality than I was ever going to need or use. I care more about the user experience being lightweight and snappy after load than bogged down by needing to fetch fetch fetch fetch from the server and rendering everything in one bit at a time and occasionally breaking because whoops some script failed somewhere and now this little bit of functionality the user expects _isn't there anymore._ If I had to build a more dynamic site, I would much rather create pre-rendered cached pages that can satisfy common requests and deliver those so that the server response to a page request can be _instant_ with no rendering load, and for everything on the page to get shipped at once to the user. If you want to do SSR with hydration, I think that the pre-rendered page that ships to the user should also ship with some minimal extra DHTML and javascript for at least bare minimum functionality. That way if the main javascript that actually handles all of the more real-time behavior of the page fails to load (likely due to dodgy internet or the page just having been sat on for a while with zero user interaction), the page that the client gets is at least minimally interactive and still Just Works™.
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 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
We should mention that our server will have a heavy load, which will increase the bill of our instances instead to let the client process and deal with Steve rendering and use the power of edge computing
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!
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.
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?
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
Cant wait to see my inbox with users asking why they are clicking and nothing is happening. Don't seems that beneficial at all, gonna skip this trend and wait for 2 to 3 months to see the next big revolutionary crazy idea js developers come up with.
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 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.
Right after the 1st load, SPA becomes way faster than SSR and RSC since all it needs is the data to render and all assets are cached locally, the rendering happens instantly and ONLY the data required for the next rendering is being requested. there is no way to beat this model as long as any of this knowledge is hold by the server, which means it always requires more data send over the wire to get the same job done, and for this more data, the server is doing more unnecessary work. RSC is even worse, for every route change, the payload contains more data than SPA since the “render” is happening on the server, the payload contains the result of the React component call. And if you are building a PWA, just forget about any server render technique, they can not even close to beat your speed right after the 1st load… SSR is only for solving the 1st rendering problem and this problem only, which is why Remix.js got it right(right after the 1st render, it is a plain SPA). Also, The scaling of SSR is worse for self-hosting since now you have an extra server to receive the traffic, all the cache problems you have for the backend, you have to solve them again here. For most SaaS, a proper architecture for the front end is SSG your before-auth and SPA your after-auth if you aim for the best UX.
SSR was never conceived or popularised as a performance tool but rather as SEO helper, one route one html. Isomorphic applications simply download the HTML on the first load for the route that is requested via http , it gets hydrated and the app never does NOT NEED another server call to obtain extra HTML, from that moment on it's purely SPA for every subsequent route.
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
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?
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.
SEO needs prerendering, because crawlers may stop loading assets or otherwise decide a page has finished loading junk when it actually hasn't. Actual users are a lot more tolerant of app times. If users complain, you probably did it wrong.
Amazing how no one talks about PWAs, offline first apps, realtime collaborative apps or hardcore client side caching and optimistic updates. Just having an api that’s event driven complicates the whole rsc paradigm to the point that making a db update and having to wait 500ms for the backend to process it before revalidation is a challenge. I guess everybody’s building blogs and ecommerce nowadays…
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/
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
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
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.
@@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.
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!
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)
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
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 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...
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
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
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
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
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.
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.
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
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 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
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.
ugh I love these excalidraw videos... thanks for the effort on these, unbelievably helpful!
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
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
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.
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.
Man, you are putting out some BANGERS more recently. Keep up the great work, appreciate what you do Theo!
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.
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
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.
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.
This is the best explanation of SSR I've been able to find on RUclips. Well Done.
Your explanations (in tandem with Excalidraw illustrations) are the best I've ever seen. Thank you.
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 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.
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.
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
Great entry point for people that aren't that sure about the differences between all these techniques!
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 is the channel to follow if you want to learn things from first principle.
This is pure gold. Thx for shearing your knowledge!
SSR is almost never a good solution for apps that doesn't need to be SEO friendly like dashboards. By doing CSR, you ship the client code once, and then on it's just Ajax requests. If cache is implemented properly, reloading the whole page will be instantaneous. Moreover CSR can reduce load your server because it doesn't have to render HTML, which can reduce your cost.
Takeaway:
SSR for public facing websites that need to be indexed by Google and other search engines.
CSR for web apps which are usually behind a login page and that don't need to be indexed by Google.
This is exactly what me as total newbie trying to get an overview was wondering. When to use what principle. Thank you for your comment! Just to clarify: If I don't want to be scraped or indexed I use client side rendering and change it a lot around. if I want to be found (i.e. I want to sell something) I use server side rendering?
And now we’re reimplementing functionality the browser already does, but this time with JavaScript sprinkled on top of it. It’s silly how the browser, a perfectly valid and capable client, is being used to load another client. The browser is already a hypermedia client, best to use it as such.
@@Htbaayes but keeping state in the DOM, and mutating said state directly, is slow and expensive at anything beyond moderate scale.
Executing state transitions in-memory is still much more performant, hence why so many JS solutions exist
IMO, HTML and the DOM were never suitable abstractions for highly interactive web apps. They were really just designed to render static content, a sentiment that still holds true to this day
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!
Help me a ton, i was having the questions but didn't know where to find answer. Thanks theo
Hands Down, best explanation by Maestro Theo.
Honestly one of my favorite videos you've made
I have been watching your SSR knowledge sharing videos for the past couple of months now. They are very helpful in trying to make sense of all this and I am very grateful that us developers have a resource like your channel for current and future reference. Thank you for that.
That being said, I find that this new direction, that the React ecosystem is pushing so vehemently towards, feels very unnatural and over-engineered. I understand that there are cases where this kind of optimisation makes sense, but it is making it the default that worries me the most. Because React has such a huge user base, this new paradigm is essentially going to be shoved down their throats. I believe there is a sweet spot in API design, where you can obtain a reasonable amount of user guidance without being too opinionated. If there's one thing that was definitely not missing in React, that thing is more complexity.
I know lots of smart engineers are putting huge efforts into this and I have a huge amount of respect for their work. I very much hope I'm the one who's wrong here.
Amazing content very well explained! Thanks a lot Theo! 😀
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.
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.
Amazing explanation, thank you for that Theo!
Thanks so much for this explanation, just wonderfully done :)
Web dev roadmap going absolutely crazy.
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've been extremely opinionated all through the entire fad of offloading template rendering to the clients' devices. I grew up in circumstances where I didn't always have blazing fast internet that could load a chonky javascript framework in (comparatively) no time flat, nor did I always have devices with enough compute power for such websites to not be a complete draaaaaag on the entire system while I waited for upwards of a minute or two for everything to _eventually_ fully load in.
I've always been firmly in the camp of shipping fully-rendered documents to the client, with only enough javascript attached to add the necessary interactivity, and even THAT javascript needs to be MINIMAL. To the point that I would literally implement my own polyfills and ship only the polyfills I needed to ship to get the functionality I wanted out of a page, instead of just falling back entirely on jQuery or similar and shipping a humongous universal polyfill with way more functionality than I was ever going to need or use.
I care more about the user experience being lightweight and snappy after load than bogged down by needing to fetch fetch fetch fetch from the server and rendering everything in one bit at a time and occasionally breaking because whoops some script failed somewhere and now this little bit of functionality the user expects _isn't there anymore._ If I had to build a more dynamic site, I would much rather create pre-rendered cached pages that can satisfy common requests and deliver those so that the server response to a page request can be _instant_ with no rendering load, and for everything on the page to get shipped at once to the user.
If you want to do SSR with hydration, I think that the pre-rendered page that ships to the user should also ship with some minimal extra DHTML and javascript for at least bare minimum functionality. That way if the main javascript that actually handles all of the more real-time behavior of the page fails to load (likely due to dodgy internet or the page just having been sat on for a while with zero user interaction), the page that the client gets is at least minimally interactive and still Just Works™.
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 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.
Fantastic explanation, thank you for this.
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 like that Freddie Mercury, after an outstanding career as a rockstar, started to help me on my software engineering path!
i used ssr react components but i didnt know you could combine them with suspends, nice!!
this is a great video to learn about SSR
I can't help thinking of SSR as reverting back to the days of LAMP.
We should mention that our server will have a heavy load, which will increase the bill of our instances instead to let the client process and deal with Steve rendering and use the power of edge computing
6:21 Are first two steps cached by the browser after subsequent app visits?
great explanation.
The editor is smooth, love all the care ❤
awesome video, thank you!
Interesting video, looking forward to more
Gen Z probably doesn't know what "Ajax" is.
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!
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 has been my question in my prototype note taking app
Really great video ! Loved it
What program are you using Theo for writing and drawing on the screen?
And thanks for the amazing explanation.
Excalidraw
Great historical perspective!!
This was extremely helpful.
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?
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
Cant wait to see my inbox with users asking why they are clicking and nothing is happening.
Don't seems that beneficial at all, gonna skip this trend and wait for 2 to 3 months to see the next big revolutionary crazy idea js developers come up with.
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
Great videos,, always learning new
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.
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?
Right after the 1st load, SPA becomes way faster than SSR and RSC since all it needs is the data to render and all assets are cached locally, the rendering happens instantly and ONLY the data required for the next rendering is being requested.
there is no way to beat this model as long as any of this knowledge is hold by the server, which means it always requires more data send over the wire to get the same job done, and for this more data, the server is doing more unnecessary work. RSC is even worse, for every route change, the payload contains more data than SPA since the “render” is happening on the server, the payload contains the result of the React component call.
And if you are building a PWA, just forget about any server render technique, they can not even close to beat your speed right after the 1st load…
SSR is only for solving the 1st rendering problem and this problem only, which is why Remix.js got it right(right after the 1st render, it is a plain SPA).
Also, The scaling of SSR is worse for self-hosting since now you have an extra server to receive the traffic, all the cache problems you have for the backend, you have to solve them again here.
For most SaaS, a proper architecture for the front end is SSG your before-auth and SPA your after-auth if you aim for the best UX.
SSR was never conceived or popularised as a performance tool but rather as SEO helper, one route one html. Isomorphic applications simply download the HTML on the first load for the route that is requested via http , it gets hydrated and the app never does NOT NEED another server call to obtain extra HTML, from that moment on it's purely SPA for every subsequent route.
Grapqhl is security nightmare at the backend
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
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?
Love your contnet, hope you keep it up
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.
SEO needs prerendering, because crawlers may stop loading assets or otherwise decide a page has finished loading junk when it actually hasn't.
Actual users are a lot more tolerant of app times. If users complain, you probably did it wrong.
We are changing to a new pattern of development because search engines can't read meta-data
Amazing how no one talks about PWAs, offline first apps, realtime collaborative apps or hardcore client side caching and optimistic updates. Just having an api that’s event driven complicates the whole rsc paradigm to the point that making a db update and having to wait 500ms for the backend to process it before revalidation is a challenge.
I guess everybody’s building blogs and ecommerce nowadays…
Idk, i just use next js and leave it at that.
shit I am a non native speaker but I understood everything. This is so well put.
What's the name of the tool you use to draw the diagram?
Really helpful content!
brilliant explanation!