Caio Raphael

Fast first paint: Browser receives ready HTML, so content appears immediately.
SEO-friendly: Crawlers can index without running JS.
Better performance on low-end devices: Rendering work done server-side.
Predictable behavior: Consistent output independent of client environment.

Higher server load: Each request triggers a render.
Slower navigation between pages: Full or partial reloads unless hybridized.
Complex state management: Keeping client and server states in sync requires hydration.
More infrastructure complexity: Balancing caching, streaming, and SSR latency.

Slow initial load: The browser must download JS, parse it, and then render. Until that, the user sees nothing.
SEO issues: Search engines struggle or delay indexing JS-rendered content.
Poor performance on weak devices: Rendering and hydration cost CPU and memory.
Accessibility and fallback failures: No JS = no content.
Complex caching and debugging: Harder to reason about compared to static or SSR models.

.
The page could be either static index.html , or it could be generated with a function, based on parameters of the request.
The entire page at once.
When you click a link, you don't have any indication that something is going on, other than the loading bar at the top of the browser. You'll have to wait until the server gives back a response, for you to see something new.

.
You don't get the full page after a request, but a skeleton HTML.
This HTML is going to have a script tag in it.
The HTML is the same regardless of the page you are into.
"It's not just one API call. The amount of API calls performed are insane, like dozens, hundreds."
You can see the API calls made in the Network tab.
.
"When you have the ability to do everything on the client, you start to".
When navigate to /theprimeagen happens, the browser immediately generates a new page, like a spinning wheel.
This is cool, but surely has a lot of bloat until then. It's not for everything and it's not for everyone.

A soft-evolution of SPA.
.
It does a thing called hydration : it re-run the same React code so that your React can link up to the right places in the HTML.
Possible problems :
- If you press a button before a button is hydrated, the button will do nothing.
  - The framework Qwik thinks hydration is the root of all evil and wants to eliminate it.
- You might have to send data twice. One for the HTML, and another for the React code. This is done so if a text had a button on it, you'll need the JS to do stuff. In some cases you just have text, and therefore this is unnecessary.
  - There's a lot of benefits of the HTML having the content, but if it has a ton of content that doesn't change while you're at the page, you are just loading a bunch of things that don't belong to JS.
This method gives you the best of MPA and SPA, but also you get the worst of both.
- There are problems with Next.js, etc.
Good, not great.

An evolution of SSR'd SPA / Full SSR.
.
.
You have the benefit of having a SPA effect of clicking something and immediately seeing the result, due to client-side rendering, as well as having the benefit of not having to send JSON of all different ways to render to the client.
Instead of sending the giant pile of JavaScript that has all possible state your UI can be in and the JSON you actually need to do that render, you can just send the HTML.
This is what makes HTMX so magical. The server is not sending JSON down to the browser to transform into HTML, it just sends the right HTML. That's really cool.
You get the immediate navigation of the SPA. You get the HTML-first development of an MPA and you get a developer experience where you don't feel like you are fighting between these two different things.
Possible problems :
- You no longer have the SPA design where every page resolves into the same HTML file. You now have to have backend code running React. You cannot use this model if you are not using React on the server that resolves the entire website and every url.