Explain Static Generated vs. Pure HTML Sites Like I'm Five

Good people of the interwebs, please sort me out here. So, if the ultimate goal of static site generators (SSGs) is to output html files, then wouldn't it make sense to just create/write and then upload the HTML, CSS, and Javascript files directly to a host server vs. creating them in some kind of markdown language and framework first? Is the only reason for using markdown and using a generator like Jekyll, Hugo, etc, is because of readability issues when it comes to writing and reading the code? In other words, I could just create straight up HTML, CSS, and Javascript files, them load them to a server. Why should I go through the extra effort, time, etc. to introduce another language and framework into this when the ultimate output is the same?

Did you find this post useful? Show some love!

Because if you hand-write your HTML/CSS/JavaScript you wind up first copying and pasting a lot of boilerplate, then later updating the exact same markup in a million places if you ever change how any common piece works or looks. Writing markdown instead of HTML is nice, but the real reason to use a generator is for templating.

Static site generators allow you to focus on making new content, and all the stuff around your content (nav, footer, contact forms, site/blog indexes) is defined once.

Weird metaphor time: You've been tasked to build 100 LEGO houses for a friend, however you know your friend will only play with one of them at a time.. There are several ways you can go about this:

  1. Build 100 houses. If you start of building houses with red roofs, but then your friend comes by and decides they want blue ones, you have to go back and modify each house. However, your friend can play with any house they want, since they're all there. (Pure HTML)

  2. Make a robot that will build houses as requested. Your friend can only play with one house at a time, so the robot only needs to know how to build each of the 100 houses. Bonus: you only have to tell it how to build the main components of a house (walls, roof, foundation) once, and then tell it how houses 2-100 are different from House 1. So when your friend asks to play with one, it'll build it right then and there, though they may have to wait a few seconds before they can play. Problems may arise if your robot breaks down or gets hacked though. (CMS systems like Wordpress or Drupal).

  3. Make a robot that knows how to build houses, and tell it to build them all at once. Now your friend can play with any house they want without going through a robot first (like in number 2), but if you need to change something across all the houses, you just twist a knob and tell the robot to build them all again. This has the good parts of the first option (immediate and speedy availability), as well as the second option (automated building of common pieces across all houses, like roofs and walls). This robot is your static house site generator.

Side note: Is the plural of 'roof' really 'roofs'? Apparently 'rooves' is antiquated?

This is a fantastic explain-like-I'm-five! Thank you :-)

Classic DEV Post from Feb 11

Building Web Components with Vanilla JavaScript

Back in 2015, I was in the midst of learning my first front-end framework -- An...

Follow @aspittel to see more of their posts in your feed.
Matt Bryant
Member since Mar 13, 2018
Trending on dev.to
What's a recent frustrating bug you've had with a crazy simple solution?
#debugging #discuss #php
So You Learned React, and Now You Work with jQuery...
#career #beginners #productivity
What are your programming blogs?
Follow Friday!
Biggest aha moment
CSS 101: The Box Model
#css #html #webdesign #webdev
Postgres or mysql
Does anyone else feel bothered when people term us as coders instead of developers or programmers..?