The moment you add an RSS script you cease to use raw HTML and start to use your own bespoke site generator.
On the plus side, a personal project only changes when you intend for it to, so you don't need to worry about breakage. (Unless your scripting language breaks.)
If you're using markdown and js, in what sense are you blogging in raw HTML? Not to doubt but it feels like a qualified version of the underlying state of affairs.
I blog (for work) on WordPress and hate it. I could imagine using org mode or markdown, pandoc to emit HTML with some tuning and a simple script to publish via sftp.
It's a GitHub Action that regularly scrapes your page and checks for new entries, turning it into an RSS feed. Set up a redirect yourblog.com/feed -> you.github.io/feeds/feed.xml, then you're golden.
If I turn off Javascript, your blog breaks in ways that shouldn't be possible if it really was HTML (specifically, links and images disappear[0]). You're not blogging in raw HTML, but markdown. Your homepage is the most 'raw HTML' page I can find on your blog, because it uses real HTML elements to display things, and doesn't even use JS or CSS.
Presumably meaning he directly edits the .html files instead of using any kind of SSG/build step. The Markdown is transformed with JS on the client-side.
re: static, there are two main points of view. Static from the visitor's perspective or static from the webmaster's perspective. This seems to be about static from the webmaster's perspective which is a "modern" view and one that seems to have overloaded the term since 2015 or so.
What? No... static web pages can have JavaScript, but everybody gets the same page over the wire. Dynamic web pages have some sort of program generating the resulting page for you, like PHP or Ruby; they can return different HTML for the same URL. That's dynamic. It has nothing to do with if you're the client or the server.
For any communication I think we need to take as a premise that static HTML and static web sites are not the same category of thing. Any particular page on the web can be totally static or totally dynamic or a mix. There are static HTML pages on static web sites. There are dynamic HTML pages on static web sites. There are static HTML pages on dynamic web sites. And there are dynamic HTML pages on dynamic web sites.
The meaning of static HTML is the least contentious. A static HTML page is just an .html (or .htm, or anything else if the mimetype is set right) hypertext markup langage document that is stored on a file system as a file and sent to the end user when they request the URL that maps to that file. The HTML encodes what the web site user will see and does not change.
When the static .html file includes "static" (not really since it is executed code) javascript (or other executing language embeds) that changes the page to something other than displayed by the html in the file on disk. So it becomes a dynamic HTML page (for ~5 years called "DHTML").
The only place where static HTML becomes unclear is in the case where some webserver linked program generates the static HTML on demand with no storage of the HTML as a file on the filesystem before being sent to the site user. In this case even though the user sees only static HTML there's crucially no file ever created on the webserver so it's dynamic HTML.
The meaning of static website is increasingly more unclear compounding on the fuzziness of what a static HTML page is. Generally there are the same two points of view as above but with a tweak.
There's the website users point of view where a static web site is static if the pages are just HTML and do not require executing any code to view. If you (or your browser) look at the source you can read the text and see the image URLs. It does not have to be generated by the browser's execution of some client side code.
Then there's the developer point of view where a static web site if the code required to generate the website is stored in a static file on the webserver. In this framing you can deploy a self contained .html file which includes the javascript code for a client side dynamic web application. This web application can completely change the text shown and even draw in outside information not in the file. But since it can be put on a CDN as a static asset it is a static web site.
You advocate the developer-view of what static website means. But this perception is a modern overloading of the phrase. For literal decades static meant what the user-view of static website. Neither is wrong but unless you state it explicitly there will be misinterpretation like above.
A tiny bit of webdev-side dynamicism can really help with managing visitor-side static websites built on .html files in directories.
If you run your own webserver and write HTML then check out server side includes. Being able to include .html fragments in other .html files means no need to edit the same bit in dozens of .html files (ie, left_menu.html, footer.html, etc). And since SSI hasn't really changed in 20 years the major implementations (nginx, apache, etc) have basically nill attack surface or mantainence burden. And there's no "rebuilding" or anything that's not HTML markup to maintain.
HTML+webserver SSI is just more HTML but without the redundant editing.
Absolutely agree. Just for fun, I recently implemented SSI using Cloudflare Workers [1] — but with a twist to feel like it's from 2025. It's a bit of a shitcode experiment, but I really wanted to recapture that early hacking spirit.
I recommend you https://nucelo.com. Open source minimal blog platform. Everything you want is included, rss or newsletter. I pay $4 per month. I used raw html for a while, then I switched to this platform.
Am curious. How is this raw HTML if you're using markdown?
But on the other side, writing in raw HTML is a fascinating topic I've been very intrigued by. http://john.ankarstrom.se/html/ is a very inspiring post.
I write my blog in markdown and serve it to the browser as such, with a one-liner javascript include to render it in browsers that support that. I like that the "canonical" post source is preserved and served (you can read it with telnet, in a pinch).
had a look and I like it. More "raw markdown" (what the OP uses too) instead of HTML in web publishing is a good thing - basically because xml syntax is not how humans want to write.
This, combined with git forges pages concept or tilde user accounts makes for nice corners in the webs.
Markdown is the least bad way for humans to write, IME. It definitely beats handwriting, it definitely beats every other markup/formatting language, and subjectively I find it nicer than MS Word style "WYSIWYG" formatting although that part is maybe more arguable.
See also this review/critique from the cURL author, especially if you’re going to implement it yourself. Particularly around certificate handling and URL parsing, there’s a lot of underacknowleded complexity in Gemini.
That's a really well written post. Thank you for sharing it, really makes you think about all the thought that has went into http and how important Chesterton's fence is
Yeah but also all of the legacy baggage that it comes with, y’know?
Like the URL parsing stuff for example. The issue is that they pull in one of these enormous old RFC’s and also say “but UTF-8” without any more explanation.
A better URL might be a good thing — scope it down to what’s in common use, design it tightly for your needs, etc. But if you’re gonna do that, do it! Rather than just pulling in an RFC with decades of baggage and then modifying it ad-hoc.
I used wintersmith.io. At some point it was abandoned and eventually the node version needed was old and other stuff associated with it. It became a hassle.
I promise you, HTML is not a hassle... It's markup. You describe the page, and then... you're done. And if you don't use weird, niche tags, it'll work basically forever.
This is a patently false promise. Yes, it's markup, but a bad one un-ergonomic-suitable for direct human consumption. Even the author of the blog understands it and uses alternatives
> with md-block for markdown
> You describe the page, and then... you're done
Unless you want to re-describe something, of course. Maybe sort a column in a table...
If you make such risks up, then no one says that html will be readable in the same way in 20 years (which is already kind of true as you have a lot of old blogs with awful layout on mobile)
But there is an even easier one - nothing will happen to your html built files of 20 years, they'll remain... static.
The worst is you'll go to updating your lovely html by hand, but you would've saved yourself wasting 20 years doing that instead of using a better system.
That's one thing I did realize over the last year.
It is not a huge work but still some work, especially, as you wait for themes to upgrade themselves with the newer version of Hugo.
I really like Hugo but I couldn’t ever find the right look and theme that I liked and spent way too much time on it. I decided to just create markdown posts on GitHub on that special user repository where the readme contents end up on your profile.
For me, it blinked some markdown on the page briefly before formatting appeared. So, no, it's not raw HTML.
For what it's worth, I don't think there's anything wrong with that. My blog is written in markdown. HTML is a deeply unpleasant thing to write blogs with.
Blogging in raw html means you fire up emacs, tramp to the blogs index.html find the last closing p tag and underneath put the post headline and timestamp and an opening p tag on the next line and you are off to the races.
Of course opening the index in tramp, putting the heading, timestamp and p tag goes into a function or paused kbd-macro so it fits into Mx blogthis
Lol. Once you start learning about Elisp and the Emacs platform, it's so trivial to write up scripts like this. Mostly due to the fact, that every command is also a function, and the whole state of the software is accessible. I have a bunch of ebooks (pdf) in a folder, and on macOS, I created a quick workflow that fuzzy search them (file name) and open the selected one using Alfred.app. I created the same feature for the shell using fzf, and the emacs version (using consult-find) was equally short.
My favourite project of mine is a little web server to support raw html blogs! It can handle serving via ssl, and adds features like an rss feed, a sitemap and a few go templates to make directory listings easy to maintain. The README is pretty authoritative for documentation.
I like it, but raw HTML doesn't mean it has to look like it's from the 90s. He could centre the text with CSS, add some whitespace, specify system fonts, rather than just Times Roman etc.
"html" is mostly defined in the real world as "something most browsers will render".
<html><head><title>My HTML Page</title></head><body>Hello world!</body></html>
Is technically "invalid", but it's "html" in the sense that everything from w3m and Netscape Navigator through to Chrome bleed will render it as intended.
(About to click the [reply] button hoping the HN software doesn't screw all that markup up.)
136 comments
[ 3.3 ms ] story [ 186 ms ] threadI can write a script to generate that from the list of article but I'm not sure if there's better way.
On the plus side, a personal project only changes when you intend for it to, so you don't need to worry about breakage. (Unless your scripting language breaks.)
I blog (for work) on WordPress and hate it. I could imagine using org mode or markdown, pandoc to emit HTML with some tuning and a simple script to publish via sftp.
It's a GitHub Action that regularly scrapes your page and checks for new entries, turning it into an RSS feed. Set up a redirect yourblog.com/feed -> you.github.io/feeds/feed.xml, then you're golden.
View source on this page: https://justine.lol/rss.xml
I got the template from a friend.
Very easy.
[0] it's particularly bad on https://devpoga.org/cheap-complexity/
The meaning of static HTML is the least contentious. A static HTML page is just an .html (or .htm, or anything else if the mimetype is set right) hypertext markup langage document that is stored on a file system as a file and sent to the end user when they request the URL that maps to that file. The HTML encodes what the web site user will see and does not change.
When the static .html file includes "static" (not really since it is executed code) javascript (or other executing language embeds) that changes the page to something other than displayed by the html in the file on disk. So it becomes a dynamic HTML page (for ~5 years called "DHTML").
The only place where static HTML becomes unclear is in the case where some webserver linked program generates the static HTML on demand with no storage of the HTML as a file on the filesystem before being sent to the site user. In this case even though the user sees only static HTML there's crucially no file ever created on the webserver so it's dynamic HTML.
The meaning of static website is increasingly more unclear compounding on the fuzziness of what a static HTML page is. Generally there are the same two points of view as above but with a tweak.
There's the website users point of view where a static web site is static if the pages are just HTML and do not require executing any code to view. If you (or your browser) look at the source you can read the text and see the image URLs. It does not have to be generated by the browser's execution of some client side code.
Then there's the developer point of view where a static web site if the code required to generate the website is stored in a static file on the webserver. In this framing you can deploy a self contained .html file which includes the javascript code for a client side dynamic web application. This web application can completely change the text shown and even draw in outside information not in the file. But since it can be put on a CDN as a static asset it is a static web site.
You advocate the developer-view of what static website means. But this perception is a modern overloading of the phrase. For literal decades static meant what the user-view of static website. Neither is wrong but unless you state it explicitly there will be misinterpretation like above.
If you run your own webserver and write HTML then check out server side includes. Being able to include .html fragments in other .html files means no need to edit the same bit in dozens of .html files (ie, left_menu.html, footer.html, etc). And since SSI hasn't really changed in 20 years the major implementations (nginx, apache, etc) have basically nill attack surface or mantainence burden. And there's no "rebuilding" or anything that's not HTML markup to maintain.
HTML+webserver SSI is just more HTML but without the redundant editing.
http://www.kibo.com
[1] https://github.com/artps/ssi
But on the other side, writing in raw HTML is a fascinating topic I've been very intrigued by. http://john.ankarstrom.se/html/ is a very inspiring post.
This, combined with git forges pages concept or tilde user accounts makes for nice corners in the webs.
An overview of the protocol, proxied from Gemini to HTTP, available here: https://geminiprotocol.net/
https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-s...
Like the URL parsing stuff for example. The issue is that they pull in one of these enormous old RFC’s and also say “but UTF-8” without any more explanation.
A better URL might be a good thing — scope it down to what’s in common use, design it tightly for your needs, etc. But if you’re gonna do that, do it! Rather than just pulling in an RFC with decades of baggage and then modifying it ad-hoc.
No? You don't need to upgrade to the version that deprecates. Besides, what features are you using with such a simple blog the are at risk?
Ahhh...
> with md-block for markdown
> You describe the page, and then... you're done
Unless you want to re-describe something, of course. Maybe sort a column in a table...
No one says that single binaries compiled in the last 10 years might be usable without a VM in another 10 or 20 years.
And no, 20 years for the same blog to exist isn't even so rare.
But there is an even easier one - nothing will happen to your html built files of 20 years, they'll remain... static.
The worst is you'll go to updating your lovely html by hand, but you would've saved yourself wasting 20 years doing that instead of using a better system.
Upgrading hugo is not straightforward due to the backward incompatibility changes. Too much changes to care for a static generator.
That doesn't sound like raw HTML to me. I write my own blog in raw HTML with a text editor (BBEdit), no JavaScript, and no server-side script either.
For good measure, I also write my RSS feed in raw XML with a text editor.
For what it's worth, I don't think there's anything wrong with that. My blog is written in markdown. HTML is a deeply unpleasant thing to write blogs with.
Of course opening the index in tramp, putting the heading, timestamp and p tag goes into a function or paused kbd-macro so it fits into Mx blogthis
You do it just like that. But with vi.
https://github.com/PlayTechnique/andrew
An example of what I mean: http://bettermotherfuckingwebsite.com/
A more flashy example: https://thebestmotherfucking.website/
https://ontology2.com/the-book/html5-the-official-document-l...
though I also published some Jupyter notebooks
https://ontology2.com/essays/PropertiesColorsAndThumbnails.h...
<html><head><title>My HTML Page</title></head><body>Hello world!</body></html>
Is technically "invalid", but it's "html" in the sense that everything from w3m and Netscape Navigator through to Chrome bleed will render it as intended.
(About to click the [reply] button hoping the HN software doesn't screw all that markup up.)