All right, so as promised, let's discuss what the difference is between server-side rendering and client-side rendering. So as briefly discussed in the last lesson,

server-side rendering comes through with all of the initial markup needed for the initial page load already rendered out and provided directly inside of the document of our response.

Client-side rendering, however, just has the mounting element and nothing inside of the mounting element for our view application, React or whatever it is they may be using there.

Beyond that initial render with subsequent requests, they both will behave the same. They just come through with data needed to update the page accordingly.

So in the back here on the left, I have our actual plot my course application that we'll be building out that we created in the last lesson. Then on top on the right hand side,

I have a client-side rendered application with SSR disabled. So if I were to expand my inertia application over here, go into app, we just have an app.ts.

That would look the exact same as our app.ts on our server-side rendered application, but we do not have a SSR application on our client-side rendered as we don't need it.

Beyond that, the CSS and pages both look the exact same, and they both have a separate TS config from our AdonisJS application as well.

Additionally, resources, views, and our initial layout looks the exact same too. It's got our VEAP method adding in our scripts in our initial inertia page, and

then it also has the inertia head and the inertia tag as well. If I go ahead and do Ctrl+tilde, open up the terminal, and we boot these up, so npm run up there.

All right, so our client-side application is at 3333, and we jump over to our server-side application, command-tilde, npm run dev. This one will be at 52914.

If we go ahead and open up our server-side application now, so I'm gonna command-click on it, and that will open up our browser here. This is our server-side rendered application, and I'll go ahead and

just jump back into Visual Studio Code and hop over to our client-side one, command-click on that to open that one up as well. The left tab here is our server-side rendered application, and

on the right-hand side here is our client-side rendered application. So if we open up the Inspect panel and take a look specifically at our network,

and it's the document request that we're most interested in here, go ahead and give this page a refresh. All right, you can see we have all of our scripts coming through here. That looks fine. Let's scroll up to our document though, and

let's take a look at the response, specifically the role response. Within here, you can see our VEAP scripts getting added in, as well as that initial page component right there.

And then inside of our actual body, we have our InertiaJS application mounting point, and that's provided all of the initial page data as a data page attribute.

So if we scroll over to the right though, we can see that this element contains no information, it's just empty. That's where the main differences between client and server-side rendering happens.

Client-side rendering will come through completely empty for our mounting element. It's up to the client-side to then register all of the scripts for

the scripts to run and to render out the initial content. If we were to jump into our expect panel, and there is our app ID right there, take a look at the child content.

There is all of the content being rendered out, specifically on the client side. None of what's inside of this app element here is rendered and

provided by our server whatsoever, as this element is completely empty. If, however, we were to jump over to our server-side rendered application,

right-click on this, inspect, jump into the network panel, expand this out a little bit, and give it a refresh. All right, we see all of our scripts come through. That's a-okay again.

Let's jump up to our document, take a look at the response, and specifically the raw response. Again, you see all of the scripts come through along with our initial page component.

That looks fine, but inside of our body here now, we have our mounting element, again with all of the initial page data as data page attribute right there.

But if we scroll over to the right-hand side, you'll see that this element is not empty and actually contains all of that initial HTML that we see directly on the page.

This was furthermore insinuated whenever we took a look at the actual preview of the rendered content. We see all of the content come through with the actual response,

whereas with our client-side application, all of the content is completely empty. There's no content coming through with the document whatsoever. And that's because with our server-side rendered application,

it's making that initial render on the server-side, hence the name server-side render. Now beyond the initial render, they both will behave the same. We don't have any additional pages right now, but

it just comes through as an API response with the updated page data. And then the client-side will make that update accordingly. So it's just the initial render here that's happening server-side,

which is the same as any server-side rendered client application. So what are the pros and cons here? Well, server-side rendering requires the HTML generated on the server-side

to match the initial render on the client-side. This is what we discussed in the last lesson as hydration mismatch. Furthermore, packages may or may not support SSR or server-side rendering.

So you will need to check on a per package basis to see whether or not it supports server-side rendering. However, since the rise in popularity of Next and Nuxt, a lot more packages have been taking SSR into consideration.

So this is less of an issue nowadays as it was back when it was a brand new subject. Some of the pros of SSR though is since the HTML is initially rendered on

the server, we're gonna have a quicker initial load time since it doesn't need to load all of the scripts to then render it out. It already has the initial render ready to go directly from the document.

Because of that, SSR is generally recommended whenever SEO or search engine optimization is important for your application,

which is typically important for content-rich applications, stuff like blogs, marketing materials, and things of that nature.

Really anything that you would want search engines to be able to pick up on and recommend your site for. Now, yes, as a caveat, Google has been able to read JavaScript for quite some time now. But the scope and

effectiveness of it being able to read that has been up for debate. And since you do have that initial render time being quicker with SSR, it's still generally recommended.

Client-side rendered apps, on the other hand, are just much more straightforward and easy to work with because you don't have the extra complexities of SSR to worry

about, and you don't have the hydration mismatches to worry about either. It only ever needs to worry about serving content directly inside of the user's browser rather than on your server.

So at a top level, the debate between server-side rendered and client-side rendered for your application comes down to, do you need search engines to be able to read and recommend your content?

In our particular case for our application, we don't need it whatsoever. But because server-side rendering takes some extra steps, we're gonna cover that throughout the series, so we are using SSR here.