Before we get into extreme server side rendering (XSSR), we have to talk about normal server side rendering (SSR). This comes in two flavours, which I'm calling old-school and new-school.
Old-school SSR involves having a server which uses some logic to create the HTML of the web page on-the-fly. For example, you might hit /users/39, and it might give you the details of user 39. These details might be from a database, or they might come from somewhere else. The important part is there's no corresponding 39.html on the disk. The HTML is created dynamically by the back-end server. On the front-end side, there's no JavaScript or other logic required to render the page. As a result, once the page is loaded, there's no ability for it to be dynamic.
New-school SSR is similar to old-school SSR, but it does involve a bit of front-end JavaScript logic.
3 Comments
Deebster@programming.dev · 9 pts · 1y
This is gloriously insane and I love it.
And then to casually drop in that
::: spoiler spoiler (just RTFA, it's short) it uncovered a Pleroma bug by accidentally DOSing any instance that tried to generate a link preview... chef's kiss :::
drjkl@programming.dev · 3 pts · 1y
This reminds me of something (far, far simpler) that I did long ago. I wrote a small webapp that continually queried various servers and would keep the connection open to push new blocks as the server-side async queries completed. I ran into output-buffering issues (probably from the reverse-proxy server, but I can't be certain at this point) and ended up appending a 1K block of commented-out non-printing unicode characters to ensure it would get flushed to the browser. I called it the plunger. Probably not the best solution 😅
DannyBoy@sh.itjust.works · 2 pts · 1y
Very neat! The game was playable here in Ontario on fiber.