Not to knock your system since it sounds like it works great, but why not use a static site generator?

That seems like it'd do the same thing and just take out some of the drudgery.

Why add another layer? Right now the only tool he needs is an editor. That's it. Can't get any simpler than that. He also probably has a set of templates by now.

> Why add another layer?

The answer given:

> to take out some of the drudgery

At the end of the day the drudgery they are doing is writing the post, something they'd have to do anyway on a static site generator. Writing the raw html likely takes no friction at all, since they are probably copying and pasting some template or at this point know all the tags they use by heart so its no harder than a more abstract method.

> It's not pretty, but it's zero maintenance. I've been doing that for 10 years now, and I don't think I'd ever go back to a third-party dependency.

SSG is third-party dependency in one way.

It seems to me that a text editor is the same sort of dependency as a static site generator. Especially if you store the resulting site as rendered.

You can drop in whatever text editor you like though. It's only a dependency like saying a keyboard is a dependency to writing code. There will always be new editors or you can use a 40 year old one just fine too. Can't say the same about the static site generator though, maybe your setup works when you swap one generator for another maybe it doesn't.

I don’t think a text editor can be called a dependency when every computer in the last 30 years has shipped with one.

At the end of the day you have to pull in a SSG from elsewhere and run it.

Comparing the complexity of operating and maintaining a SSG to using a simple text editor is just about the most HN comment I've ever read. My blog is written with Gatsby (which I use as a SSG), and about once per year I have to dedicate and entire weekend to troubleshoot because I can no longer run the SSG due to changes in the Node/npm ecosystem. There is absolutely no corollary to using a text editor. Literally nobody will have to spend a weekend figuring out "what do I have to do to get notepad to open a .html file with today's technology". Nobody! Notepad just opens the .html file, just like it opened the same file a year ago, or 10 years ago. No need to burn weekends over opening a file!

He is a static site generator.

I was pleasantly surprised to learn writing raw html is not difficult, at all. I am not doing Rocket Science, though. As others say, static site generators introduce a layer of abstraction. I like writing in markdown too, but if I really cared to, I could write my own scripts to translate. However, I found that html does not introduce undue overhead. I am sure I could churn out content more quickly if I were writing in markdown, but at what cost? There is a cost to writing _too_ quickly. Myself, I find I actually like a little friction.

With Obsidian and an add-on you can output html pretty quickly (even with some CSS I believe)

So from writing to publishing is a short flow.

I always wondered why browsers do not parse and understand markdown on their own, it would be so easy for thrm to implement it.

Until CommonMark there were a large number of ambiguities for which there was little alignment. Base Markdown is such an anemic format that it requires extensions to be useful to more forms of writing.

Along these lines...I'm surprised the HN crowd isn't into blogging in markdown, published in a git repo. About as simple as it gets and you don't get tied to a single platform. You could key sign it to ensure authenticity for when somebody rehosts it or whatever.

I had a similar feeling about markdown but I went a different direction and wrote a little package that parses markdown with front matter into html and saves it inside an in memory SQLite database. It runs quickly enough that it can hot reload anytime you save while it watches your blog posts directory. Gives you full text search and it exposes the database directly from the package so you can basically hook it up to anything.

I’m still ironing out the kinks, but it made blogging way more pleasant for me, after trying a few other things and being unimpressed overall.

That sounds really cool, thanks for sharing. It may well be that I'll eventually reach, or gradually approach, a footprint with my site files that rewards putting in place some layer of tooling along these lines.

But I like to think that, when that time comes, I will be the author of that tooling. As it sounds you are. Kudos!

Same here, I really can’t be bothered with SSGs or something like WP. I don’t even really bother with how my website looks, it’s as plain of HTML as you could get.

It suits me well.

Wait... You don't use an IDE taking up 2GB of RAM to write posts in "plain text" using a random flavor of Markdown, with custom extensions only supported by a single blog generator, and then use the command line to call 250MB worth of Node libraries which creates an AST from the barely parsable text file, all to then generate a basic static HTML file?

What's wrong with you?

An IDE using 2 GB of RAM? 2010 called, they want their IDE back.

In all seriousness I love me some JetBrains's, but boy do they eat RAM like there's no tomorrow.

Still a paying and satisfied customer.

At least no one complains about Emacs anymore :)

Could you explain how do you do it? I really want to have a blog but I don't want to fuck with wordpress and all that I know is a little bit of html, python and sql.

  <head>
    <title>Title</title>
  </head>
  <body>
  <p><b>2023.02.20</b></p>
  <p>This is the first paragraph.</p>
  <p>This is the second.</p>
  </body>

Save that as "blogpost.htm" somewhere a web server can see it.

Add stylesheets and so on as you get more comfortable, but it really is that simple. All that matters in the long run is what you put between the <p> tags.

Wow, I didn't expect so much interest in my comment!

