Programming

17668 readers

177 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

My Cheatsheet for Website Rendering Strategies (self.programming)

submitted 2 years ago by o_o to c/programming

3 comments fedilink hide all child comments

Thought this might interest the general programming community as well! If you've ever been interested in the different types of ways websites can render themselves....

cross-posted from: https://programming.dev/post/223726

Here’s a quick summary of the different ways you can load a website.

SSR (Server Side Rendering): The classic way. Browser makes request to server, server creates an HTML/CSS/JS bundle, sends it to browser.

CSR (Client Side Rendering): The vanilla React way. Browser makes a request to server, server sends back JS code which runs on browser, creating the HTML/CSS and triggering browser to further make requests to load all assets.

SSG (Static Site Generation): The “gotta go fast” way. Server creates an HTML/CSS/JS bundle for web pages at build time. When browser requests a page, the server just sends this pre-built bundle back.

ISG (Incremental Static Generation): The “imma cache stuff” way. Server may create some HTML/CSS/JS bundles for web pages at build time. When the browser requests a page, the server sends this pre-built bundle back. If a pre-built bundle doesn’t exist, it falls back to CSR while it builds the bundle for future requests. The server may auto-rebuild bundles after certain time intervals to support changing content.

ESR (Edge Slice Re-rendering): The “cutting edge, let's get latency down so low it's practically in hell” way. Server does SSG and tells the CDN to cache the bundles. Then, it instructs the CDN to update the bundle in the event that page content needs to change.

In order of performance, usually: (SSG = ISG = ESR) > CSR > SSR

In order of SEO: (SSR = SSG = ISG = ESR) > CSR

In order of correctness (will users be shown “stale” information?): (SSR = CSR) > ESR > ISG > SSG

top 3 comments

sorted by: hot top controversial new old

[–] [email protected] 4 points 2 years ago (1 children)

Something worth considering with client side rendering, is the idea that the user may not be able to tell the difference between "still rendering" and "done", making me want that final "order of correctness" flow to have a branch for client side rendering that includes a "maybe?" in case there's a server connection somewhere that's slow or broken.

I'm sure I'm getting too pedantic because this post isn't about best practices for implementing it, and I'm currently bitter about a tool I have to use that does it poorly, having no difference between "fetching information" (aka, still rendering), "no information to fetch" (aka, done rendering), and "connection broken, please refresh" (aka, reboot the server, AGAIN).

[–] o_o 3 points 2 years ago

Agreed! I think this is generalizable to say that CSR is when you need to show "loading indicators" which is kind of annoying because.... I had to send the loading indicator from server -> browser.... so it was loading just to load some more.

[–] [email protected] 1 points 2 years ago

Thank you, that's a really nice summary : )