SSR Before & After Next 13

Numerous individuals, myself included, embarked on their journey of learning Next.js with version 13. Nevertheless, my comprehension of Server-Side Rendering (SSR) was somewhat flawed until I delved into the historical workings of Next.js, specifically how it operated before the 13th version. Presented below is a succinct overview highlighting key concepts and distinctions between Next.js pre and post its 13th version. (please correct me if im wrong)

Pre-rendering

By default, Next.js pre-renders every page, meaning that HTML for each page is generated in advance rather than relying solely on client-side JavaScript. Pre-rendering can lead to improved performance and SEO. Each generated HTML includes the minimum JavaScript code required for that specific page. When a page loads in the browser, its JavaScript code runs, rendering the page fully interactive (referred to as "hydration").
it comes in two forms: SSR and SSG.

SSR & Hydration

SSR primarily focuses on the initial page load. When employing SSR, you transmit HTML to the client and subsequently load all your standard React JavaScript. The application becomes "hydrated" once the JavaScript is loaded, returning to its full functionality as a client-side React app. In essence, after the initial page load, your application remains the same as a regular React app, with the exception that the first page load consists of pure HTML.

React Server Components (RSC)

React Server Components are a new feature of react 18, they operate by executing all the logic of React components on the server and sending only the resulting HTML to the client, without the inclusion of JavaScript. so the end result is pure html and no subsequent hydration happens (no sending js for interactivity)

the cool thing about RSC is that you can use your fetch api DIRECTLY at the top of your component (not inside a useEffect).

before next 13

in a nutshell The traditional getServerSideProps function was basically doing the work of RSC (React Server Components) and also indicating that this page should be SSR (meaning pre-render the html and hydrate the js later for interactivity).

getServerSideProps was formerly used in Next.js to retrieve data on the server side and pass it as props to your page component. This was beneficial for pages that required pre-rendering of frequently updated data from an external API, such as a blog or a news site.

Utilizing getServerSideProps improved page performance and SEO by providing HTML to the client with pre-filled data.
Before Next.js version 13, getServerSideProps was the method for indicating that a page should utilize SSR, which entailed pre-rendering HTML per request and subsequently hydrating the JavaScript.

After next 13

After next 13, its has gotten even better with "use client" and RSC, all your components are RSC by default, which means no js generation, just html generated from the server and sent to the client, however if you needed interactivity and needed SSR instead of RSC you can indicate that a component is SSR by putting just "use client" at the top of your component (which means you should propably avoid fecthing data directly at the top of your component since that function will re-execute for each render, instead put it inside a useEffect() like you always used to).

Client components still participate in server-side rendering (SSR) or build-time static site generation (SSG), serving as clients to convert the initial render output of React components into HTML that can be rendered before downloading JavaScript bundles. However, they cannot leverage server-only features such as direct database access.