My blogging stack

When picking a static website generator for publishing content (see my previous post for how I landed on Hugo), one should consider the entire writing and publishing stack and workflow: from brainstorming to writing to spellchecking to publishing. For example, I might have been happy with the Quarto blog as my static site generator, but writing my content in Notebooks¹ in VSCode or RStudio isn’t ideal. Below I list all the tools I use in my current content creation workflow, and is rounded off with a comparison of the markdown editors Typora](https://typora.io/) and iA Writer.

Ideation, writing and deployment

• Logseq. All my ideas start in this excellent outliner with backlinks. Whenever I get an idea about something to write about, I try to immediately write it into my Logseq graph, either on my phone or laptop. The same goes for iterating on existing ideas: whenever a new aspect to a topi pops up in my head, I try to add a new sub-bullet immediately to any existing “idea bullet points”. Logseq is also great for brainstorming and outlining posts. In fact, Logseq is such a great tool that it has impacted the way I take notes and manage tasks profoundly. Its rudimentary task management system is sufficient for my needs, so Logseq – the single tool – has now replaced my previous day-to-day stack of Todoist for tasks and Bear for notes. The possibility to create queries on my notes makes sure no tasks or tags disappear without me noticing. If you like to think in bullet points (AKA an outliner tool) and are curious about backlinks, I highly recommend giving this open-source tool a spin.
• Typora. While I love Logseq for what it does well, it is not an ideal tool for writing longer form documents, like blog posts. VSCode is too basic “text editor” for Markdown and not ideal for writing in my opinion. I’ve used Bear notes for several years, and while I am fond of it, it’s not exactly what I require for writing blog posts. Mainly because it is not a Markdown file editor; all notes made within Bear needs to be exported to Markdown, which makes it incompatible with my workflow. I want an editor that edits the Markdown documents in the /contents folder of my Hugo site directly and has good support for both plain text and rendered Markdown. The best alternative I have tried is Typora, which I now use for writing and editing all my Markdown files. I started with iA Writer, but I was not satisfied with it; then I tried Typora and I never looked back. For an in-detail comparison of Typora vs iA Writer, see the dedicated section below.
• LanguageTool via Obsidian. While I can get basic spellchecking directly in Typora (provided by macOS I think), I prefer to turn it off when writing to avoid interrupting my “writing Zen” and to get more “intelligent” spellchecking – when the post is ready for that. I landed on LanguageTool, a direct competitor to Grammarly. I prefer it over Grammarly mainly because it is open source software, it has a better privacy policy, is based in the EU and allows for spellchecking via a JSON API. The latter point opens for sending Markdown documents to the API and getting it back spellchecked. The LanguageTool plugin for Obsidian integrates well with a LanguageTool endpoint, and provides a nice spellchecking UI inside the Obsidian editor. This is much nicer than a workflow of copy-pasting back and forth into the LanguageTool UI (which doesn’t support Markdown syntax either). Obsidian should possibly have been mentioned in the bullet above: even though it is not what Obsidian is most known for, it is an excellent standalone Markdown editor. If you would rather not pay for a Markdown editor, Obsidian would be my recommendation.
• VSCode. I don’t use VSCode to edit post contents much, but for everything else. Change settings via YAML files, edit CSS or HTML templates, etc. It works very well for this, being language-agnostic and having integrated terminal and git support.
• Hugo generates my Markdown posts to a static website. And it does so very fast, it is great to see how the final output looks like instantly via the hot reloading. Performance is a feature. Go’s HTML templates have not mesmerized me, but they do their job well enough and are easy to tweak. For more on why I landed on Hugo and the DoIt theme, see my previous post.
• Netlify hosts my Hugo static site. It was straightforward to set up continuous deployment on push to main branch via a private GitHub repository. The 300 build minutes in Netlify’s free tier is plenty for my needs, especially given that the Hugo build is so fast. For this currently small site, the build averages at 15 seconds on Netlify’s VMs. I considered using GitHub Pages for this, and I might have been happy with that CDN hosting solution as well. I think the ease of setting Netlify up with continuous integration for Hugo and getting deploy previews were the main reasons for trying it out. So far, I am pleased with the choice, it has worked flawlessly.
• Kagi Ultimate. A tangent perhaps, but I’ve started to use LLM’s extensively for work and writing. It’s an excellent sparring partner for developing ideas and getting tailored information about any topic. I also use it to provide feedback on my writing. Like when I end up writing a paragraph I am not happy with, it may have good suggestions for improvements or sentence rewrites. I use the LLMs available through Kagi’s Ultimate plan; I’ve used the GPT4-Turbo model the most until now, but the recently released Claude 3 Opus model looks promising (but more eager on hallucinations, it seems 🤔).

Site extensions

• Plausible. I use Plausible for event tracking on this site. It is open source, hosted in EU, uses a lightweight front-end script and I like their stance on privacy. I don’t need to know who visits my site, but I appreciate accurate numbers. I am now using their paid service, which works well and is hassle-free. I like to contribute to open source software like this, but if I ever want to switch to hosting the backend service myself, that should be pretty straight-forward.

• giscus. The DoIt theme has built-in support for several commenting solutions. I opted for giscus since it is free and uses GitHub Discussions as the “back-end” (instead of GitHub Issues like utterances). Most readers of this blog have a GitHub account, I guess, so having the GitHub login requirement for commenting or reacting to posts should be fine.

• littlefoot.js. When writing a post, I find it challenging to decide if parenthetic information should be included in the main text or as a footnote². How much parenthetic information include in the main text vs. in a footnote depends on the post itself, in my opinion. For brief get-right-to-the-point posts, I prefer to put all parenthetic information in footnotes; for longer posts, it is fine to include most of it in the main text. But I did not like how my pages started to look when having many ³ footnotes. It both disrupts the reader flow, by making the reader scroll up and down on the page, and the footnotes end up taking much space at the bottom of the article. littlefoot.js is an easy-to-enable improvement, which transforms the footnotes as pop-ups on click via an ellipsis button. I needed to tweak the activation of the script in my baseof.html file to get support for math syntax via KaTex:

  <script type="application/javascript">
    littlefoot.default({
      activateCallback: function () {
        setTimeout(function () {
          renderMathInElement(document.body, {
            // KaTeX auto-render options here
            delimiters: [
              { left: "$$", right: "$$", display: true }, // For display/block math
              { left: "$", right: "$", display: false }, // For in-line math
              { left: "\\(", right: "\\)", display: false },
              // Add more delimiters as needed
            ]
          });
        }, 50); // Adjust delay as needed to ensure content is visible
      }
    });
  </script>
  

Typora vs iA Writer

At first, after doing research on the best Markdown-based editor for writing, I landed on iA Writer. My attitude to tools is: if I have to pay for the best tool for the job – making me some nudges more productive – I’ll do that. There are great things about iA Writer, and I think it was the first editor to offer focus and typewriter mode (which I tend to have enabled). But I ended up having too many quarrels with it. I then gave Typora a shot, and in almost all aspects I prefer it over iA Writer. I’ll first compare some functionality in the table below and then mention the bug in iA Writer that, ultimately, made me seek an alternative.

Then to the macOS iA Writer app bug that made me look for another editor. Occasionally, it edited on a copy of the original Markdown file I had opened. It is a strict requirement for my workflow that all open editors should be able to save and update changes to the same “master” Markdown document. I usually have three editors open at the same time when writing: iA Writer/Typora as the primary editor; Obsidian for spellchecking; VSCode for the entire Hugo site repository (which I occasionally use to also edit the Markdown posts). It seems like iA Writer gets into a state where it edits an internal cached copy of the original .md document, or such, resulting in state conflicts between editors. This is a blocker for me, I can’t have a tool in my workflow that behaves like this. This might be a bug that the iA Writer team will fix any time soon, but until then, I am reluctant to use iA Writer for anything apart from “light” editing of my files (e.g. cliché detection).