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.
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.
Markdown makes it challenging to write form controls (input. select, textarea, buttons) and non-visual identifiers (id, class). To solve for most of these concerns I still find I prefer to do it dynamically against the DOM as needed by user interaction.
Besides you can directly embed any HTML inside markdown.
> 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.
It's nice to have to a set of programs I moderately care about, so when I'm learning another language I can port them to it.
They're unimportant enough that I can comfortably experiment, but important enough that I want to complete the rewrite.
My "blog engine" is a nushell script that uses pandoc and built-in XML support to convert markdown into a site+feed.
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 notice, for example, that this doesn't include a <!DOCTYPE html> at the top, but it still functions because browsers accommodate incorrectly formatted HTML.
> I notice, for example, that this doesn't include a <!DOCTYPE html> at the top, but it still functions because browsers accommodate incorrectly formatted HTML.
I was just being lazy. I've added it now.
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.
Including the prompt in your write up is a nice touch.
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.
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.
This is static site generation? I had another name, basically it was CMS for people that used ms word to type blog posts
Doing this again with a markdown step sounds cool
I think a real cms just has like tag engines and the ability to group posts and that sort of thing. But a site where everything is chronological; and otherwise only "wicked" - linked via potholes in posts is really all I need.
Maybe. I do need 2 blog sites here soon. I'll try templating for one and a ssg for the other maybe.
Yeah can probably get a whole static site from a python script that loads jinja. There are lots of ways.
I just think this stuff is so easy and there is so many good tools that it is worth tailor making a solution you like.
After all, a simple web component in a page of code would have allowed client side includes.
If you set the bar to "0% JS at all costs" then you can't very well complain about how hard it was to maintain HTML.
Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client, nor deteriorate the experience of the user.
After all, you provide a CSS file, right? The JS to do client-side includes using a custom element (so that `<client-side-include remote-src="...">` works) is unlikely to surpass a modest CSS file in terms of size.
Do you serve your content with "Content-Type: text/plain"? Client-side parsing of HTML and CSS, layouting, etc, is a looot of code.
I mean you could sum it all up and compare it to human-hours or something but that's not a useful metric because it's distributed.
Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future. Imagine users being able to display data (because fundamentally that is all a blog [or any site] is) in a way chosen by each user. That would probably be worth the extra cycles on device.
But handcrafting html is inconvenient to do frequently, so for more ordinary posts I write in markdown and use some custom scripts and pandoc to generate html. For me this approach is more fun than using a static site generator and less annoying (because I spend less time figuring out why an upgrade randomly broke something, or how to make the SSG do things I already know how to do manually). But the only reason it hasn't devolved into a full hand-rolled SSG is that I don't need/want much consistency across pages: there's no shared nav bar and I don't try to keep the styling or layout of older pages in line with newer pages.
Doesn’t the client have to do rendering work regardless or whether the HTML is served server-side or client-side?
That said, he's throwing the baby out with the bath water and making convoluted claims. I agree with some of them, but I'll exercise my desire to write more and reply:
> My hope is that I’ll take advantage of this and start writing more!
Choosing to self-publish one's blog is already at odds with "I'm doing this to write more". So blaming handwritten HTML for added friction is not so fair.
Literally writing every single page of HTML is unnecessarily strict. As another commenter mentions, why not add a few client-side templates for header/footer, a global nav etc.
Jekyll is really not a very ergonomic static site generator. I got GitHub famous for a hot-second because I wrote a little framework to help: https://github.com/jekyllbootstrap. TLDR: Jekyll is famous because the cofounder of GitHub made it. Not really because it's the best or even a good implementation. It's neat, it's just, why would you use that if you have access to a fully ruby runtime.
Anyway, I love hand-writing HTML so my bias out. I don't think it's HTML's fault. HTML is super easy to write, as OP agrees.
I made my own little website framework (of course); it's not ready for prime-time but you can peruse here: https://plusjade.com/demos/index.html
If you truly write directly in html, you are probably going to be writing about html or webdev, as your mind is in that headspace, and you have to tweak a lot of html stuff so that's what you get to talk about. Once you let go a bit of that primitive purism you realize you are free to think about whatever the fuck you want.
That said I have a lot of love for speaking about the medium. When I'm feeling cynical, it feels dumb to speak about anything other than the medium. It makes sense to me that half of the discourse on twitter is about elon musk, at least it's transparent in its topical bias, on typical media the topical bias gets rerouted and engineered through ads so that you can "focus on the actual content" which is kind of dumb, I guess, I find the ads end that keep the lights on end up being more important than yet another mindless sitcom.
So yeah, I'm torn. But whichever path is chosen, going through this drama of self hosting, tech minimalism and reinventing the wheel, is a key signature of the tech blog, it really shows the identity of the author and the work they've put into the mix of their ideas and their web space, in a way that, say, a wordpress instance, cannot fulfill.
Even something like a squarespace site is worth the proprietary commercial money if you enjoy blogging.
proceeding with all the steps that make it hard...
> exercise in pointless manual labor
This is exactly correct! Let the tools do their job and insert all the spans/tags/etc. that a browser expects, devote your energy to the content!
