A note on qual­ity

This is a draft” post. If you’re look­ing for an ex­pla­na­tion of what a draft post is do­ing on a pub­lished site, you can find one here.

In short, this post most likely does not meet my high stan­dards — at times, even base­line. It may not be com­plete, have spelling er­rors, etc. I have pub­lished it be­cause I think in some way, as in­signif­i­cant as it could be, you might find it re­source­ful.

Been spend­ing some time do­ing some New-Year-cleanup on my site. The end-goal is to keep the code­base lean and main­tain­able. Here’s the low­down…

Removing Preact and live web­men­tions.

When I first set up web­men­tions on my site, I fol­lowed Max Bock’s tu­to­r­ial. It seemed like a neat idea to have live web­men­tions take over the sta­tic por­tion and re­place it.

It’s not. It’s not a neat idea. I have to main­tain two files (one in Liquid, one in JavaScript) for the same func­tion­al­ity. Every time I make a small tweak in the liq­uid file — the one that re­ally mat­ters — I need to go in and make that same change in the Preact com­po­nent.

I use web­men­tion.io for fetch­ing and dis­play­ing live web­men­tions. Unfortunately, it does­n’t quite work out of the box for all browsers. There are… workarounds but I’d rather not keep falling into workarounds.

This change re­moves preact, detect-browser, and my own com­po­nent-spe­cific code. Instead, I now build my site us­ing a web-hook 2x a day, which I might re­duce to 1x a day.

The bun­dle size goes from 43.9KB com­pressed to 5.2KB com­pressed. Sweet! This only saves me about 0.1 sec­ond in load time, so any per­for­mance in­crease is neg­li­gi­ble. That was never my goal any­way with this change.

Collapsing web­men­tions and com­ments into a sin­gle area.

I also took in­spi­ra­tion from Paul Robert Lloyd and Jan-Lukas Else here who dis­play their in­ter­ac­tions in a col­lapsed details el­e­ment — huz­zah for HTML! 😊

Where my in­ter­ac­tions used to look like this:

Two separate, visible-by-default sections for webmentions and guest comments, each with an introductory text. "Two separate, visible-by-default sections for webmentions and guest comments, each with an introductory text."

They now look like so:

Two collapsed-by-default toggles for webmentions and guest comments, with no introductory text. "Two collapsed-by-default toggles for webmentions and guest comments, with no introductory text."

Probably far more boring” — but I quite like it for now.

Cleaner IndieWeb posts, less link’ over­head.

I felt the main mi­croblog page is quite… heavy on the eye. So I re­moved the links per post type, and slimmed down the mi­cro post card. I doubt any­one cared for the cat­e­gories on the in­dex pages, or the fact that a cer­tain post does or does not have web­men­tions.

Before:

A screenshot of my Microblog page showing links to index pages for different post types, and a detailed post menu card showing a permalink, publish date, categories, whether it is stale, and whether it has webmentions. "A screenshot of my Microblog page showing links to index pages for different post types, and a detailed post menu card showing a permalink, publish date, categories, whether it is stale, and whether it has webmentions."

After:

A screenshot of my new Microblog page with a page-level introductory text, no links to index pages of different post types, and a cleaner micro post card -- with only the title, content, and the date acting as the permalink now visible. "A screenshot of my new Microblog page with a page-level introductory text, no links to index pages of different post types, and a cleaner micro post card -- with only the title, content, and the date acting as the permalink now visible."

Less use­ful, but I like it. The perma­link pages any­way carry the de­tailed info and meta­data.

Still on the agenda…maybe.

I’d be very cu­ri­ous to hear your thoughts on these sub­jects.

Removing TailwindCSS.

Tailwind is great, and al­lows for easy de­sign it­er­a­tion. Now that process is largely done. I’m still work­ing on this task, and it’ll prob­a­bly take a while to go through with.

Why do it at all, though?

  • It slows down my browser to a crawl when I’m de­vel­op­ing and want to tweak things within the browser.
  • I have to wait for the de­vel­op­ers to add sup­port for CSS fea­tures. For ex­am­ple, on the v1 re­leases, there was a time I kept us­ing mr-3 (to add mar­gin to the right) in­stead of just us­ing gap in vanilla CSS, which Tailwind did­n’t sup­port at the time. Yikes!
    • I hate keep­ing up. One less mov­ing part would be nicer.
  • My markup has be­come gory and un­read­able. I’d like to sim­plify it and make sense of it at first glance. This would also give me head­space to im­prove the over­all se­man­tics.

Ultimately, my CSS will be vanilla CSS with mod­ern/​up­com­ing CSS fea­tures us­ing PostCSS. One fine day, I might drop PostCSS from the build process. This is of course when ever­green browsers ship very good sup­port for the CSS fea­tures I use.

I think this is the right way to go.

Removing guest com­ments.

This is tricky and I’m still un­sure if I want to do it.

What mo­ti­vated me to write guest-com­ments-api and in­clude it on my site was this com­ment left by Ankit on DEV.to back in June 2020.

That, and a de­sire to learn server­less. Which I promptly ditched any­way be­cause of ven­dor-lock-in.

I think I have re­ceived maybe 3 non-spam com­ments all this time. Do you think it’s worth it? If it is, I might con­sider adding com­ments to my IndieWeb notes as well.

Moving off Vercel.

I want to, but once again, I’m not plac­ing any dead­line on this. The idea would be to self-host a Drone CI server that builds the site upon git pushes and via web­hooks, which is then handed over to Caddy for a quick file-server.


Well, that’s most of it. Oh, and the home page is also a bit leaner now!