No longer writing my own damn HTML

I don't understand your hangup about using JavaScript to accomplish tasks that JavaScript is extremely well-suited to do. The idea that you are somehow imposing a burden on your visitors is an imaginary constraint which is actively consuming the finite minutes you have on the planet. This is a pyrrhic victory.

I am not advocating using SPAs of any kind, especially in a blog context. However, if there is a library which makes it easy to render MathML, why the hell wouldn't you just use it?

I'm not saying that I've never invented artificial constraints for myself; arbitrary goal posts that literally nobody but me would ever notice much less care about. I am saying that perspective is everything, and that sometimes it can be hard to see from the inside.

This is intended as an expression of care.

After many iterations of tools, systems, and processes, I have settled on writing in plain text, in Markdown, to identify headings, paragraphs, quotes, images, etc.

My reasoning and approach is that I or someone should be able to read it as it is and then have a tool parse it to spit out HTML for browsers, helping others read it with a better experience.

With thousands of posts, it would be complex for me to maintain them in HTML. Now, my blog is powered by Jekyll because of GitHub pages. However, I can quickly switch to any other tool with minor tweaks.

Locally, I see my blog posts as individual files with dates `YYYY-MM-DD` and the title in their yearly folder `YYYY`. Some are in `WIP`, which I can continue to update/write. The `future` folder contains the ones that are drafts, but I can see them and don't mind if someone stumbles on them. Always a work in progress and am even aiming to simplify it further.

I just want to say how funny it is that this is posted after the spirited discussion in the previous related thread about exactly what 'writing your own html' means.

https://news.ycombinator.com/item?id=42996322

As an option that still uses HTML, with relatively minimal and common dependencies: the unified header and navigation insertion, as well as other aspects of website generation and syntax checks, can be handled with XSLT. Or one may employ a generic macro processor like M4, which should be fairly easy to set to convert LaTeX into MathML, as well as to include shared headers.

> handwriting HTML is honestly not that hard.

> To write a new article, I... [c]opy-paste an older article to get the correct headers and navbar.

This is kind of hilarious. Any parts that you copy-paste from your previous projects into your new one are almost by definition too hard to do from scratch every time. You don't normally copy-paste e.g. single words or phrases like "do from scratch" into your writing because simply writing them is quicker and less fiddly than copy-pasting them from somewhere else, right? Yet I've worked with a dyslexic programmer once, and he copy-pasted tons of single words and phrases around from his earlier messages when chatting, and code snippets when coding — because for him, it was indeed easier than writing it correctly from scratch.

So back to main original point: handwriting HTML may not be that hard, but it's still hard enough for almost anyone to make them evade it whenever they can.

I have always written my own static blog generator, moving from PERL to Ruby and most recently Python. I find the other blog systems are too complicated for what I want. Plus, I think I like writing the generator more than writing actual posts.

A funky option for doing client-side includes and basic templating without JS is XSL.

Here's an small demo I threw together https://github.com/evidlo/xsl-website

A lot of people hate on XSL, but it has some interesting abilities!

I can definitely relate to building towards an easier "write -> publish" workflow. My old site is still running WordPress but I just got frustrated with the overall feeling of oppressive heaviness to the whole framework (no shade on WP, I still really like it).

I switched over to a similar process but opted for Pelican (since I'm more familiar with Python vs Rust) which builds directly off my markdown notes in Obsidian so it's relatively WYSIWYG. Much easier to maintain and Github Actions automatically handle updates.

https://mordenstar.com/blog/obsidian-to-pelican-exporter

I think the key to getting into the habit of writing blog posts is to make the actual process of writing and then publishing as easy and frictionless as possible. I use Bear app for the writing - it's a very well designed markdown editor with some really nice, simple features, such as nested tagging. I then got ChatGPT to help write some scripts to publish it via the Quarto static site generator. I wrote about the process here: https://thisisjam.es/creating/quarto-website-with-bear/

What I did was store my Obsidian vault in my website server folder. Then I instructed Cursor to make all /whatever.md markdown files in there show up as HTML when you visit "/whatever" , and to get all the obsidian features like [[links]] and ![pics] and all rendering right. It used php and some apache settings. Works great. Now I just edit in Obsidian, and it all appears on my .com live as I type. Very low friction. I did see Hugo, Jekyll, & Pelican do similar, but it was straightfoward enough to just do it from scratch with Cursor, customized how I liked it.

I run my personal site off of Hugo. You can load some decent themes and adding new content is a relatively painless process.

But I do feel like there is a cost to using static site generators. Raw HTML is easier to work with if you aren't dealing with a lot of similar pages.

You actually skipped making an adhoc site generator of your own.

Make a 5 line shell script to do steps 1 and 2 for your entire site. Then the content is just a few paragraph and link tags. Throw in a call to markdown if you want to get fancy.