Building Static Websites
I was wanting to create a website (this site) but have been out of the web-dev game for a long time. Though I've never done any significant web work, I look back fondly at my early days of learning HTML / JavaScript and how simply anyone could get started. The pages were simple and the dependencies straight forward.
However, that quickly gave way to using Dreamweaver, Wordpress and Drupal paired with ever increasing amount of libraries, plugins and databases. Each of these added functionality and convenience but at the expense of complexity. I found myself constantly worrying about security vulnerabilities, updates and managing servers rather than working on projects and writing posts.
In the end, I scrapped the sites and forgot about the whole thing, which brings us to today. There has been a resurgence of static websites and tools to build them, enough so to spark my interest and start this site. I'll recap my experiences so far and intend to keep posting as part of the experiment.
What Are Static Websites?
A static website is a site like any other, but it doesn't rely on databases or server-side scripting like PHP. As a result, it can not provide interactivity, comments, logins, etc. Instead, it merely serves up HTML and JavaScript hosted by any basic web server like Apache or NGINX.
This is likely similar to how many of us started: creating an index.html file and opening it with Notepad. This approach still works of course, however it becomes difficult to manage as the site grows larger. Additionally you're missing out on useful features like tagging, prebuilt themes, WYSIWYG editors, etc.
In order to bridge the gap between simplicity and functionality, there are numerous Content Management Systems (CMS) that you can install locally which help to build and structure a website. When you're ready to publish, it renders the content into static source files and uploads them to the server of your choice.
Like any website, you have the option of loading external resources such as fonts and libraries. However, in an effort to simplify and secure these sites, many of the CMSs bundle all dependencies within the compiled files.
Are they worth it?
So if a static website is defined by what it can't do, why would you bother? I would argue that the benefits fall into three main categories:
Simplicity: In order to get started with a static website, all that is needed is a web server like Apache or NGINX. In order to setup your build environment, it's as simple as installing a local CMS. If you have multiple editors, they can sync files via Google Drive, DropBox, etc (I use a self-hosted Nextcloud instance). Source control can all be managed via the Git service of your choice.
Security: Since the pages lack any form of input and there is no server-side code to run, the attack surface is drastically reduced. There are no updates to manage and no third party libraries to be compromised. Additionally, the lack of server-side scripting or cookies makes GDPR compliance easy.
Speed: Without server-side code, DB lookups or third party dependencies to load, pages load significantly faster. That speed and reduced size translates to reduced costs and better user-engagement.
What I'm using
As I mentioned, there are many CMS tools to choose from, including HUGO and Jekyll. However, I landed on Publii.
Publii strike a wonderful balance between simplicity and functionality. Additionally it's fully open source and committed to security:
"All official Publii themes that our team creates, both free and premium, do not use any CDN or third-party providers to deliver files. Instead, all files; fonts, scripts, icons, and CSS files, as well as any images Publii generates, are stored locally.
Basically, if you're running a base Publii website without any third-party extensions, then you're site should be fully GDPR compliant; no mess, no fear, no fuss."
https://getpublii.com/privacy-focused/
You simply download the installer and connect to the hosting solution of your choice. In my case, I'm going to GitHub Pages and use Cloudflare for DNS/WAF/Analytics.
So far, the simplicity of Publii was reason enough to get me interested in posting again. We'll see how it goes over the coming year.