Time for a website reboot

Remember when creating a website was as simple as creating html files with a text editor or WYSIWYG software and copying a folder to a web server? Easy peasy, relatively speaking. But also easy to make a big mess. Then databases and content management systems took over, increasing complexity, but it made it easier to publish without making a mess. And then it got even cooler, and more complicated with single page apps driven by feature rich javascript frameworks. Great technology advancements, to be sure. But with all of these advancements, we compromised simplicity of publishing things that don't need a complex dependency chain. It can still be easy to publish content, but the underlying dependencies and challenge in keeping everything up to date is tough.

I've had a variety of websites riding along on this journey since the early aughts. I loved designing the ideas. I'd make endless diagrams with boxes and lines. Writing code was like wielding magic. Seeing my code process requests, manipulate data in all kinds of ways, and send the response back to a browser when doing web development was my idea of fun. I speak about this in the past tense, but I still get a kick out of it.

But here's the thing. I've been around the block a few times now, and the joy of maintaining a server has run it's course. I'm ready to move on to something far simpler -- or at least keeps the simple parts simple. Earlier this summer I had a vision to publish content in a way that's fast and cheap and secure and integrates with the way I think I'd like to author content and publish it for the world to read.

The Vision

I wanted to bringing back the simplicity of publishing website content. And also to make it very, very affordable to host that website using cloud-native technologies. And ensure high availability and performance. And make it super easy to maintain. And alleviate the majority of the headaches involved in securing things down. No databases. No servers. Just flat files generated from content written. Very limited exposure to being hacked.

I get to just write content, and publishing it becomes an automatic step in the process of saving it. And I don't have to worry about maintenance. That's the vision.

The Project: Simple Site

Is anyone else doing this already. I'm about 100% sure the answer is "yes". Do I care? No. I felt like embarking on a journey that would give me the satisfaction of building something custom for fun, so I did :-D! I call it Simple Site.

Here are the pieces of the puzzle that make it all work.

Authoring

Author all content using Markdown syntax It's been around for over 20 years now, and picking up popularity. It was designed specifically for publishing content on the web, so it's a natural fit. Way easier that writing HTML.

I follow some simple conventions in authoring markdown files that map to publishing on the web.

• Folders containing the markdown files represent the categories of content.
• Files in the root directory would be like root pages on the site -- think "About" and "Contact" kinds of pages
• Metadata at the top of the page using a frontmatter convention offers a way of controlling how files are processed and published.

I keep that written content in a Github repository. Github is generous enough to offer free packages that make it possible to keep the content in a place where it's safe, backed up, and accessible from anywhere. Of course, it's all source controlled too. Another great benefit is that editing content can happen through the web interface. There's no need to author content on a local machine. At the moment, I'm intending to use Obsidian as my editor. Seems like all the cool kids are doing it these days, so why not. Fortunately, it is just a text editor, so I can easily swap for something different later.

Processing

Authoring in Markdown is simple, but it needs to be processed to work on the web.

I handle this with a relatively simple Python app that turns all of the written content into static html files that I can copy to a destination on the web for hosting. In concept it's relatively simple. I use html template files - one for a page of content for each markdown source, one for a category listing page, and another one for the home page - and then inject content into those html templates. The python app handles all of that, generates a menu, category listing pages, and saves the files in a way so they're ready to publish online.

Publishing

This is the cool part. I happen to be a big fan of GitHub actions. When certain events happen in a repository, you can execute a process that uses the code in the repository. For example, when committing a new file containing content that I want to publish to the repository that I use, I can check out code from another place, to execute the python app that generates html files from my source. Pretty slick.

But it gets better. This much effectively generates the files needed for an entire website, but they're not accessible yet. So, the next step in the action syncs all of the files to an AWS S3 bucket configured for static website hosting. There are other destinations that work similarly, like Github pages and Cloudflare Pages . I like both, but decided to start with S3.

That would be enough, but I also chose to layer CloudFront on top for further performance enhancement and SSL encryption.

The Reboot

Way back in 2006, I created this site, using the Blogger platform. Powerful in it's own right, but you know, time moves on.

I've rebooted to publish this site to be the one you see before you. Modernized in design. Reinvigorating my creativity. Now I can author content with relative ease, and publish it for high availability. The costs are free at the scale I'm working, and I expect that it will remain that way indefinitely, unless I publish very prolifically. And I don't have to worry about things breaking because there's very little that can actually break!

I'm excited as this get's rolling out. It's making the magic of the web happen for me all over again.