This is novice stuff. I write my blog by modifying the filesystem's binary structure by hand with a hex editor. There is no Javascript or CSS whatsoever and the document uses only elements, attributes, and behaviours that were both described in the original HTML v1.1 DTD and that have continued to appear in every intervening IETF, W3C, and WHATWG issuance since then. Many of the elements are therefore deprecated and currently unimplemented in all evergreen browsers. Nevertheless I live in firm expectation of their eventual reinstatement. The HTTP service is one I nicked from a grad student in my CS department circa 1995, it speaks only HTTP/0.9, and is written in a mixture of ksh and dd, requiring no other utilities. This runs on a SPARCstation 20 from the same era that has been repaired from scavenged parts so many times that the hostname spontaneously updated to "theseus" a few years ago. Fun fact: impurities in the copper I smelted to replace the power supply windings led (as you can no doubt imagine) to induction spikes on the drive rails, and the subsequent fsck erased all blog entries mentioning Jonathan Schwartz. So nothing of value was lost. Readers may be pleased to learn that despite all this I'm not totally retro; since SunOS 4.x is now out of support, the Kodiak is proudly booting NetBSD.
The blog itself is, of course, optimised for viewing in Lynx. In fact it only works in Lynx
What can I say, I modernised. It feels like an age since I last toggled in a bootloader through a front panel. I'm also anticipating a bit of snark (pun intended) from the folks still twiddling data on their magnetic drums using an iron needle. It's all in good humour though, we continue to get along because I didn't switch to SVR4.
I know you’re being facetious, but there was a time that I did toggle a boot loader in with switches on the front of a mini computer. Now I feel super old.
You’re not alone. I too am ancient enough to have done the same. PDP-8 at my hometown university computing centre. At least half my original comment held a grain of truth, as a matter of fact. Including the dd/sh HTTP server (hi Claudio!)
Real professional software developers only use the subset of HTML which ISO standardised in 2000 as ISO/IEC 15445:2000 with additional validating constraints. Published via SOAP ands WS-*.
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.
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.
I don't know what I'm more offended by, the implication that writing 'raw' HTML is some noteworthy retro skill, or the fact the blog isn't actually written in raw HTML at all, but in Markdown.
I had the same thought. 72kb of JS dependencies from some CDN to render that "raw HTML". If you are going to claim to be a purist, try actually being one first.
I blog with raw HTML too, but I don't blog about it. The "blog about the tools I use" tarpit is somewhat unique, it's like if online chefs were obsessed with creating knife and fork recipes.
I think that’s misunderstanding the point they’re making. It’s not talking about knives, it’s talking about knife recipes. As in, “I use the pairing knife to cut the salmon” which is definitely similar to “I use HTML to write my blog”.
Maybe if it was a unique, special pairing knife, sure. That could be a real conversation. But it’s just a normal pairing knife. You’re just announcing you make the thing, with the other thing that makes the first thing.
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.
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.
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...
Javascript loaded from Cloudflare! What's the chances Cloudflare (current age: 14.5 years) is still around in 20 years and still providing this Javascript (current age: 30 years) file (current age: beginning of Israel's current bombing of Gaza)?
And another one loaded from the website of the creator of that module! Last commit 2 years ago. Created 1 year before that. Will it continue to exist?
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.
I literally blog with raw SGML. Each post comes with a handful per post ENTITYs for that post's common abbreviations and links. Unlike inopinatus's comment, I do keep up with "modern" standards, which is why my posts conform to the "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN" doctype, the latest HTML standard approved by the ISO.
Blog content is assembled via various SGML entities includes into a prehtml file of "-//ISO-HTML User's Guide//DTD ISO-HTML Preparation//EN" doctype per ISO 15445:2000 recommendations[0]. This is all processed with osgmlnorm through a somewhat simple Makefile to generate the resulting HTML files.
"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.)
As other comments mentioned, the content is written in Markdown and rendered in the browser. So “blog with raw HTML” feels like a stretch... that said, View Source in the browser shows the exact HTML document that's presumably hand-written in the source repo [1], so I guess it comes down to the definition of “raw”. It could mean “not pre-processed”.
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.
"raw html" that does not work without JS (I mean literally, links are not links without JS), but on the other hand looks ugly even if 10 lines of CSS would make it look nice
If you turn Javascript off, the Markdown-formatted text will not display as a clickable link, but like "[hugo](https://gohugo.io/)". You would need to copy and paste the link into a browser address bar to navigate there instead of just clicking the link.
As others mention its not raw HTML, but also the browser is applying styles of it's own - you can't get away from that. Isn't that reason we have CSSS resets so we have a baseline starting point that other browsers have forced upon us.
How long ago were the default CSS rules set for a browser. They should probably change.
I used to blog with raw html. In 1999 when I was 12. It sucked. There is a reason why we use things like markdown now. Still, you kids should definitely dig into the fundamentals at least one time and write raw html. Just don't stay there and pretend it's somehow better for you.
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.
Why are there so many of these exact kind of posts lately? I swear I’ve seen 10 posts in the last month with some variation on “I use less technology to do X than the next guy”. It might be noteworthy if the author had an interesting problem to tackle, previously used a convoluted stack to accomplish it but then stripped it down to basics - but no, this is just “I wrote HTML to make a website”. I’d rather read “I used a hammer to hit a nail”.
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.
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.
Irrelevant to the topic, just wanted to say hi. I have the honor to know poga during teenage with shared interest, and you have always been an inspiration to me. Seeing your post on the front page of HN is a welcoming surprise.
Regarding the topic, I resonate with the concern about personal blog having to follow the convention of certain technology. Wouldn't say I enjoy reading it (or any site) without some minimal styling though.
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’m curious, does [my blog](https://ziofil.github.io/) count as “raw html”? I do have some minor js and css, but I don’t rely on a static site generator and I do everything by hand…
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.
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.
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.
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.
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.)
To those taking issue with the "raw" HTML claim when the author actually writes markdown syntax and converts it to HTML: SGML, on which HTML is based and which is originally understood to supply the authoring features HTML itself is lacking, has the SHORTREF capability [1] which can map custom tokens into markup and thus implement a large portion of markdown in pure SGML, if still not "raw" HTML.
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.
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.
The blog itself is, of course, optimised for viewing in Lynx. In fact it only works in Lynx