Super Simplified HTML Rendering
To begin begin our super simplified HTML rendering we need to start with a super simplified overview of web architecture.
The browser sends a "request" to a server:
Browser -> Network -> Server
A server sends a "response" to the browser:
Server -> Network -> Browser
If this super simplified web architecture already got the HTML to the browser, then why do we need to render it? And what does it even mean to render it?
HTML needs rendered because content on websites is almost always dynamic at some level. It might need updated slowly over time, it might be different based upon the user visiting, and it might change as they interact with the website. Rendering HTML means that you create the HTML in an automated way. Here are the different ways to render HTML:
Don't render it
Okay, you got me. This one doesn't really count. But the developers could write every line of HTML by hand. Do you have a dozen web pages each with the same header and footer? The header and footer would need copied and pasted onto each webpage.
Static Site Generator
That copying and pasting is a hassle. Instead the developers could use a templating engine and write the html once, and then generate each web page with the same header and footer.
Static Site Generator with Deployment Hooks
It's a pain for a developer to have to go in and regenerate the whole website every time something changes. We can automate this by looking for changes in the code and then regenerating the website every time something changes.
Server Side Rendering
Maybe our html contains information that is stored in a database, could change at any time, and always needs to be up to date. Leave your static site generation behind, on to server side rendering we go. Instead of generating the html as the code is being developed or in a deployment hook, we generate it when a request for a webpage comes to the server. This way it is always up to date.
Client Side Rendering