Blog update: Back to basics
Well, we're coming up on two consecutive months without posting, which means that this blog experiment has been a failure. Which is okay, of course. I probably have 10 times more failed projects than deployed projects. That rate seems okay to me, but that's a blog post for another day. Maybe. If the blog still exists. This is like my fourth try.
Just because the blog project has failed so far doesn't mean that I'm
going to give up on it, though! I'm giving it another shot now by
rewriting the static site generator behind this website... Or really I'm
removing the static site generator. I am now the static site generator.
This is my static site. Look around you. All of this is just native HTML
+ CSS. Absolutely no interactivity, no Javascript. It's honestly a
breath of fresh air from the React I write in my day job. Fiddling with
blog tech instead of writing posts seems like the kind of counter
productive activity that has caused all of my past blogging attempts to
fail, but it has led me to write this blog post. And this blog post
thankfully resets the TIME SINCE LAST BLOG
counter so that
I don't have to feel so bad about leaving the site unattended until at
least two more months.
The core of this rewrite is just going back to the basics and serving a totally static site. This page is just an HTML document that I wrote by hand, linked to a CSS stylesheet that I also wrote by hand. The index/main page are also just HTML documents that I will manually maintain by copying and pasting the formatting for linking to my most recent post.
I haven't really written static HTML/CSS websites since I learned how to
code during my fourth (?) grade summer technology camp. It's pretty
enjoyable, though, to write in semantic HTML5. To run a blog like this,
all it requires is settling on a common structure for each page. Then,
one stylesheet can be created that targets tags instead of classes or
ids which makes the HTML document much cleaner. Check out the source
code of this page to see the structure I've settled on. I just have one
big content
div that supports headings, paragraphs, lists,
and asides, so far. Images and code blocks are coming soon, then at that
point, we'll have all the tools we need to write any sort of blog post.
I was worried that having to write raw HTML as opposed to markdown would increase the effort required in writing each post, but that really doesn't seem to be the case. I'm writing this post now in VSCode, split-screened with an HTML preview window. I quite like this set up. It is perhaps a little less immersive and focussed than, say, a fullscreen Notion session, but that also might be a good thing. Processes that feel scrappy are easy to jump in and lab something out, whereas I've found that processes that feel clean and efficient and well-structured give me the impression that what I'm producing within those processes better have the same quality. Which, of course, then leads to perfectionism paralysis.
So my theory is that by writing within this suboptimal experience—with VSCode trying to code auto-complete every single word I type with Emmet Abbreviations, with paragraphs running off the right side of the page unless I enable Prettier word wrap, with this god-awful default HTML tag auto-close that never closes the tag how I want it—I will hopefully feel more at ease with writing freely and thus more frequently. We'll see how it actually turns out. Stay tuned.