No longer writing my own damn HTML | Hacker News Reader

No longer writing my own damn HTML

claytonwramsey.com

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.

The ideal amount of JavaScript is zero.

I disagree. The gov.uk website completely eschews JavaScript at some usability cost, in particular form validation is delayed until way later than it would be if they added just a little JavaScript. It can be quite annoying.

> The gov.uk website completely eschews JavaScript at some usability cost

I would imagine this was mostly driven by accessibility requirements more so than some ideological rigidity.

a little bit of the right kind of JavaScript helps accessibility, so it's clearly not

Unfortunately, some people view accessibility as an ideology.

It’s easy to dismiss the genuine needs of someone else if one’s not impacted though.

Ideology or not, exclusion does not help.

Perhaps, but, taking the example provided, Gov.uk deals with population scale products funded by taxpayers and which may be exclusively digital. Accessibility as an ideology makes sense in this context, and, I would argue, is morally correct.

Why?

I agree and with small single page sites doable but when I need to put a navigation (plus language versions etc) of the site into a mobile layout I have to do the js toggle, or do I?

Why would you need JS for any of that?

how else can I have a fullscreen overlay navigation on a phone from an accessible toggle button?

almost forgot to answer the question: because I don't know any better

Actual answer: like this! https://codepen.io/Sfate/pen/kGbLzK

yep that works thank you - so to get the fullscreen overlay (since we only want it on the phones) a media query - maybe it should be the one gridcell navpage. But maybe the links should be listed for the robots ... if mobile is default/first there would be only one link - yeah maybe this is good.

You can do a lot with CSS these days: https://css-tricks.com/the-checkbox-hack/

One (unusual) approach I like because of the simplicity is to put all your navigation links in your footer, and the hamburger/menu button in the header is just an anchor link that scrolls down to your footer.

Unfortunately, accessible HTML solutions for well established UI patterns like menus and tooltips are still far too difficult to get right (anything that requires JavaScript usually).

Nice, and I agree - maybe… the desktop version gets a nav and on the phone it’s all one elder scroll. With section links if it gets too long. … but still need the entry point for lang versions

I agree, but HTML widgets are not sophisticated enough not to require some amount of scripting for interactivity in many cases.

It is for documents but we have web apps that are not documents.

As a fellow no-JSer (when it comes to personal sites) for me it’s mostly about pushing myself to figure out creative solution using only what’s available within CSS and HTMl, which is a lot these days. It’s a fun exercise.

Sounds like the fun exercise went 'a bit' too far in this case

I think it’s up to them to decide. If they’re having fun doing it I don’t think there’s anything wrong.

But all the tasks in the article are totally straight-forward SSG stuff. Why would you do some processing in a build step, but then stop half-way and ship a bunch of JS to the client so they can finish it? That only makes sense if the work is dynamic in some way that it can only be done on the client-side.

Because you go where the good tooling is and MathJax is drop-dead simple to integrate on the client.

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.

same here.

Besides you can directly embed any HTML inside markdown.

I want to agree with this because I completely love markdown and it solves for so much of accessibility.

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.

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

Yeah, people (primarily developers) have always claimed HTML is so hard to get wrong and yet failure is well above 90% after consideration for accessibility, SEO, security, and more.

It was likely meant as a counterpoint to it. However, I don’t really know what either story brings to the table in terms of learning value, either option has been with us since the age of CGI scripts…

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.

XSLT is indeed great for this but very underestimated

My “static site generator” is m4 and make.

People over complicate things.

> 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.

+1.

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.

This is the best solution I think - you get to have things work just as you want like if you were manually writing the HTML but don't have to manually do the repetitive parts like keeping layouts and navigation synced.

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!

This is really neat, I didn't know the browser would serve a page that had been generated by XSL. Is this just a hack, or is it an intended feature?

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.

It's a feature! People used to build websites on this technology.

> 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 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/

Different process, but this is my experience too. Making it super easy to go from writing to publish helps keep momentum.

Including the prompt in your write up is a nice touch.

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.

Publish the PHP!

Sure. I'm not necessarily advocating others use it, but I'll post it for the curious. https://github.com/gth001/MarkdownToHTML/

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.

Build times can be annoying. I have a bicycle shop's website in Hugo, full generation takes about a few dozen seconds, upload using rsync easily a minute because of many nested directories with images. I ended up writing a script to only upload changed html and new images unless needed.

You know there was a time when we had to wait dozens of seconds for the modem to finish its handshake before you could do anything.

80s or 70s geezer, huh?

