I set out to reproduce the effect from "The CSS Hack You Need To Know", which is all about using the attr() CSS function to extract an attribute's value from the tag being styled so you can apply it to a ::after entry that will display the attribute. The idea is that one could then set:

<div class="notification-bell-container" current-count=5><svg ...></svg> </div>

And get back something that looks like this:

As I was playing with the source code, I realized that it had one major shortcoming: it didn't scale well. For every different size, if you wanted the notification circle to be even approximately in the right place you would need to hand-code the location of the counter and have breakpoint-oriented versions for phone, tablet, desktop, extra-wide, and ten-foot displays.

Can we do better than that? With web components we can do anything.

Many years ago, there was a programming language experiment named Wyvern that promised the polyglot developer he could, in the same file, write each function in a different language, and it would all work. It was a crazy idea at the time, but now? Now we write this way all the time. The Web Assembly Component Model is only going to make that all the more true.

JavaScript developer Katharine Angelopoulos recently wrote an article titled Emerging Paradigms for Delivering Content Faster, and while there's much good in her article there was a line in there that stopped me in my tracks. She wrote:

Static Site Generation came about as a solution to the maladies of SSR and CSR.

As someone who's website literally reads, Created: October 14, 1994 by Elf M. Sternberg, that line made me blink three times. I write stories, and there's no way I was going to convert them all to HTML by hand. From 1994 through to today, a total of 29 years, the story site has been statically generated from something resembling Markdown (for a while it was a format called Muse, which almost nobody remembers, and before that it was just called "Usenet emphasis style"), so static site generation can hardly be called "a reaction to server-side or client-side rendering."

It was literally the first thing we did. But the Eternal Amnesia means most people don't know that.

As I mentioned in my last post, I really wanted to find a Web Component library that builds, you know, Web Components. Each component should be a standalone, loadable file ending in .js that instantiated the constructor of a fully-realized web component. I wanted a few bells and whistles, like HTML and CSS auto-templating, Typescript is a must but Sass is a nice-to-have.

Stencil promised that. It's promise reads "Stencil is a library for generating small, blazing fast Web Components that run everywhere." I'm took them at their word.

They lied.

I dislike "magical thinking" in software development and React has become too magical.

I've been a React developer since 2015 so I went through the "class-based to function-based" revolution in React Development. I've gone through the iterations of learning about Hooks, and Memos, and Callbacks, and I have to say that modern React requires a daunting amount of experience to write with any competence as well as a deeper understanding of JavaScript's call-by-value vs call-by-reference nature to avoid re-renders.

So it was with the typical glee of confirmation bias that I read Nudge's React is Holding Me Hostage in which he outlines the problems with modern React, including the illusion that state in React is a part of the component when, in fact, it is an input to the component.

Unfortunately it looks like the Lit team is making the same mistake.

One of the things I've always wanted for my website is a search engine that wasn't beholden to Google. I've considered using Solr or one of those, but I really wanted something local. Something that ran on my laptop. Something that wasn't "in the cloud."

I had helped developed a library science application back at university, but that was over 30 years ago, and while I actually still have that textbook the techniques in it are outdated. I thought about using Tantivvy or something along those lines, but each was a complicated mess.

Then I discovered Meilisearch, and I fell immediately in love. It's a typo-friendly, incredibly fast, and (for searches) lightweight search engine that you can run locally.

Here's how I built it:

Recently I've been restoring an ancient website, one I first created in 1994, 29 years ago: The alt.sex FAQ.

alt.sex was the very first question-and-answer forum for sex-related questions on Usenet, even before there was an Internet, and somehow, when I was 28 years old myself, I wound up in charge of the editing team putting together the FAQ for that wild place. It's been 25 years, I wondered what it would be like to rebuild the site in a modern setting. It was fun.

Every image on a webpage is, unless you take measures to prevent it, draggable and droppable. Even on Linux, which isn't the world's most user-friendly operating system, you can pick any image on the page and drag it off, drop it onto your file manager of choice (Caja, Nautilus, KFM), and you'll be prompted for a filename under which it should be saved.

Sometimes you have complex forms that people click through very quickly. Your controls include card interfaces with a picture and a checkbox or radio button, and sometimes a sloppy click on one of those won't register as a click because it'll register as a drag on the photo instead, annoying the customer. Here's how to prevent that:

About fifteen years ago at a startup, I built a very data-heavy single page app for biologists to manage a map/reduce version of a gene sequencing engine, and because it was data heavy, it made use of templates to render much of the HTML. If you've ever been in this situation, you reach for a library.

With HTML Templates, you might not need a library. But I suspect you're going to want one.