2026-07-20
According to Auntie Wiki, one of the first known versions of the “Hello, world” program appeared in a 1972 book written by Brian Kernighan, A Tutorial Introduction to the Language B. The author used three external variables representing ‘hell’, ‘o, w’, and ‘orld’, and stitched them together with a trailing ‘!*n’ to print hello, world! on the terminal along with a newline character. Of course, that book was published only four years after I was born, so I wouldn’t have known any of that at the time.
This “Hello, world” web page is a static index.html page created using Hugo, an open-source static website generator. Hugo takes content written in simple Markdown files and combines it with HTML embedded with some Go templating to build a static HTML website. To add new content, the user simply creates a new Markdown file, then tells Hugo to rebuild the website.
Depending on the complexity of the templates and the computer’s performance, rebuilding a 1000-page site could take as little as one second. To upload the updated website to a web server, the user could issue a command like rsync -avz -e "ssh" /home/localuser/project/public/ user@example.com:path/to/public/html/ which would only upload changed files to the server. Granted, if the user changed a template that affected every page on the site, then it could take a little while to upload everything, but if the user just added one page of content, then the upload could be almost instantaneous.
The user could eliminate the need to upload files to the web server entirely by editing the templates and Markdown content files directly on the web server, and then run the single Hugo executable directly on the server (assuming the web host allows that). There are also advanced methods to use Git for continuous integration and delivery of edited templates and Markdown content files to the web server, achieving almost automagic updates.
Hugo isn’t new. It’s been around since 2013. I just hadn’t heard of it before. Why am I ditching WordPress for a static website generator in 2026? Two reasons.
Reason one: Because I can.
Reason two requires a trip down memory lane.
If we were to ask Aunt Google, “What was the first publicly available website on the World Wide Web after it was opened to the public in 1993?” she would respond with info.cern.ch. This was literally the first website, and it explained to the world what the World Wide Web was, and how people could access it and add to it. Before that, being “online” was very different from what we think of today. BBSs, Prodigy, CompuServe, I had used them all, but it wasn’t until 1996 that I first experienced the World Wide Web for myself.
I had been asked to log into my CompuServe account, open a terminal, and type in some esoteric address. What I found was a text document. Some of the text appeared highlighted. Tabbing over to the highlighted text and pressing a key would change all the text on the screen. Some of the new text appeared highlighted. Tabbing over to that text and pressing the same key changed all the text on the screen again. I didn’t understand what just happened. Ten minutes later, it kicked me off because this was a timed trial connection. I tried it again. And again. I finally figured out how to go back to the previous document. That was when I first understood hyperlinking, and that was when I was hooked. It wasn’t long before I went to my local computer store, bought Netscape Navigator, and ditched CompuServe in favor of a local, fledgling, dial-up Internet service provider.
And, yes, I am one of the few who actually paid for a web browser because I was still on Windows 3.1 (which did not come with a web browser) until I bought my first laptop in 1997, a Compaq Presario 1080, which came with Windows 95 and Internet Explorer.
By 1998, I was teaching myself HTML, acquired my domain name in 1999, and started coding websites for others as a side gig. By then, it was already apparent that websites with frequently updated content tended to percolate to the top of search engines. However, most website owners didn’t want to learn how to edit their own HTML pages to update content, and they certainly didn’t want to pay a web developer to do it every time. Clearly, content management systems for the masses would be the next big thing in web development.
The first content management system (CMS) I played with was Movable Type after discovering Wil Wheaton’s early blog. This was the bees knees for a blogging-style website because users could update their own content ad nauseam and readers could leave comments. Over the years I tried many other content management systems like Drupal, Joomla, and WordPress (among others), and they all work in a similar way. An SQL database on the back end feeds content to a templating system which outputs HTML to your browser.
Most content management systems also make it possible to add lots of other features to a website besides blogging, such as contact forms, calendars, e-commerce, forums, file sharing, photo galleries and more. Sometimes these modules come built-in with the base system, other times you need to rely on third-party plugins which are relatively easy to install. Some plugins are free and others will cost you.
Although this is certainly an elegant way to make it easy for owners to update their own content and provide valuable features on their website (anybody can be taught how to enter content into a web form and hit the Submit button), it’s sort of a clunky way to deliver that content to the reader. Unless there’s some sort of page caching system, each page of content sent to a visitor has to be built each time the page is viewed which takes processing cycles on the server.
Plus, if you’re not careful, a poorly written CMS, module, or plugin could leave your website open to attacks by bad actors who could add, delete, or change content on your site, or worse. The simple fact that a CMS is running on a web server is enough to attract spiders hunting for known vulnerabilities to exploit. I’ve had a Drupal site hacked before. I’ve had a WordPress site hacked, too. Not fun recovering from either.
After about 20 years using different content management systems, I started to miss the simplicity of a static HTML website. There’s no PHP code running on the server, and no database running in the background, so the attack surface for hackers becomes smaller. And since there is no processing on the server every time a visitor wants to read a page, content tends to load very fast in the browser. Of course, manually editing static content and uploading it to a server would not be as convenient as just filling out a web form and hitting a Submit button. But it’s not a deal breaker either for a small website, especially for someone comfortable using a simple text editor and a command line.
What features might someone be giving up by switching to a static website? The most obvious loss would be interactive features that require server-side processing, such as comments, contact forms, and forums.
Although it would be nice to provide visitors an opportunity to leave comments so they can give me a piece of their mind, I have usually left comments turned off in my content management systems because they are such a spam magnet. So…much…spam…it just wasn’t worth it. Besides, my website is mostly published for my own reference, and so I can occasionally scratch a writing itch. If what I write happens to be useful to someone else, cool, their comments might be nice without the spam. But I’m not looking for validation in the form of comments (if I needed validation, I would join Facebook), so it’s not a deal breaker if there is no comment system.
It would be nice to provide visitors the ability to contact me if they wanted to, but I certainly don’t want to post my personal email address in a mailto: link because my inbox would be flooded with spam. I also know that simply obfuscating my email address is fools game. I know there’s a way to use Google Sign-In to authenticate users before they can submit a contact form. That would at least require some effort on the part of the sender to have a valid Google account, but that would put a wall up for anyone who doesn’t use Google (including me ever since Google abandoned their original “don’t be evil” imperative). I could put a Signal.Me link on the site. Of course, that puts up a different wall for people who don’t use Signal, but I might be okay with that wall. If someone really wanted to contact me, at least they’d have a very secure way to do so, and it might help introduce people to Signal.
Another idea for dealing with comments and the ability to contact me would be to start a Mastodon account and direct visitors there. Yup, another wall, and it’s certainly not a private solution. But Mastodon’s federated platform is generally considered less toxic than other social media sites (*cough* Twitter/X), so it could be an option.
One final solution would be to find or write a server-side script to process contact form submissions directly on the server. This reintroduces some security risk, of course, but a well-written script with the very limited focus of processing a contact form should, in theory, be easier to secure than a sprawling CMS and database.
Content management systems certainly provide other features that are helpful for maintaining a website, such as dashboards, WYSIWYG editors, spellcheck, version control, SEO tools, e-commerce, etc. Some of these could be replicated in creative ways for a static website. For example, publishing using Git could provide version control, and writing content using a word processor capable of saving files in Markdown format, such as the current version of LibreOffice, could provide spellcheck and some WYSIWYG functionality.
It should be clear by now that going static does have its challenges, so not every website owner can or should abandon their CMS. However, since I am not relying on any of the interactive features conveniently provided by these content management systems, I think it makes sense for me to go static. Besides, I think I would enjoy the process much like I did when I first started 28 years ago.
While coding HTML files by hand is certainly old-school cool, that doesn’t mean we can’t use automation where possible. That is where Hugo comes in.
Instead of hand coding the structure and content for every HTML page on a website individually, which could quickly become tedious, Hugo lets us hand code reusable HTML and Go template files we need for things like headers, footers, and navigation. Next, using whatever text editor is preferred, content is written and saved in simple-to-understand Markdown files. Then, a single hugo build command is issued at the command line to build the entire site by automatically combining the template files with the Markdown content files. In the event a site owner is just adding a single page of content, this rebuild process is nearly instantaneous. In the event a site owner decides to change a base template file that applies to every page on the site, no problem. Hugo is designed to be fast. Depending on the complexity of the website, 1000 pages could be rebuilt in about one second using just a basic 4-core laptop. Extremely complex websites do take longer to rebuild, but that processing time can be significantly reduced by smartly caching layouts and partials, and by limiting the number of taxonomies. Finally, to make the changes public, the entire website is uploaded to the web server (or better yet, only the changes are uploaded with rsync, which is much faster).
With a static HTML website created by Hugo, there’s no buggy CMS or plugin code to worry about, no database susceptible to SQL injections, and pages tend to load extremely fast. Will it have all the features of a typical CMS? No, especially when it comes to interactive features like comments, contact forms, and forums. But some of those features could be provided by creative application of third-party software or services.
In spite of the challenges, for my use case, Hugo is kind of like my mechanical wristwatch. Sure, I could wear an Apple watch with all bells and whistles. But I don’t need a watch that can play music, monitor my heart rate, protect my hearing, track my sleep, chat with Siri, find a family member, browse photos, take dictation, and answer my phone. What I need is a watch that tells time within reasonable accuracy, and where I can enjoy the occasional manual steps necessary to maintain that accuracy.
Simpler times, y’know?