60s grandgeezer here. try waiting a week or two, to find out that your punched card batch job didn't even compile, let alone run, because of a single character typo you made. back to square zero.

kids these days ...

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.

Back in the day I'd use a WYSIWYG editor to design a front page and navbar and whatever, then split each part into header, nav, footer files and have code spit out the template HTML in the correct order with "body" file chosen by the URI

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.

That’s the idea. But static site generation just means doing that templating before, so your site is a zip of html and assets.

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.

oh, right. so every time you want to post something you have to run the generator? i think that's why i ended up rolling my own templating thing, asking the sorts of people i set it up for to invoke some other software was a bridge too far. i don't remember how i automated moving the text from their machine to the server but it was "once it's saved it's in there" sort of thing. this was early 2000s, i stopped setting up personal sites for people around 2006.

The big problem was not wanting to write even a small amount of is.

After all, a simple web component in a page of code would have allowed client side includes.

I did think about that! However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. Forcing users to run code just to render some boring text seems like a waste.

Hmm - what is the actual cost incurred by the users here? Mostly battery right? Is that not virtually inconsequential to each individual?

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.

Please, no. Don't use a SPA to render a blog, that's awful.

Browers already give users near complete ability to customize how web pages are displayed and SPAs usually make this worse not better.

The actual cost is forcing users to run javascript, with all its privacy leaks and security issues, to view what should be a static HTML document.

Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly.

In this case, users with JS disabled would miss out on loading, what, a navbar and footers?

And fuck off with "too lazy to develop properly." I am so tired of HN users constantly talking shit about JS. There are times to fight for efficiency but this is just part of a tired crusade.

> Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly.

This is a very uncharitable take.

It's because I know how to develop properly that I want to send the repeated content of the site to you just once; the header, topnav, lhs-nav and footer will be cached if JS is enabled. The cost of that JS is less than the common elements anyway!

It's funny. Further up in this discussion is someone sharing their demo of using XSLT to dynamically assemble a page from parts. This process properly caches the fragments as well. No JS required, just the default rendering process for the browser. But XML+XSLT is the "red-headed stepchild" that everyone seems to hate.

Writing a SPA just to recreate the built-in functionality of rendering a static page on the client side is overkill IMHO. If it's an actual application (the A in SPA), then fine. But for what is essentially a static website... why?

Your take is getting more and more uncharitable.

In what world is 60 lines of JS an SPA?

Come on, enquiring minds want to know. Show us all this SPA you know off that is 60 lines or less.

So, I think perhaps you are confusing me with the person further up in the thread. They said "don't use a SPA". You replied with a counter argument about JS. Then *I* pointed out someone else in the thread demonstrating using XML+XSLT to to client-side rendering and I called out people using SPAs to dynamically render what is essentially a static website. So "Your take is getting more and more uncharitable" seem to assume that the GP and myself are the same, and we are not.

Your last line seems overly aggressive and confrontational. I have zero desire to engage with that.

All that being said, have a wonderful day.

> XML+XSLT is the "red-headed stepchild" that everyone seems to hate

One look at XSLT syntax and you learn why.

I mean, I've used XSLT plenty in my career and I honesty don't have any issues with it at a high level. It's essentially just another templating format with the added benefit of being a markup language itself and being rendered directly by browsers without adding any JS.

You need to quantify before you say it's an issue. Eg. if the battery cost is 0.001% vs 0.0011% it's not actually an issue, despite technically being more expensive.

>what is the actual cost incurred by the users here?

Time.

Every bit of JavaScript is more time to download, execute, and then render the page. Time is a valuable resource, users appreciate not being told to waste it.

>I think it's better to distribute the workload across clients.

The bulk of such loads should and ideally must be on servers, not clients. Use PHP, not JavaScript.

Also worth noting, the biggest motivator for JavaShit by far is the website owner(s) cutting costs. More load on the clients is more idling of the servers, the consequences of this will be homework left for the readers.

You're not distributing the workload to clients, you're duplicating it.

> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website.

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.

The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled.

There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled.

Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.

> There is no actual need solved by using client side include to load a nav bar.

I disagree: this[1] was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.

When you find yourself switching stacks to get some feature, trust me, it's really needed.

> Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.

Sure, and in this specific case all the dev had to do was include a link in each blog post to the root of the site `<a href='/'>home</a>`.

So when the JS is turned off the user can still navigate.

Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification, they already know that most things won't work for them anyway!