I should start by saying that I'm not averse to a little "manual labor". I know a lot of people feel compelled to automate everything, and if you're like that, then you wouldn't like my methods at all. ;-)

My entire blog is in a git repository.

I use BBEdit for text editing. https://www.barebones.com/products/bbedit/ It has a full set of HTML tools and templates.

Whenever I want to write a new blog post, I create one from an HTML template that already has a style sheet, header, footer, and other structured info.

All of my blog posts are listed reverse chronologically in a table in the "index.html" file. I just have to create a new table row for the new blog post at the top and fill in the date, filename, and title.

I can preview the blog post in a web browser while I'm writing it, and BBEdit accepts drag and drop of images files, automatically creating img elements.

I also have a template for the RSS feed entries. I use the Atom format FWIW. Each entry has a section where I can copy and paste the HTML from the blog post into the RSS feed:

<content type="html"><![CDATA[ ]]></content> </entry>

I use the W3C feed validation service to check the RSS syntax, and I also subscribe to the local copy of the RSS feed file in my RSS reader app. https://validator.w3.org/feed/

That's about it! My system has become slightly more sophisticated over the years. When I started blogging this way, it was even more primitive. The whole point was to just start blogging, and not worry about my blogging system. It seems that worrying about the blogging system stops a lot of people from blogging in the first place.

> It seems that worrying about the blogging system stops a lot of people from blogging in the first place.

I couldn’t agree more, and I’ve been a victim of it myself. This is why I like zero-config setups now. Choosing themes is the most attractive nuisance ever…

Mind sharing a link to your blog?

I'm also a "tooling minimalist", but I'm curious how you handle things like grouping posts (or do you just not bother?).

Assuming everything's not on a single page, how do you avoid tedious duplication?

I'm assuming it's https://lapcatsoftware.com/articles/

As noted in my other comment, I looked for it out of curiosity too, and it's incredibly satisfying to see how fast it loads.

The name of the blog is a little joke/pun about how bare-bones the site is. I'm not a designer, obviously!

Fellow raw HTML writer chiming in. My hand-built little web app for blogging broke maybe five years ago with some OS X update, and I have been too lazy to fix it.

Man, your website is the shit and one of the better examples of an antidote to the Website Obesity Crisis. Words over hero images.

Also a raw HTML writer, but I’ve been considering the SSG route to make site updates (global nav changes, redesigns, etc.) manageable. You seem to have some method of handling this on your site, given that I can view a page of posts from 10 years ago and still see links to this year’s posts. How are you doing that with raw HTML? (If this question doesn’t make it clear, I am quite amateur.)

I had a PHP script that did this for a while — I would write the post itself by hand, then put it into a database; the PHP script would regenerate the site locally and take care of things like nav links; then I would rsync the static output to the web server. Once I figure out how to get it all running on the latest OS X again I'll use it again; I'm a big fan of this kind of setup. I'm sorry that I don't have specific tools to recommend for it.

I used to write raw HTML, but have since come up with my own markup system [1]. The posts themselves are still stored in HTML because I don't want to get stuck with a sub-optimal markup language. By storing the rendered HTML, I can change how the markup language works (and I have).

The blog engine itself [2] is one I wrote starting back in 1999, and still in use. It works, does exactly what I want, so there's no reason to change it. And to see it in action: <https://boston.conman.org/>.

[1] You can see an example here: <https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg>. The markup engine is written in Lua: <https://github.com/spc476/mod_blog/blob/master/Lua/format.lu...>.

[2] <https://github.com/spc476/mod_blog/>

Oh my goodness, I just looked through your submission history to find your website, clicked through to a random page, and I was blown away by how fast the page loaded. I love it.

the other thing you get is information density, I can see posts back till midway last year.... on my large monitor on many sites, you can be luck to see the last 3. Scrolling, I can quickly see 10 years of posts. Fantastic

I’m becoming a bit disenchanted with new things in general. This website is a perfect example of how needlessly complicated most other websites have become.

Imagine how pleasant browsing the internet would be if most sites were like this?

I’m starting to think tech in general is 1% signal and 99% noise…

I did something similar but used wiki syntax with a handful of extensions. The source content was stored in a specific directory layout/scheme and the site code generated the page hierarchy from that, storing it in an adjacent cache dir. Coming from a sysadmin background, it seemed very natural and easy to manage. Definitely the way to go.

One day I'll clean it up and offload it to github for others who are like-minded.

This sounds almost exactly like something I whipped up in the early 2000s [1]. Each post was its own directory (so I could just drop images in), and it used file system metadata for dates. It was based on Bash, ImageMagick, sed, m4, head, tr, and... XSLT (I swear it seemed like a good idea at the time!).

Believe it or not, the tool actually even worked with Cygwin after I switched to Windows (on my very first laptop).

[1] https://log.schemescape.com/posts/static-site-generators/pre...