The absurd complexity of server-side rendering

> Sure, but the first hit would've been a cache hit anyways.

Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory. It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake...and then inject the data into the template, before sending it down the wire.

> CDN would have the static bundle "at the edge" already for you.

The static bundle just saves on download time. The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage. Depending on how your client-side bundle is structured, it may be 100ms or 1s before it even begins to make the outbound request back to the API to fill in the necessary data to power your BI dashboard or whatever your use case is. And that's if your BI dashboard was structured to be optimal with all requests rolled up into one (additional architectural effort, easier to satisfy on SSR with multiple database hits having less impact to performance).

Edge functions like Cloudflare Workers have 0ms cold starts.

We're talking tiny fractions of a penny per request. For example, Cloudflare Workers have 100K free requests per day and then its $0.15 / 1 million requests after that.

Better user experience, and it might cost you pennies more per month vs. static + round-trip.

> documentation sites, blog-like sites

Sites like those can often be fully static sites.

Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.

Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.

Heavily cached server-side rendering and statically generated sites kinda converge at some point to the same thing

> Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory

Sure, I accept this.

> It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake

I contest all three parts of this.

* physically closer

How can this be guaranteed? You have no control over the closest Edge function vs Cloud Server to the user. It's just as likely your Edge function is farther away from the Cloud Server than the user is, from my view. Perhaps your cloud provider is offering you routing services you claim are superior, but given the nature of my questioning is anti-vendor-lock-in you'll understand I mostly disregard that.

* always quicker

How can this be true? The user's machine is quite nicely guaranteed to be somewhat available for the compute here - they issued the request themselves after all. Your machine, on the other hand, has a good chance of cold starting for this request or being hot because a bunch of other requests are being issued to it simultaneously. Given we have async steps in what the SSR is doing, backpressure from sharing resources with other users sounds worse than what we risk with a client machine.

* without the need for an additional HTTP handshake

Again, your Edge function seems likely to either be cold or busy, so this is only something you can speak about probabilistically

> The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage

HTML still needs to render a DOM, not sure you're hitting on the right points of the parsing... Plus if this page is meant to be interactive still, you've not gained anything with the initial SSR phase

> Depending on how your client-side bundle is structured, it may be 100ms or 1s to fill in the necessary data

It's just not a big deal, and it's laughable you'd make the example a BI dashboard because you rendered something nice for them initially in maybe 0.5s faster on a median request, in exchange for literally enormous complexity. But a BI user is probably going to be in there for a long time, interacting heavily with client-side JS you shipped and they had to parse and render and then also reconcile/hydrate

> easier to satisfy on SSR with multiple database hits having less impact to performance).

How is this easier to satisfy on SSR? You have minimal advantage on your Edge worker being closer to your database than the user, unless your Edge function is actually just sitting beside your database server. It has to make the same requests and transfer the same data the client would be transferring in order to perform this SSR, there are only savings here if your Cloud provider is offering you big vendor lock-in promotions.

> Better user experience, and it might cost you pennies more per month vs. static + round-trip.

> Cloudflare loss-leader pricing

Unconvincing.