Super Simplified HTML Rendering
Published: 2019-02-25 12:21:47

---
title: Super Simplified HTML Rendering
published: true
description: 
tags: 
cover_image: https://thepracticaldev.s3.amazonaws.com/i/s9idondhhl26yi1uaoqg.jpg
---

I wanted to provide a quick overview of the different ways html can be rendered. At various points I have found myself needing to explain these concepts to either non technical folks or someone just learning web development.

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

This is done with a protocol call HTTP. The webpage you visit is an HTML document that comes in an HTTP response from a server. This web page will probably then send other requests to the server for things like JavaScript, CSS, images, or dynamic content.

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

Do you need turn your complex web page into a series of reusable components such as navigation, buttons, forms, and footers? Does the web page need to perform lots of data updates as the user interacts with it, pulling in new data and sending data to the server to be saved? Well it can be tough to do all of that if the HTML can only be rendered on the server itself. Instead of doing that, we can just generate the HTML right in the browser. Load in your applications JavaScript, load in the data you want to display, and render the HTML right then and there.

Check out [my blog](https://www.alexlockhart.me/) for more of my musings upon technology and various other topics.