IOW, you're not dealing with a clueless user who will wonder why the page has no navigation, you're dealing with someone who spent extra work and effort to get into the state they are, so they're already aware that most things don't work for them anyway!

But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go down that route.

I can assure you, as a competent developer, that adding client-side includes with graceful degradation is maybe 60 lines of JS, cached, with no noticeable delays for the user.

If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.

> this was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.

Client side includes would have solved a small part of the pain points that were listed in the article.

This is a developer who explicitly didn't want to add javascript. Compromising a design goal, especially for a hobby project, to only partially solve your pain points, doesn't seem like a good trade off.

> Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification

Disabling javacript is not a deviation from any specification.

> But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go that route.

I never said either of those those things. I said "lazy" and I never implied anything about the size of javascript required for client side includes.

I never used "SPA" in my response to you I used it in response to this:

>> Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future.

This is not advocating for thin client side include. This is arguing for a world where everything is an SPA.

> If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.

Not only did I never say such a thing, but it is pretty darn clear that I don't hold such a view since you quoted me in your comment as advocating for progressive enhancement, which generally isn't a SPA but uses some javascript.

You should take a breath and try reading things more than once. You've repeatedly put words in my mouth and done so with some oddly aggressive language

looks like you forgot to include the [1]link.

There is no actual need solved by using client side include to load a nav bar.

i am maintaining a site by hand right now. i am fine with copying from a template to get the structure. styles and formatting should be CSS anyways. navigation is the only thing that is a problem. i'll either figure out if i can do navigation in CSS or i'll end up having to use javascript. client side include in html only is the very thing missing here.

> Forcing users to run code just to render some boring text seems like a waste.

Do you serve your content with "Content-Type: text/plain"? Client-side parsing of HTML and CSS, layouting, etc, is a looot of code.

Hilarious post in that it mirrors my own experience. Starting writing a SFS site by hand in HTML, hated writing new things on it, decided to ditch it for a static site generator.

I use a sort of intermediate approach for my personal site. It's just stored as html files in a git repo, and I do write the html by hand for pages that I want to put extra love into (e.g. an annual year-in-review post to share with family and friends). You wrote something in your original "Writing my own damn HTML" post that captures a big part of why this appeals to me: "I see my website as a sort of self-expression project - kind of like a zen garden..."

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.

> As a workaround, I shipped Highlight.js with all my blog articles, which I never really liked. My site was static, so why should I force users to do rendering work on their machines?

Doesn’t the client have to do rendering work regardless or whether the HTML is served server-side or client-side?

No JS, client side code highlight using dark magic: https://blog.glyphdrawing.club/font-with-built-in-syntax-hig...

The best method I found is write in markdown and then use react-markdown on a next.js app. Kind of overkill but it works well.

Ignore the high velocity toys emanating from the strollers of leadership ... and just use WordPress.

God on Clayton to publish his thoughts on his own blog!

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

My main issue with writing html directly is that it's not a writing workflow. I write in my notepad, or in my notepad.exe or word about lots of things, only a few of which I would end up publishing, so htmlizing was always a publishing step that starts with a source material. From that it naturally follows that it can be easily automated, and html is a great format for this in theory, but even as a programmer WYSIWYG is so powerful, I'd rather write in Word or notepad exe and THEN annotate what are the headings and etceteras.

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.

Everyone loves to gripe about Markdown, but I think this the killer feature which keeps it so prominent: it's right at the sweet spot of staying in a writing workflow while still having enough formatting capability to cover ~95% of use cases. Despite all the complaining, I don't expect it to be replaced any time soon and I think all my notes and writing will be in Markdown for many years to come.

I only have 1 markdown editor, in nextcloud. Is there an app that let's me write markdown and then save as .md for publication by something that makes that HTML?

What do you mean markdown editor?

I thought the idea was that you can just write it as plain text in something like notepad.exe

markdown isn't viewed as plain text, though. So a markdown editor lets you edit markdown while seeing what it looks like, with things like "make this highlighted selection bold" as a keypress combo or a button.

Hmm, it also has display support in a lot of random websites and tools like GitHub and reddit

I’ve felt the pain

Honestly, I thought this was going to be another AI post. TIL about zola. Looks cool.

I mean, no shit dealing with raw HTML sucks. I really don’t understand why technical people get in their own way.

Even something like a squarespace site is worth the proprietary commercial money if you enjoy blogging.

> handwriting HTML is honestly not that hard

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!

Html and xml are prime examples of why code prettiness is super important for the developer experience. Markdown and JSON exist because the above are plain ugly.

Reply on news.ycombinator.com