Rendering is a process of turning data and code into HTML that can be seen by the end user. Rendering can happen in either client(browser) or server, and it can be done all at once or partially, and these all have trade-offs in terms of ux performance and DX.

1. Basic and original rendering is static websites: in this rendering paradigm, you put together all of your web pages in advance, then upload them as static files to a storage bucket somewhere in the cloud and point a domain name to them. This works
2. Multi-page applications: where the HTML and data are put together dynamically on the server whenever a request comes in from browsers. The appearance of the website can change whenever the underlying data changes. Many biggest web apps today still use this approach.

Single-page applications (SPA): all the ui rendering happens in the browser, you start with one HTML page as a shell, then execute JavaScript to render the ui and fetch any required data with an additional HTTP network request. It's just a spa, it can still have multiple Routes, those Routes don't point to a server, they are just updated by JavaScript in the browser. The huge advantage of being instantaneous to the user, unlike multiple applications that might take at least 300 milliseconds or more to render the page.

SSR: something that could render HTML and Data on the server or the initial page load, then hydrate to client JavaScript afterwards. The general idea is that the initial request goes to a server and renders everything dynamically, then after that initial page load load JavaScript takes over to give you the app-like single-page applications experience. The drawback is that you need an actual server, and servers cost money.

SSG: slight variation on SSR is SSG. In this paradigm, you render all of your HTML in advance, then upload it to a static host like a storage bucket, but SSR it will hydrate to JavaScript after the initial page load. Websites like this are often called Jamstack. You get the simplicity and low-cost hosting of a static site with the app-like spa experience. The only disadvantage is that you have to redeploy your site whenever the data changes, and that's why they invented ISR.

6 . ISR: the idea is that you deploy a static site, but you redeploy individual pages on the fly on your server when the cache is invalidated. Normally, with a static site, you can just cache everything permanently on a CDN, making it extremely fast with ISR. The cache can be invalidated based on certain rules, like a specific amount of time, and when that happens, the pages will be rebuilt, and this allows you to handle dynamic data without the need for actual server deployments like you would with SSR. You get both worlds between SSR and SSG, but the drawback is that it's more complex to setup on your own and hydration problem. On the initial page load, the app might feel like it's frozen