Static Websites

“Static Websites” are websites made entirely of static files. They’re usually made by writing content in text files which are run through some program to turn them in to a set of html/css/js files to serve on the web.

Static sites are different than your usual site because they do not run any “code” on the server and because of that they can be safely hosted by others at scale like AWS S3, Netlify, Vercel, Firebase, and etc.

Making a Static Site Link to heading

Why to make a static site Link to heading

Static sites have become very popular because they’re cheap and easy to maintain.

• Cheap
  • Static sites are small and storage is extremely cheap (near zero)
  • “No code” just static files; which means the service hosting your website doesn’t need to worry about tightly isolating tenants and can share more of a server to host many users.
  • Serving static files requires very little CPU and a large server serving many websites can handle serving your site for less than a server you run just for yourself. Because it needs to be able to handle many websites at once it makes sense to use a more powerful machine than what you would use for yourself which can also handle spikes in traffic better.
  • Using files to store the content means not needing a database nor maintaining or scaling that database during traffic spikes (“Hug of Death”)
• Secure and Low Maintenance
  • No database means it can’t be attacked/compromised/etc.
  • No code means the website itself doesn’t have anything to exploit
  • Because the server just needs to serve static files it can be locked down more extensively than a typical website is locked down.

Given how cheap, secure, and low maintenance static sites can be it’s no wonder they’ve become increasingly popular since Github announced Github Pages and Jekyll in 2008.

That said let’s go over some reasons to not use a static website and some nuances of how people actually use static websites today.

1. Static websites require a “generate/compile” process which for some SSGs can take a long time (Jekyll is particularly slow for even medium websites).
2. Most static website systems are designed by developers for developers which requires experience with Markdown and Git at a minimum.
3. Most static websites still need some server-side logic which is what the JAMstack has tried to address which uses serverless functions to provide the minimal api functionality needed by the static site (e.g. to power a “Contact Us” form).

Hosting Static Sites Link to heading

Today’s computers, operating systems, web servers, and internet connections can handle a lot of data.

Static sites on the other hand usually are not actually that much data. An excellent example is a personal blog which often has less than a couple thousand pages and is not updated often (less often than every minute. often once a month or two).

Static Site Generators Link to heading

While you could make your own static site by hand it would be difficult to maintain. A lot of the reason “static” websites went out of favor initially was that dynamic websites made it easier to maintain many pages consistently.

Static Site Generators (SSG)¹ like Hugo[^this-side-uses], Jekyll, or Gastby let you choose a theme and write content in text files that can be used to generate the HTML that actually gets served to users. Because they use text files for the content you can now manage your content via something like Git, Github, and Pull Requests.

List of (some) Static Site Generators:

• Hugo
• Jekyll
• Gastby
• Next.js[^next-js]
• E11venty
• Pelican

Hugo Link to heading

This website, and pretty much all my websites, are built using Hugo. There are alternatives, ones which I’d probably like more generally (Zola maybe), but I’ve used Hugo for a long time and I picked it as a “long term” pick because at the end of the day I barely maintain my websites as much as I should².

Build a Hugo Site with a Nix Flake Link to heading

This is the flake.nix I use to build this website (for local testing only for now). I have patched it together from a lot of different resources online, but it’s pretty bullet proof.

Anywhere I have nix I can run nix run . -- serve -wD and I have the particular version of hugo I was using before on either Linux or macOS.

There is a pending project to figure out the details of how I can deploy this on my dedicated server, but Netlify does a good job hosting this site so it’s pretty low priority.

{
  description = "Personal website for Chris Portela";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs";
    utils.url = "github:numtide/flake-utils";
    hugo-coder = {
      url = "github:luizdepra/hugo-coder";
      flake = false;
    };
  };

  outputs = inputs@{ self, nixpkgs, utils, ... }:
    utils.lib.eachSystem [
      utils.lib.system.x86_64-darwin
      utils.lib.system.x86_64-linux
      utils.lib.system.aarch64-darwin
      utils.lib.system.aarch64-linux
    ]
      (system:
        let
          pkgs = import nixpkgs {
            inherit system;
          };
        in
        rec {

          packages.website = pkgs.stdenv.mkDerivation {
            name = "website";
            src = self;
            buildInputs = [ pkgs.git pkgs.nodePackages.prettier ];
            buildPhase = ''
              mkdir -p themes
              ln -s ${inputs.hugo-coder} themes/hugo-coder
              sed -i -e 's/enableGitInfo = true/enableGitInfo = false/' config.toml
              ${pkgs.hugo}/bin/hugo
              ${pkgs.nodePackages.prettier}/bin/prettier -w public '!**/*.{js,css}'
            '';
            installPhase = "cp -r public $out";
          };

          defaultPackage = self.packages.${system}.website;

          apps = rec {
            hugo = utils.lib.mkApp { drv = pkgs.hugo; };
            default = hugo;
          };

          devShell =
            pkgs.mkShell { buildInputs = [ pkgs.nixfmt pkgs.hugo ]; };
        });
}