“Hey, hope you’re doing well!

I was going to link to something of yours for an article I’m writing for Piccalilli, but I keep getting a “This site can’t be reached” error in Chrome. I tried in Firefox, and it’s saying it can’t establish a secure connection... Andy just left a comment saying it’s working for him, so it might be a regional thing? I have no idea.”

Wait. My site is down?

I switch into the browser and load the site. It’s fine. I hit refresh. Still fine. I pick up my phone and load the site there. Also fine. I feel a little lift of relief, followed immediately by confusion: If my site is down for Kevin but not for me, something’s definitely not right. Maybe it really is a regional thing?

So, I do what any legitimate web person does when confronted with a problem: I throw technology at it. VPN time! I connect through Canada, because that’s where Kevin is based, and sure enough – my website doesn’t load. And I get the same results checking availability through check-host.net from a bunch of other locations: Brazil, Czechia, Hong Kong, India, Japan, and the Netherlands all fail to load the site, for instance.

After a few emails back and forth with my shared hosting provider all-inkl.com the issue is identified: they’ve indeed installed a filter that blocks entire countries from accessing my site. Without telling me. They just decided on their own that the best solution to whatever was happening was geographic surgery. “Your website is being accessed permanently and en masse. This is presumably a DDoS attack,” they wrote. “We have installed a filter that only allows access from certain countries so that we can protect the server from overload.”

An Alien Invasion

A DDoS attack? A botnet trying to hammer my server into submission? Really? I look at the access logs. No, this is something different. This is methodical. Millions (!) of requests over a couple of days from things with User-Agent strings reading GPTBot, OAI-Searchbot, Claude-SearchBot, or Meta-ExternalAgent, plus a whole bunch of IP addresses from Singapore, Shenzhen, and other parts of Asia scanning my articles and notes sections. That’s not a botnet DDoS attack. That’s an LLM bot “attack” by OpenAI, Meta, Anthropic, and many others.

In their hunger for data to train their large language models, companies from all over the world are systematically harvesting every word I’ve ever published, feeding it into their language models to keep them fresh – and the side effect, the collateral damage, is that Kevin in Montreal now can’t read my articles because my hosting provider decided the solution was to block Canada and half the rest of the world.

I sat there staring at those logs for a while. The irony wasn’t lost on me. This is my little corner of the web. My writing. With my weird little style mixer up there in the top right. And now it is simultaneously being strip-mined by AI companies and effectively made inaccessible to actual humans around the world who might want to read it.

This is where we are in 2026. There’s something happening on the Web at the moment that almost feels like watching that old arcade game Space Invaders play out across our servers. Bots and scrapers marching in formation, attacking our servers wave after wave, systematically requesting page after page, relentlessly filling their data stores while we watch our access logs fill up.

The webspace invaders have arrived.

And the numbers are staggering. About 50 percent of web traffic is now coming from non-humans. Bots, crawlers, and agents are constantly moving across our servers in search for new pieces of content to absorb and while search engine crawlers are still the highest traffic bot category, AI/LLM bot traffic is constantly surging, with AI training being the main crawl purpose. According to Cloudflare’s 2025 Year in Review report, AI bots originated 4.2 % of HTML requests. But this number excludes Googlebot, which crawls for both search indexing and AI training, and averaged at 4.5 % of requests. Yes, according to Cloudflare, Google’s crawl volume is still bigger than all other AI crawlers combined. And in some months of 2025, the numbers were even more extreme. Take April 26, 2025, for example: on that day, human traffic only accounted for 34.5 % of HTTP requests worldwide. AI bots came in at 4.1 %. A number that is already high on its own but is being dwarfed by Googlebot with a whopping 11 % of HTTP requests. I repeat: 11 % of HTTP requests worldwide coming from Googlebot alone. The rest of “Non-AI” bots averaged at 50.1 % of requests that day. And this number might still include a fair amount of LLM training bots that hide behind fake User-Agent strings.

The Open Web Subsidizing Big AI?

Here’s the thing about running a personal site on modest hosting, the kind of hosting most of us are on: you notice when things change. The big platforms, they can absorb all this additional traffic without blinking. They have CDNs and server farms and maybe even entire teams of people thinking about handling bot traffic.

But me? I’m running a simple setup. A Craft CMS site on shared hosting, some static files here and there, nothing fancy. Just like the majority of people with a personal site or a blog. And suddenly, I’m getting hammered with enough traffic that my hosting provider is implementing emergency measures. And I’m not the only one. Just recently, Remy did not only notice unusual spikes of traffic on his blog, but his project JS Bin was hit so hard by massive spikes in network inbound traffic that he was struggling to keep the site online. As Jeremy mentioned, The Wikimedia Foundation is also seeing unprecedented amounts of traffic generated by scraper bots. While humans tend to browse with intention, those AI crawlers “binge read” indiscriminately and visit also the less popular pages. 65 % of this resource-consuming traffic they get for Wikipedia is now coming from bots.

And when I asked on Mastodon and Bluesky, plenty of people chimed in. Turns out I’m really not alone. People are seeing the same pattern on their own sites – often serious enough that they’ve had to take action. There’s even a classic tell at the moment: waves of “users” visiting from Singapore with suspiciously old Chrome User-Agent strings.

There’s a power imbalance at work here that’s hard to ignore. Large “AI” companies, the ones with billions in venture capital, send their bots to harvest free content. Not only from big publishers or Wikipedia, but from small, independent websites, too. But we, the people running these sites – often as passion projects, as ways to freely share what we’ve learned, as digital gardens we tend in our spare time – we’re the ones paying for the bandwidth and server resources to handle all those additional requests while those companies profit from the training data they extract. It’s an asymmetric battle: small systems absorbing the demands generated at an entirely different, industrial scale.

These companies might not be plotting evil, but they’re externalizing their costs and aren’t particularly concerned about the collateral damage. Sure, some still provide robots.txt compliance. They’ve published documentation about their crawlers, albeit often incomplete. But even compliance and documentation won’t change the fundamental math: when you have dozens – no hundreds, soon thousands of companies (just look at the download counts on Hugging Face for any popular model), each running their own scrapers, each one binge-reading your site not once every two weeks like earlier versions of Googlebot used to do, but several times a day, the aggregate effect can quickly overwhelm a small site. And as long as the training data keeps flowing and the models keep improving, why would they change anything?

Good Bot, Bad Bot

Alright, it’s bad, obviously. But things get even messier. In Space Invaders, the aliens followed predictable patterns. You could learn their behavior, anticipate their movements, and develop strategies to play the game longer and score higher. The game we’re playing on the Web now? It’s unpredictable.

Because on the Web, we’re now playing against adaptable opponents. Scrapers from Singapore that hide behind spoofed User-Agent strings, in an attempt to appear as though they are a real browser, instead of identifying themselves honestly. Scrapers that change their IP addresses regularly. Scrapers that obviously don’t give a penny about your cute robots.txt. Scrapers that obviously don’t care about the gentleman’s agreement that the web was built upon.

And we’re just entering the next phase. Agentic AI. Systems that can autonomously explore websites, adapt their scraping strategies based on what defenses they encounter, rotate IP addresses, work around rate limiting. The bots are getting smarter by the minute. More persistent. More capable of treating every attempt to protect our sites as a new puzzle to solve.

This isn’t Space Invaders anymore. Those aliens invading our webspaces are locking on and firing relentlessly, constantly adapting, learning, and getting stronger. And here I am – one human with a keyboard – trying to keep my site accessible to other real humans while it is being harvested and under fire from all directions.

And to cap it all, all of this is happening against a backdrop of genuine geopolitical competition where training data for large language models is being seen as strategic infrastructure. The countries and companies that control the best AI models are said to have real future advantages – economically, militarily, politically. This transforms web scraping from an annoyance into something that’s part of a much larger power struggle. Chinese AI companies might not be that concerned about conventions around robots.txt or polite crawling. But honestly, American AI companies are under pressure to maintain their lead, and when prioritizing growth over everyone else in your path is the business model, they’re perfectly willing to cut corners, too. Everyone’s racing, and the open web looks like free resources up for grabs. The result is that my personal blog – your personal blog – becomes collateral damage in this competition. The scrapers don’t care that you’re not Facebook or the New York Times. Your content is data. Data is valuable. And in this race, the externality of overwhelming small site owners is just the cost of doing business.

“Just Use Cloudflare”

So naturally, there’s a corporate solution being offered. Cloudflare, with its massive network infrastructure, provides (free) AI bot protection now. You add some DNS entries, flip a switch in the Cloudflare dashboard, and let their systems handle the AI crawler traffic for you.

And from what I hear, it works fairly well. Cloudflare can identify and block malicious scrapers at a scale that individual site owners simply cannot. They can distinguish between real browsers and bots masquerading as browsers. They have the data, the machine learning models, the infrastructure, and the threat intelligence.

But I keep coming back to this question: should we all need to route our traffic through Cloudflare? Is that really the sustainable solution to the webspace invaders problem? Is that really the open, independent web we want?

Because here’s the thing: Cloudflare already sees an enormous percentage of web traffic. They’re a neutral actor now. But power structures change. Companies change. Countries and their governments change. Obviously. Every time we centralize infrastructure in response to a threat, we make the web a little less distributed, a little less resilient, and a little less ours. And we all saw last year what happens when half of the web relies on just one single point of failure. Within just one month, Cloudflare experienced two major outages: a global outage on November 18, 2025 took down roughly one in five webpages globally at the height of the incident, and one-third of the world’s 10,000 most popular websites, apps, and services, according to some estimates. Another significant incident occured on December 5 while Cloudflare attempted to detect and mitigate an industry-wide vulnerability in React Server Components.

I sat with all this for a while, trying to figure out how I felt about it and what to do with it. On one hand, I don’t have the time or expertise to run sophisticated bot detection on my own. I have a day job. I have a life and a family. The idea of spending weekends maintaining IP blocklists and analyzing traffic patterns is exhausting just to think about.

On the other hand, every small site owner routing through Cloudflare means more consolidation, more centralization, more of the web’s infrastructure dependent on a single company’s good intentions and continued solvency.

I don’t have a good answer here. I really don’t. It’s one of those problems where all the solutions feel inadequate, somehow.

Still, I decided to give it one last try. And so, I spent the last few weeks moving my site from my shared hosting plan over to a virtual private server (VPS) where I have more control over the protection layers of my site and where nobody can add a country filter without my knowledge. I’ll write more about other aspects of the setup in future posts.

Activating Your Site Shields

But for now, let’s look at a few practical ways to fight back against those webspace invaders. Because although the bots and agents are getting smarter by the minute, there is still a lot we can do to better protect our sites and hosting bills.

You, Robot?

The first step (still) is to start with robots.txt, even though this won’t stop them all. Create a robots.txt file in your web root if you don’t have one yet, and then explicitly disallow known AI scrapers of your choice:

If you want to go further, you can block wide whole range of known LLM bots with a list like the one at ai.robots.txt or even serve a robots.txt that continuously updates via Known Agents (formerly known as Dark Visitors – interesting name change, by the way). It’s not a complete solution, but it’s a starting point that takes a few minutes to set up.

However, using robots.txt will only work for the actors that actually honour this convention. If a crawler decides to ignore your robots.txt, nothing will stop it. That’s why a lot of people, just like Ethan, have also started blocking bots via .htaccess.

For my new VPS setup, I now use nginx to serve my site. And so, instead of using .htaccess, which does only exist on Apache, I added a user agent check to the nginx config instead, similar to the one you can find in the ai.robots.txt repo:

If the User-Agent string matches that of one of the bots on the list, the server now returns a 403 Forbidden status code and blocks the request. In case you're running an Eleventy blog on nginx, Robb has written about a similar approach he is using to block bots on his site.

One important note, though: if you want to still allow the Internet Archive to archive your site, which you should, make sure to not block their archive-org_bot – like I did at first. ;)

Rate Limiting

If you control your server configuration, rate limiting also becomes essential. Real humans very rarely request fifty pages per second. But aggressive scrapers definitely do. Therefore, putting a cap on how often someone can repeat an action within a certain timeframe can help stop malicious bot activity and reduce strain on your server. If you’re on nginx, look into limit_req_zone and limit_req, as explained in this post on the nginx blog. Apache has mod_ratelimit.

The tricky part is setting the right thresholds. Too strict and you risk blocking legitimate users or search engines. Too loose and the scrapers slip through easily. I’ve been experimenting with this, and honestly, it’s been a lot of trial and error and I’m still not 100 % sure if my settings are ideal. The general advice is to conservative – maybe 5 to 10 requests per second per IP – and adjust based on what you see in your logs.

My own setup, which complements the nginx config setup above, now distinguishes between three tiers of visitors based on User-Agent strings: the most aggressive bots and crawlers are blocked immediately, less aggressive crawlers – those that respect robots.txt – and user-initiated AI searches are moderately throttled, while everyone else (presumably humans, I hope, I’m still very hopeful, I guess) falls into the least restrictive tier. Using IP addresses would strengthen this approach even further, since, as we know, malicious actors will spoof their User-Agent strings. But for now, this additional rate limiting layer should help catch another significant number of aggressive invaders and cut off the peaks.

Monitoring Your Access Logs

I know, it sounds tedious. And it is. But you need to know what’s actually hitting your site. And means looking into the access logs of your server or webspace, not just your analytics dashboard. Because tools like Fathom or Plausible will only tell you half of the story. They apply their own filters to keep your analytics clean and bot-free, which is great for understanding human visitors. But that also means that there is no way around looking at your raw logs.

I recently spent hours going through mine, identifying the IPs with the most traffic and blocking them manually as a first, probably a bit unsustainable counter-measure. But it helped me to understand the problem better – and also to check whether my actions actually had an effect.

Tools like GoAccess can be super helpful for this, because they give you real-time insights and even let you set up alerts for unusual traffic spikes. Because ideally, you want to know when something weird is happening, not discover it three days later when your hosting provider has already implemented their own “solution.” This goes double for client sites.

Using IP Blocklists

IP blocklists are part of any solid firewall setup, but you need to be thoughtful about it. There are well‑established resources that publish lists of IP addresses of known scraping networks, exploiters, spam sources, and other malicious actors – data centers that legitimate traffic would never come from. Useful resources include AbuseIPDB, Spamhaus’s Don’t Route Or Peer Lists (DROP), blocklist.de, or All Cybercrime IP Feeds by FireHOL.

You can then block those IPs with a firewall like Linux’s iptables via ipset. This, however, requires ongoing maintenance because those lists need updating. There are ways to configure your server so that the lists get updated automatically. In my case, I am now using Hestia Control Panel on my server, which makes configuring iptables a bit more comfortable when blocking individual IPs or whole blacklists. But you should still be very careful to not block legitimate traffic or even yourself. It is all about finding the most trustworthy lists and not being overly aggressive. And again, watching your logs.

Poisoning Well

For the really aggressive invaders, especially if you’re concerned about LLM scrapers harvesting your content without consent, effectively violating your copyright, there’s another approach: serve different content to suspected bots, or as Heydon put it, poison the well, actually. Feed them garbage data. It won’t stop the bandwidth drain, but it does something about the copyright violation.

WAFs: Blocking the Baddest Baddies

The final layer of protection would be to install a web application firewall (WAF) that includes bot protection. Open-source tools like BunkerWeb, SafeLine, or the really interesting Anubis provide multi-layered defense against bot attacks through CAPTCHA verification or other challenges, dynamic protection, and anti-replay protection. They are basically an additional layer (a reverse-proxy) between your app or website and the internet that only lets the good traffic through.

But the bigger you make the concrete walls around your digital garden, the more likely it might also have negative consequences. You might block legitimate crawlers. You might hurt your accessibility and block real humans. And you might spend hours installing and maintaining systems that break in weird ways. To me personally, tools that put a challenge in front of real humans still feel a bit like admitting defeat.

So I haven’t yet tried Anubis, for example – although it might well be the best way to really get rid of the crawlers. But I’ll definitely keep exploring this space and try out this and other tools, now that I have my own virtual private personal website server.

The Web We Wanted

We built the web on optimistic assumptions. We assumed good faith. We assumed people would respect robots.txt because we all understood we were building something great together. We created these protocols and conventions because we believed in mutual respect and shared purpose. The Web was supposed to be for everyone.

But when training data becomes worth billions of dollars, when AI capabilities determine who wins and loses in global economic competition, when scraping is a strategic commercial activity, then those assumptions break down.

Part of me wants to believe that we can still maintain an open web without surrendering to corporate infrastructure or turning every website into a defensive fortress shooting webspace invaders. Part of me wants to believe that international cooperation could establish better norms over time and that the companies building these AI systems will take responsibility for the externalities they’re creating. (Haha.)

But I’m now also old enough to be an optimistic realist. I’m watching my access logs, I’m watching the arms race escalate, and I’m wondering how long places like mine can hold out. How long before every personal website needs enterprise-level protection just to function? How long before the cost of publishing your thoughts online becomes prohibitive for regular people? For some, it might be already.

It feels like we might soon be forced to choose between accessibility and survival. Between openness and sustainability. Between our ideals about what the web should be and the practical reality of keeping our sites online.

An Infinite Game

Stories like mine are now probably happening to more small site owners everywhere. Many of them might not even know why their hosting bills are climbing or why their sites are suddenly down in certain countries. And once they find out, many of them might not be able or willing to set up a VPS and spend hours fiddling with server logs, firewalls, blocklists, and nginx config files.

Yes, the AI companies need to do better. They actually should throttle their scraping to reasonable levels. They actually should respect the limited resources of small sites. They actually should develop industry standards that don’t externalize costs onto individuals who are just trying to share their work. This might even be in their best interest, because ultimately, they also risk destroying the very ecosystem they depend on – after all, what will their LLMs learn from when the independent web has been scraped into extinction? But I’m also not holding my breath for voluntary restraint when there are billions of dollars at stake. In the end, it is also on us to adapt to this new reality – clear-eyed and pragmatic.

So what do we do? We document what’s happening. We block scrapers. We move to better, more capable servers. We share our approaches and learn from each other. We push for better standards and regulations where we can. We make noise about the problem instead of suffering silently. Because this is the Open Web and and the Web was designed so that we can still do all that. That’s the magic of it.

I for one am not giving up my little corner on the Web, of course. I'll continue to document and write about that journey that is my personal website. Over the coming weeks, I will share my experiences with my new VPS setup – how I configured the server, how I set up my continuous deployment pipeline for Craft CMS (yes, I have that now, Manuel! 😉), how I configured caching and other performance improvements, and I’ll also finally write more about the redesign and CSS of my site. Because that’s what our little corners on the Web are all about. That’s what the personal website verse is all about. And that’s what we are trying to protect here.

So, if you’re running a website, check your logs. Set up some basic protections. Share what you find. Be part of this conversation. Write about the future you want. Because the alternative is watching the independent web getting scraped into oblivion while we all wonder what happened to the Web we loved.

Here’s the thing about Space Invaders, the game: it didn’t end when the aliens reached the bottom. It just started over, harder and faster. Maybe that’s where we are now. It’s not game over. Not yet. Just the next level. And we need to get better at playing it.

👾👾👾

What has your experience been with AI scrapers? Have you found approaches that work? Have you “given up” or moved to Cloudflare? I’m genuinely curious what’s happening in your corner of the Web, because I suspect we’re all dealing with variations of the same problem. So let me know via Webmention, Mastodon, Bluesky, email, or maybe even in a response blog post.

Own Your Web – my newsletter about building personal websites, publishing independently, and reclaiming your corner of the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

Trig Functions

The Trig functions that are now available are as follows:

• sin()
• cos()
• tan()
• asin()
• acos()
• atan()
• atan2()

If you have ever studied Trigonometry, then these do exactly what you think they do. If you didn’t, this is all extremely helpful for calculating angles and lengths of sides of triangles. Math stuff.

Let’s talk about where you’d use them.

Placing things in a circle

This is the classic example that shows off being able to calculate the placement of multiple items based on their angle relative to each other.

CLOCKS!!

You can now easily make a clock that will have hands that are correct

Browser Support

These functions are well supported, and can absolutely be used, today!

More Resources

• Web.dev

I heard from quite a few people who were excited about the Web Component Engineering course but missed the Thanksgiving sale window. So, as we wrap up the year and head into a new one, I’m running one more sale as a bit of year-end / new-year “good tidings.”

From now through the first week of the new year, you can get 25% off my Web Component Engineering course when you use the discount code GOODTIDINGS25 at checkout.

About the Course

Web Component Engineering is a self-paced, in-depth course on modern UI engineering through the lens of Web Components and core Web Standards. It’s designed to help you move beyond framework-only knowledge and really understand the Web Platform you’re building on.

You’ll get a deep dive into topics like:

• Using and authoring Web Components in real applications
• Working directly with DOM APIs instead of only through frameworks and abstractions
• Modern CSS for robust, scalable UI systems (including Shadow DOM styling, container queries, and more)
• Accessibility as a first-class concern in component design
• Form-associated custom elements and integrating components with real forms
• Design systems, tokens, and component libraries built on Web Components
• Application architecture, routing, and app shells with Web Components
• Tools and libraries like Storybook, Playwright, Lit, FAST, and others you’ll use in production

The course is trusted by engineers at top companies and is designed to be the “missing manual” for serious UI engineers who want to master the modern Web Platform.

What You Get

When you enroll, you get access to:

• 13 modules with over 170 lessons, fully self-paced
• A custom interactive learning app that lets you follow along, run demos, and experiment in the browser with no setup
• Runnable examples, downloadable notes, and reference materials
• A Certificate of Completion you can share with your team or manager

Whether you’re building a design system, maintaining a complex front-end, or just want to understand what’s really possible with modern Web Standards, this is designed to meet you where you are and push you to the next level.

Sale Details

• Discount: 25% off
• Code: GOODTIDINGS25
• Valid through: The end of the first week of the new year
• Course: https://bluespire.com/course/web-component-engineering/

If you missed the Thanksgiving window, or you’ve been on the fence, this is another chance to invest in your skills and deepen your understanding of the Web Platform.

Thanks for being part of the Web community, and here’s to a great year of building better UIs with Web Standards.

I'm joining the bandwagon and declaring that 2026 will be the Year of the Linux Desktop. Specifically for the subset of fitness gaming apps, it's no longer necessary (or preferred) to be tethered to Windows.

Two long-term trends have led to this moment.

Windows has been on a "slowly, then all at once" descent in quality that really started ramping up last year.

Working with our client sysadmins on a daily basis, I get to see first-hand the OOB patches and hotfixes we've been scrambling to apply (including this weekend when Patch Tuesday broke core RDP functionality) and pray don't make the experience worse. Combined with a "Continuous Innovation" and "Controlled Feature Rollout" strategy that launches features when you least expect it, and it's made everything feel ephemeral and ready to break at any moment. When was the last time you got excited for an update, rather than dread it?

I don't think it's any surprise this corresponds with Microsoft's headfirst embrace of generative AI. Both internally (Satya claims 30% of Microsoft's code is AI-written) and externally (the "everything is Copilot" meme, the rebranding of Edge as an agentic browser), it's inescapable.

At the same time, desktop Linux has been steadily improving and growing more reliable. Some of this has to be spillover from investment in downstream OSes like ChromeOS, Android, and Steam OS, all based to some degree or other on Linux. Core peripherals like Bluetooth work across all my devices I've tried it on, on machines both designed to run Linux and on PCs with random hardware I didn't even check compatibility with before installing.

My Distro

One meme I've struggled with is the tendancy for Linux desktops to start off strong, but degrade in reliability over time.

Historically this feels like a problem I'm also culpable for. A common experience is for userland changes applied to make a Linux desktop functional would inevitably break some unrelated part of the system. Install a new Python 3 runtime for a project, and somehow you've broken your virtual desktop setup, because it relied on 2.7.

The critical drive lately has been the rise of atomic desktops. These distros are "immutable", in that core filesystems are read-only and cannot be modified, even as root. The OS (and supporting packages) are updated all-at-once, and can be rolled back to a previous release if anything goes wrong.

Almost all userland work is accomplished with high amounts of isolation. GUI apps are Flatpak, and CLIs use Homebrew, so they don't interfere with system packages. Want to setup a development environment? On Bluefin, you're pushed to use devcontainers, so everything happens inside an OCI (here Podman) container.

It's pretty incredible how far you can take this approach. Bazzite (a gaming-focused distro) works so well that it's very common to as a drop-in replacement on Steam Deck (replacing an Arch-based OS). I'm running it on my gaming desktop and spent more time fighting Windows UEFI bugs than I did getting a fully-working setup.

Bazzite ships with Steam and its Proton compatibility layer, but my games need to run outside Steam. How does that behave? Turns out, great!

Zwift

My favorite cycling-themed MMORPG doesn't have a native Linux port and probably never will. It also has quite a few Windows system dependencies (its launcher relies on an Edge-based WebView2), and of course it needs access to a GPU and peripherals like Bluetooth/ANT+. I've been trying to get Zwift running for years with tools like Wine/Lutris, but every attempt at getting it running failed, and I'd inevitably corrupt my environment installing incompatible, conflicting versions of Visual C++ Redistributables.

This has been almost completely fixed with Kim Eik's netbrain/zwift repo - an all-in-one Docker container that setups an isolated Wine environment, installs Zwift, and applies a known set of working patches. The result is a setup that's easier to run than Windows.

Not everything works yet. In particular, Bluetooth (needed to interact with the trainer, heart rate monitor, etc) isn't available, though there's ongoing development that I'm hopeful for.

In the meantime, I'm setting things up using alternate means. My trainer supports Wi-Fi connections, so no Bluetooth is needed for power, cadence, and resistance. I even set up the trainer on an isolated VLAN (as it's essentially an expensive IoT device I don't have full control over), and Podman was able to discover it after setting networking=host.

Other peripherals (controllers, HR monitors) still require Bluetooth, so I've just got an old Android device running Zwift Companion sitting on my trainer desk. Honestly this is the most "non-native" part of my entire setup, but I'm still using supported tools (and was having to use the Companion even on Windows after an update broke BLE connections).

Zwift runs at a clean 60fps, and I'm able to stream to Owncast via OBS just like before.

Beat Saber

This one I thought would be more challenging. As a VR rhythm game, I'd expect significant hurdles to a clean, performant experience.

My setup has always been a little unorthodox: on Windows I've been running a modded Beat Saber, installed using BSManager to setup extra songs/mods, and control which version I run. The game then streams to a Quest 2 headset, and I pray the latency gods are favorable. I spent the better part of last year getting this setup working well on Windows, and settled on tweaking Virtual Desktop to stream the game, limiting the resolution and frame rate along the way. Other tools like Oculus Link and Steam's own wireless streaming just weren't cutting it.

Turns out, Linux VR gaming is pretty solid these days. The LVRA community has been compiling tools and best practices for years, and many things are turnkey now. Need to stream to a Quest headset? Pick between ALVR and WiVRn. And again, both are installed as Flatpaks, so if you get it wrong, it's super easy to change course!

I went with WiVRn, as it bundles its own, Steam-independent OpenXR runtime, which has been supported by Beat Saber for years. And with a few small changes to the command-line arguments in Steam, I had vanilla Beat Saber running on my headset almost immediately. Interestingly, performance seemed to be even better on Linux than Windows; I was streaming at 120fps (on Windows I limited to 72) and my audio latency was down by nearly a third (~60ms compared to 90 on Windows). This isn't uncommon, quite a few benchmarks a game running on Linux can outperform its Windows counterpart.

Finally, I wanted to get modded Beat Saber running. Luckily BSManager provides a Linux flatpak that installed without issue, and I could download and mod versions just like on Windows. Getting it running on the headset proved to be a much bigger challenge. Out of the box, the WiVRn app list on the device wasn't detecting the modded Beat Saber, so I couldn't start it.

With some help from the BSManager Discord, I found the set of environment variables that needed set (within BSManager) to get it to launch. But the workflow was pretty horrendous: start WiVRn on the PC, then launch the client on the headset. Then take the headset off and launch Beat Saber on the PC. Then, put the headset back on and start playing.

It turns out there were a few bugs in both BSManager and WiVRn that prevented the app from being discovered, and launching properly. With some trial and error (and reading a bit more C++ than I was ready for), I was able to get it running. The details are in this GitHub Issue - and fixes have already landed in the WiVRn codebase.

This feels like a telling anecdote where the Linux gaming ecosystem is at: the fundamental components to play even complicated games are solid, and have been steadily improving. And when things don't work, there's a community to help address it. Hopefully more of this knowledge will get pulled out of private Discords and into public knowledge bases (or simply fixed at the root).

I can tinker with Linux when I need to cool down

I feel like I've just scratched the surface of what a Linux gaming PC can do. My library is pretty small, but I expect to grow it, especially with the Steam Frame inbound, offering another VR headset running Linux directly.

Of course there are other neat features you can try with a Linux machine with a decent GPU. Bluefin's AI strategy is one of local operation and control. So if you want to experiment with LLMs, you can install Ramalama, pull down a model from Huggingface you're comfortable with, and use your own GPU and resources. It feels like a breath of fresh air to have control of what's running on your machine, compared to the Windows experience of "what fresh hell with this restart bring today".

if we go for HTML email, we can apply just enough layout and styles to make it almost like a plain text email, only with a bit more class.

• A pleasant readable typeface
• Reasonable line length
• Breathable line height
• Anchor links on words
• Dark/light mode

Here’s one from Cursor:

I find a “button” style could be added to that short list of OK things in an otherwise chill HTML email. But I really like how short and sweet the email is. Begs to be actually read.

And one from Mandy Brown:

Probably the nicest typography of any newsletter ever. But really isn’t doing that much to pull it off, just a nice typeface with smart setting.

A recent project of ours involved modernizing a large, decades-old legacy web application. Our fantastic design team redesigned the interfaces and created in-browser prototypes that we referenced throughout development as we built HTML/CSS patterns and HTML web components. For the web components, we used the Light DOM and progressive enhancement where possible, keeping accessibility front and center.

Going in, we weren’t sure how challenging it’d be to write tests for HTML web components. Spoiler alert: It wasn’t too different than testing framework-specific components (e.g., Vue or React) and in some cases, even easier!

For a project of this scope, a strong test suite was crucial, as it enabled us to focus on new features instead of constantly fixing regression bugs and repeating manual browser testing again and again. These are the patterns that worked well for us.

The web component testing stack we used

Our testing stack consisted of:

• Vitest – Fast, ESM-native test runner with Vite integration using a jsdom environment
• Lit’s render() function and html templates to render to the DOM
• The DOM Testing Library (no framework wrapper), along with:
  • @testing-library/user-event – User interaction simulation
  • @testing-library/jest-dom – DOM-specific matchers, for example toBeVisible(), toBeChecked(), and toHaveFocus()
• vitest-axe – Automated accessibility rule checking (to catch low-hanging fruit)
• eslint-plugin-testing-library and eslint-plugin-jest-dom ESLint plugins to help enforce testing best practices

Most of these tools are standard. The interesting choice here is using Lit’s html and render() in the tests. We built our first (and one of the most complex) web components with Lit, then switched to vanilla web components for the rest. Since lit was already a dependency, we continued to use its templating features, expressions, conditionals, and directives in our tests. A few of the benefits:

• Setting up new tests included no manual DOM manipulation
• Provided a declarative HTML-like syntax with editor syntax highlighting
• We were able to create shared parameterizable example/demo Lit templates (shared by tests and Storybook stories), which significantly reduced the boilerplate
• Helped standardize how each test (and Storybook story) should be set up for easier maintenance
• The rendered HTML is immediately in the DOM, which means Testing Library queries and standard DOM APIs work without special setup
• Better TypeScript support within our tests

Overall, a better, more efficient developer experience.

Worth noting, there is also a standalone lit-html library that we could have used instead of the full lit package. lit-html provides html and render, as well as the directive modules. Today I learned. 🙂

Light DOM web components simplified testing

One of the most impactful early architectural decisions we made was to build all web components using the Light DOM instead of Shadow DOM. While we didn’t realize it at the time, it dramatically simplified testing and component composition.

From a testing perspective, it meant we could query anything, anywhere, anytime:

render(
  html`
    <my-amazing-component>
      <my-tree-component 
        data=${JSON.stringify(jsonData())}
      ></my-tree-component>
      <dialog></dialog>
    </my-amazing-component>
  `,
  document.body,
);

With Shadow DOM, we’d need something like:

// ❌ What you'd have to do with Shadow DOM
const component = document.querySelector('my-amazing-component');
const shadowRoot = component.shadowRoot; // May be null!
const button = shadowRoot?.querySelector('button'); // Doesn't cross boundaries
// Or use special testing utilities that pierce shadow boundaries
// And if there are nested shadow boundaries, *eek!* 😬

With Light DOM, it’s much simpler:

// ✅ What we actually do
const component = document.querySelector('my-amazing-component');
const button = component.querySelector('button'); // Just works

And Testing Library queries also just work:

render(validationExample(), document.body);

// screen.getByRole() finds elements INSIDE your components
const emailInput = screen.getByRole('textbox', { name: /email/i });
const submitBtn = screen.getByRole('button', { name: 'Submit' });

// These work because there's no Shadow DOM boundary blocking queries
await user.click(submitBtn);
expect(emailInput).toHaveAttribute('aria-invalid', 'true');
expect(emailInput).toHaveFocus();

Testing Library’s philosophy is “query like a user would.” With Light DOM web components, the mental model matches perfectly.

Testing web component events

Most, if not all, web components we built dispatched custom events with detail data. We used the following Vitest features to confirm the expected event data:

• vi.fn() function spy
• toHaveBeenCalledWith() assertion
• objectContaining() assertion

it('Emits change event when "Confirm" is clicked', async () => {
  const user = userEvent.setup();
  render(
    html`<my-tree-component 
      data=${JSON.stringify(jsonData())}
    ></my-tree-component>`,
    document.body,
  );

  // Set up the handler function spy for the 'change' listener
  // Attached to `document` to confirm event bubbles
  const changeHandler = vi.fn();
  document.addEventListener('my-tree-component-change', changeHandler);

  // Click confirm button
  const confirmButton = screen.getByRole('button', { name: /^confirm$/i });
  await user.click(confirmButton);

  // Event should be emitted with correct details
  expect(changeHandler).toHaveBeenCalledWith(
    expect.objectContaining({
      type: 'my-tree-component-change',
      detail: {
        action: 'change',
        selectedEntityIds: ['test1'],
      },
      bubbles: true,
    }),
  );
	
  // Clean up the event listener
  document.removeEventListener('my-tree-component-change', changeHandler);
});

Testing hidden inputs generated by web components

One of our goals was to minimize the need for legacy backend code refactors. The legacy application relied on good ol’ traditional form submission architecture. Some of the legacy UI relied on JavaScript-generated hidden inputs that satisfied the backend code. Our new web components needed to match this behavior.

When testing the hidden inputs feature of a web component, Light DOM web components made it much simpler because any hidden inputs created by the web component are included in the form submission automatically:

render(
  html`
    <form>
      <my-tree-component 
        data=${JSON.stringify(jsonData())}
      ></my-tree-component>
      <button type="submit">Submit the form</button>
    </form>
  `,
  document.body,
);

// Get the form
const form = document.querySelector('form') as HTMLFormElement;

// Hidden inputs are in Light DOM, so form submission includes them automatically
const hiddenInputs = form.querySelectorAll('input[type="hidden"][name="entity"]');
expect(hiddenInputs).toHaveLength(5);

// They participate in form submission naturally
const formData = new FormData(form);
const entities = formData.getAll('entities');
expect(entities).toHaveLength(5);

In some cases, we needed to confirm the hidden inputs rendered in a specific order with specific prefixed values. To test this, Vitest’s toMatch() assertion with regular expressions came in handy:

expect(entities[0]).toMatch(/^OP(AND|OR|NOR|NAND)$/);
expect(entities[1]).toMatch(/^EL/);
expect(entities[2]).toMatch(/^OP(AND|OR|NOR|NAND)$/);
expect(entities[3]).toMatch(/^EL/);
expect(entities[4]).toMatch(/^EL/);

Testing both attribute and property APIs

Most of the web components supported both declarative (HTML attributes) and imperative (JavaScript properties) APIs. We added basic “render” tests for each use case:

it('Renders via `content` attribute', () => {
  render(
    html`<my-data-table
      data=${JSON.stringify(jsonData())}
    ></my-data-table>`,
    document.body,
  );
  
  const tableEl = screen.getByRole('table');
  expect(tableEl).toBeVisible();
});

it('Renders via `content` property', () => {
  render(html`<my-data-table></my-data-table>`, document.body);
		
  // Set the JSON data via the property
  const component = document.querySelector('my-data-table') as MyDataTable;
  component.data = jsonData();
  
  const tableEl = screen.getByRole('table');
  expect(tableEl).toBeVisible();
});

Typing web component references

We wrote all web components and tests in TypeScript. This helped catch API changes anytime we refactored or fixed bugs. In tests where we wanted to access component properties or methods, we needed to add a type assertion since querySelector() can possibly return null:

render(
  html`<my-tree-component
    data=${JSON.stringify(jsonData())}
  ></my-tree-component>`,
  document.body,
);

// Use a type assertion since we know the element is in the DOM
const myTreeComponent = document.querySelector(
  'my-tree-component',
) as MyTreeComponent; 

// Now you have full TypeScript support
expect(myTreeComponent.treeNodes).toHaveLength(21);
myTreeComponent.data = newData; // Type-safe property access

Tests and Storybook stories shared Lit html templates

As mentioned earlier, sharing Lit html templates helped reduce boilerplate and standardized how we set up all tests and Storybook stories. Below is an example Lit html template for an input validator component:

// input-validator-example.ts

import { html } from 'lit';
import { ifDefined } from 'lit/directives/if-defined.js';

export interface InputValidatorExampleArgs {
	type: HTMLInputElement['type'];
	validationError?: string;
	required?: boolean;
	pattern?: string;
	ariaDescribedby?: string;
}

/**
 * Used by tests and Storybook stories.
 */
export function inputValidatorExample({
	type,
	validationError,
	required = true,
	pattern,
	ariaDescribedby,
}: InputValidatorExampleArgs) {
	const inputId = `input-${type}`;
	let label = type.charAt(0).toUpperCase() + type.slice(1);

	if (type === 'select') {
		label = `${label} an option`;
	}

	if (type === 'text' && pattern) {
		label = `${label} with regex pattern`;
	}

	let field;
	if (type === 'select') {
		field = html`
			<select
				id=${inputId}
				?required=${required}
				?pattern=${pattern}
				aria-describedby=${ifDefined(ariaDescribedby)}
			>
				<option value=""></option>
				<option value="1">Option 1</option>
				<option value="2">Option 2</option>
				<option value="3">Option 3</option>
			</select>
		`;
	} else if (type === 'textarea') {
		field = html`
			<textarea
				id=${inputId}
				minlength="10"
				?required=${required}
				?pattern=${pattern}
				aria-describedby=${ifDefined(ariaDescribedby)}
			></textarea>
		`;
	} else {
		field = html` <input
			id=${inputId}
			.type=${type}
			minlength=${ifDefined(type === 'password' ? '5' : undefined)}
			?required=${required}
			.pattern=${ifDefined(pattern) as string}
			aria-describedby=${ifDefined(ariaDescribedby)}
		/>`;
	}

	return html`
		<div class="form-group">
			<label for=${inputId}>${label}</label>
			<input-validator validation-error=${ifDefined(validationError)}>
				${field}
			</input-validator>
		</div>
	`;
}

This allowed us to use the same HTML for both tests and Storybook stories:

// InputValidator.test.ts

render(inputValidatorExample({ type: 'tel' }), document.body);

// InputValidator.stories.ts

/**
 * The component supports various `<input>` `type` values. Below are examples
 * of different input types that can be used with the component.
 */
export const VariousInputTypesSupported: Story = {
  render: () =>
    html`${[
      'email',
      'url',
      'password',
      'tel',
      'number',
      'date',
      'time',
      'datetime-local',
      'month',
      'week',
      'search',
      'text',
      'checkbox',
    ].map((type) => inputValidatorExample({ type }))}`,
};

Testing for accessibility

Building accessible user interfaces is something we believe in and strive for as a team. Our web component tests helped reinforce this core value.

Every web component had an accessibility violation test assertion

As a baseline standard practice, we always included a vitest-axe toHaveNoViolations() test assertion (including checking multiple UI states as needed):

it('Has no accessibility violations', async () => {
  render(formValidatorExample(), document.body);
  
  const component = document.querySelector('form-validator') as HTMLElement;  
  const submitBtn = screen.getByRole('button', { name: 'Submit' });

  // Initial form state  
  expect(await axe(component)).toHaveNoViolations();  

  // Invalid form state
  await user.click(submitBtn);
  expect(await axe(component)).toHaveNoViolations();
});

Testing Library ByRole queries as the default query

With all our tests, we’d default to querying the DOM using Testing Library’s ByRole queries with accessible names. If a query fails, the control is not accessible (either an incorrect role or an incorrect/missing accessible name):

const submitBtn = screen.getByRole('button', { name: 'Submit' });

Remember: The “first rule of ARIA” is to prefer native, semantic HTML elements and only introduce ARIA roles as needed. In both cases, ByRole queries help confirm the proper role.

Assertions for ARIA attributes where applicable

In some cases, we’d assert certain ARIA attribute values where it made sense, for example:

expect(input).toHaveAttribute('aria-invalid', 'false');

Testing focus management

Keyboard users rely on proper focus management. For example, forms should move focus to the first invalid field on validation:

it('Validates an empty form on submit', async () => {
  // … setup
    
  // Submit empty form
  await user.click(submitBtn);
    
  // Focus moves to first invalid field
  expect(emailInput).toHaveFocus();
});

Other use cases where focus management assertions are important include testing that the focus returns to the appropriate elements after dialogs close or actions complete.

Tip: As part of our development process, we use our keyboards to navigate through the UI. Did the Tab jump to the control we expected? Did we expect the Escape key to close a dialog? After submitting an invalid form, is the focus on the first invalid input? Not using a mouse and manually testing these scenarios with a keyboard helps guide the assertions we include in the tests.

Test file organization

As our test suite grew, we started organizing test files by feature or concern. This helped avoid monolithic Component.test.ts files with hundreds of tests. Here are the common test file categories we saw occur organically:

Interaction tests: ComponentName.interactions.test.ts

Tests included assertions for user interactions, click handlers, keyboard navigation, and UI state changes in response to user actions.

Event tests: ComponentName.events.test.ts

Tests included assertions for custom event emissions, event bubbling, and event payloads.

Rendering tests: ComponentName.rendering.test.ts

Tests included assertions for initial render, conditional rendering, and DOM structure.

Feature-specific tests: ComponentName.feature.test.ts

For specific features, we named test files after the feature:

• ComponentName.hidden-inputs.test.ts
• ComponentName.sorting.test.ts
• ComponentName.validation.test.ts

Directory structure patterns

We preferred to collocate the test files next to the component or feature. This kept the test suite maintainable, discoverable, and faster to run. We found it easier to find and run tests for specific features.

Pattern 1: Tests alongside component

For simpler components:

ComponentName/
├── _component-name.css
├── ComponentName.ts
├── ComponentName.stories.ts
├── ComponentName.interactions.test.ts
├── ComponentName.rendering.test.ts
└── ComponentName.events.test.ts

Pattern 2: Feature sub-directories with tests

For complex features that warrant their own folder:

ComponentName/
├── _component-name.css
├── ComponentName.ts
├── ComponentName.stories.ts
├── validation/
│   ├── use-validation.ts
│   ├── ComponentName.validation.test.ts
│   ├── ComponentName.validation.initial-render.test.ts
│   └── ComponentName.validation.attribute-changes.test.ts
├── single-select/
│   ├── component-name-single-select-example.ts // The `html` template for tests
│   └── ComponentName.single-select.test.ts
├── multi-select/
│   ├── component-name-multi-select-example.ts // The `html` template for tests
│   └── ComponentName.multi-select.test.ts
└── pre-select/
    ├── use-pre-select.ts
    ├── use-pre-select.test.ts
    └── use-pre-select.object-support.test.ts

Pattern 3: Helper/utility tests

Tests for pure functions and utilities:

MyTreeComponent/
├── _my-tree-component.css
├── MyTreeComponent.ts
├── MyTreeComponent.interactions.test.ts
├── MyTreeComponent.events.test.ts
└── helpers/
    ├── flatten-tree.ts
    ├── flatten-tree.test.ts
    ├── generate-node-id.ts
    ├── generate-node-id.test.ts
    ├── set-tree-ids.ts
    └── set-tree-ids.test.ts

Using a for/of loop to run repetitive test assertions

This pattern isn’t groundbreaking, but there were times when we used an array of input names and a for/of loop to run the same assertions against multiple inputs.

For example, without a loop:

const dataTable = document.querySelector('data-table') as DataTable;

expect(within(dataTable).getAllByRole('checkbox')).toHaveLength(6);

const selectAllCheckbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select all' }
);
expect(selectAllCheckbox).toBeVisible();
expect(selectAllCheckbox).toBeChecked();

const entity01Checkbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select Entity_01' }
);
expect(entity01Checkbox).toBeVisible();
expect(entity01Checkbox).toBeChecked();

const entity02Checkbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select Entity_02' }
);
expect(entity02Checkbox).toBeVisible();
expect(entity02Checkbox).toBeChecked();

const entity03Checkbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select Entity_03' }
);
expect(entity03Checkbox).toBeVisible();
expect(entity03Checkbox).toBeChecked();

const entity04Checkbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select Entity_04' }
);
expect(entity04Checkbox).toBeVisible();
expect(entity04Checkbox).toBeChecked();

const entity05Checkbox = within(dataTable).getByRole(
	'checkbox', 
	{ name: 'Select Entity_05' }
);
expect(entity05Checkbox).toBeVisible();
expect(entity05Checkbox).toBeChecked();

Using a for/of loop:

const checkboxNames = [
	'Select all',
	'Select Entity_01',
	'Select Entity_02',
	'Select Entity_03',
	'Select Entity_04',
	'Select Entity_05',
];
const dataTable = document.querySelector('data-table') as DataTable;

expect(within(dataTable).getAllByRole('checkbox')).toHaveLength(
	checkboxNames.length,
);
for (const name of checkboxNames) {
	const checkbox = within(dataTable).getByRole('checkbox', { name });
	expect(checkbox).toBeVisible();
	expect(checkbox).toBeChecked();
}

Using the for/of loop felt cleaner and was easier to maintain.

Thinking critically about clicking various controls at once

This is less a pattern and more a reminder for our future selves to not just accept all ESLint rules without critical thinking.

Initially, we did the following:

// Expand each of the root nodes.
const tools = screen.getAllByRole('group', { name: /^tool\\\\./i });
for (const tool of tools) {
	await user.click(tool);
}

// Expand each of the second-level nodes.
const services = screen.getAllByRole('group', { name: /^service\\\\./i });
for (const service of services) {
	await user.click(service);
}

However, the no-await-in-loop ESLint rule flagged the await within the for/of loop. Technically, the rule is correct:

Performing an operation on each element of an iterable is a common task. However, performing an await as part of each operation may indicate that the program is not taking full advantage of the parallelization benefits of async/await.

Often, the code can be refactored to create all the promises at once, then get access to the results using Promise.all() (or one of the other promise concurrency methods). Otherwise, each successive operation will not start until the previous one has completed.

The ESLint rule suggested the following:

// Expand each of the root nodes.
const tools = screen.getAllByRole('group', { name: /^tool\\\\./i });
await Promise.all(tools.map((tool) => user.click(tool)));

// Expand each of the second-level nodes.
const services = screen.getAllByRole('group', { name: /^service\\\\./i });
await Promise.all(services.map((service) => user.click(service)));

That makes sense. However, for our use case, we want each successive operation to wait until the previous one has completed. Imagine a user clicking various UI controls. The user will not be clicking all of them at once, it’d be impossible! Instead, the user would click the controls one by one. Our tests should match how a user will interact with our UI. Additionally, if the DOM updates after each click, a race condition may occur, potentially making the test flaky.

We ended up turning off the no-await-in-loop rule in each of those lines with a comment to help explain why we disabled the ESLint rule:

// Expand each of the root nodes.
const tools = screen.getAllByRole('group', { name: /^tool\\\\./i });
for (const tool of tools) {
	// We want to run the clicks sequentially to avoid UI race conditions.
	// Additionally, this closer aligns with how a real user would interact with the UI.
	// eslint-disable-next-line no-await-in-loop
	await user.click(tool);
}

// Expand each of the second-level nodes.
const services = screen.getAllByRole('group', { name: /^service\\\\./i });
for (const checkbox of individualCheckboxes) {
	// We want to run the clicks sequentially to avoid UI race conditions.
	// Additionally, this closer aligns with how a real user would interact with the UI.
	// eslint-disable-next-line no-await-in-loop
	await user.click(checkbox);
}

Avoid leaking state between tests

An important detail I want to highlight in particular: We need to reset the document body after each test run to avoid leaking state. In our case, we set this up globally in our vitest-setup.ts config file using the Vitest afterEach() teardown function. That way, we wouldn’t have to worry about manually adding this in each test or accidentally forgetting:

// vitest-setup.ts

/**
 * We are using Lit's `render` and `html` functions to render in the tests.
 * We need to reset the document body after each test to avoid leaking state.
 */
afterEach(() => {
  render(html``, document.body);
});

Adding basic dialog functionality to jsdom

Our tests used jsdom. There is an open jsdom HTMLDialogElement issue that remains unresolved. We ended up mocking the HTMLDialogElement show(), showModal(), and close() methods in the vitest-setup.ts file as follows:

// vitest-setup.ts

// Add basic dialog functionality to jsdom
// @see https://github.com/jsdom/jsdom/issues/3294
HTMLDialogElement.prototype.show = vi.fn(function mock(
  this: HTMLDialogElement,
) {
  this.open = true;
});
HTMLDialogElement.prototype.showModal = vi.fn(function mock(
  this: HTMLDialogElement,
) {
  this.open = true;
});
HTMLDialogElement.prototype.close = vi.fn(function mock(
  this: HTMLDialogElement,
) {
  this.open = false;
});

This workaround allowed us to keep moving forward with any tests that included HTML dialog element assertions.

Wrapping up

At the beginning of the project, I was feeling a bit nervous because I wasn’t sure how easy it would be to test HTML web components. Choosing to build Light DOM web components was absolutely the right choice, and once we got rolling, it made testing HTML web components no different from testing framework-specific components. I’m elated to have gone through this experience, and I must say, I love me some HTML web components. ❤️

More resources

• Testing Library has accessibility-focused helper functions that can help debug tests
• Testing Library’s queries order of priority list is a handy reference for building more accessible user interfaces
• Common mistakes with React Testing Library by Kent C. Dodds (Even though it mentions React, all of the guidelines still apply for non-React projects)
• Light-DOM-Only Web Components are Sweet by Chris Coyier
• Come to the light side: HTML Web Components by Chris Ferdinandi (11ty Conf 2024 video)
• HTML Web Components by Jeremy Keith

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

In this episode we sit down with Tyler Sticka to discuss upgrading his project, Colorpeek. We explore the practical applications of web components and CSS, and how they are shaping the future of web development. Tyler shares his experiences with prototyping and the challenges of maintaining simplicity in design.

You can listen right now wherever you subscribe to podcasts, or in video form on YouTube:

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

In a business context, design system work means numbers go down. Less bug reports, faster design iteration, shorter development cycles, fewer visual inconsistencies, smaller staffing requirements that enable folks to work on more interesting challenges, etc. All good things.

Unfortunately, contemporary business practices only reward numbers going up. There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.

This is an interesting discussion because it’s hard to quantify what’s good work when it comes to design systems. For example, when I was on a team like that I would struggle to make the case for refactoring tons of janky and confusing CSS.

Ultimately I felt like I was good at the systems part—I could tell when there were too many similar components or when we should refactor something—but I was really, really bad at the storytelling part of design systems. And that kind of work is really more story than systems: explaining to folks up the chain why this seemingly insignificant series of tasks is an investment in the future. Or why this one tiny detail is worthy of our care today so we don’t have to worry about it later.

“Ouch! WTF was that Coco?”

It was Easter morning. I was bent over wiping Sophie’s feet. Sophie is my mom’s one-year-old cocker spaniel. We were dog sitting, and Coco, our husky pitbull mutt, was thrilled. In her excitement, Coco whipped around and headbutted me.

I yelled loud enough that our oldest came running to see what happened. I told them I was fine. I’d have a lump on my head or a black eye, but I was okay.

Or I so thought until the world started spinning. I sat down on the couch in hopes things would stabilize. I tried to look at my phone to figure out if I could take Tylenol or Ibuprofen. The screen was blurry and made me feel sick.

At urgent care later, the doctor confirmed what we already suspected. Coco had given me a concussion.

A dark room with no screens

The doctor’s prescription was simple. Give your brain a rest from all stimulus for three to four days. Assuming your concussion isn’t dangerous—and mine wasn’t—that means stay in a dark room with no screens.

While I lay in bed with blackout curtains closed and a mask over my eyes, I learned to appreciate some features of our HomePod Mini that I had never used before:

• If I asked Siri to text someone, the HomePod would ping when they replied and I could ask to have the message read aloud.
• Siri could call someone through the HomePod speaker.

These aren’t earth-shattering features, but they helped me feel connected when I couldn’t use screens or ear buds.

My new favorite accessibility features

When I felt well enough to try working again, I found it necessary to make several changes to my computer.

Reduce motion is your friend

Animation and motion would cause pain in my temple. This persisted for weeks after the concussion. I once had to leave a local meetup early because the presenter used animated gifs in their presentation, and it triggered concussion symptoms.

I have since returned to normal motion on my iPhone, but I still have reduced motion set on my desktop machine. Too much movement on a larger screen can still be overwhelming. I’ve also turned off auto-play of animated images wherever possible.

Dark mode isn’t only a fad

I’ll admit that I’ve been pretty dismissive of dark mode. I thought it was something developers came up with because they like working in the dark.

But even though dark mode isn’t included in accessibility settings, I now think of it as one. Bright lights were too much for me and dark mode helped. It has moved up my priority list for the next version of our own site.

As an aside, Gmail has a dark theme, but it doesn’t turn on automatically when someone has prefers-color-scheme set to dark. That seems silly to me. The hard part is developing a dark version of your app or site. Once you have one, don’t make people search around for it.

You can use Night Shift mode during the day

Apple’s Night Shift mode shifts the color of a display to be warmer in the evening because “studies have shown that exposure to bright blue light in the evening can affect your circadian rhythms and make it harder to fall asleep.”

The slightly warmer colors in Night Mode were easier for my brain to process after the concussion. I left it on all the time.

Accessibility is for everyone

My concussion gave me a greater appreciation for the accessibility features that operating systems and browsers have built. If you worked on those features, I want to thank you for everything you do. If you built your website to honor prefers-reduced-motion and dark mode, I want you to know that your work made a difference to me.

It’s a misnomer to think that accessibility is only for people with permanent conditions. I like the way Maria Town, president of the American Association of People with Disabilities, talked about this reality in an interview with Advocate magazine:

Everyone will become disabled if they’re lucky enough. Aging is a privilege. Far too few of us get the opportunity to live to be a ripe old age. And if you do get the opportunity, you will likely become disabled.

This is our reality. Whether it is a temporary injury, a permanent condition, old age, or a literal boneheaded dog giving you a concussion, you will need accessibility features at some point in your life.

So let’s recommit to supporting accessibility in our own work not only to support those who need it now, but also because it is in our own self-interest. You never know when you may suddenly find yourself needing accessibility features.

P.S. Coco was fine. She has a hard head.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I’m not the first one to land here, of course; the likes of Karen Hao, Alex Hanna, Emily Bender, and more have been on this beat longer than I have. And just to be clear, describing “AI” as a failure doesn’t mean it doesn’t have useful, individual applications; it’s possible you’re already thinking of some that matter to you. But I think it’s important to see those as exceptions to the technology’s overwhelming bias toward failure. In fact, I think describing the technology as a thing that has failed can be helpful in elevating what does actually work about it. Heck, maybe it’ll even help us build a better alternative to it.¹

In other words, approaching “AI” as failure opens up some really useful lines of thinking and criticism. I want to spend more time with them.

Right, so: why do I think it’s a failure? Well, there are a few reasons.

The first is that as a product class, “AI” is a failed technology. I don’t think it’s controversial to suggest that LLMs haven’t measured up to any of the lofty promises made by their vendors. But in more concrete terms, consumers dislike “AI” when it shows up in products, and it makes them actively mistrust the brands that employ it. In other words, we’re some three years into the hype cycle, and LLMs haven’t met any markers of success we’d apply to, well, literally any other technology.

This failure can’t be separated from the staggering social, cultural, and ecological costs associated with simply using these services: the environmental harms baked into these platforms; the violent disregard for copyright that brought them into being; the real-world deaths they’ve potentially caused; the workforce of underpaid and traumatized contractors that are quite literally building these platforms; and many, many more. I mention these costs because this isn’t a case of a well-built technology failing to find its market. As a force for devastation and harm, “AI” is a wild success; but as a viable product it is, again, a failure.

And yet despite all of this, “AI” feels like it’s just, like, everywhere. Consumers may not like or even trust “AI” features, but that hasn’t stopped product companies from shipping them. Corporations are constantly launching new LLM initiatives, often simply because of “the risk of falling behind” their competitors. What’s more, according to a recent MIT report, very nearly all corporate “AI” pilots fail.

I want to suggest that the ubiquity of LLMs is another sign of the technology’s failure. It is not succeeding on its own merits; rather, it’s being propped up by terrifying amounts of investment capital, not to mention a recent glut of government contracts.² Without that fiscal support, I very much doubt LLMs would even exist at the scale they currently do.

So. The technology doesn’t deliver consistent results, much less desirable ones; what’s more, it extracts terrible costs to not reliably produce anything of value. It is fundamentally a failure. And yet, private companies and public institutions alike keep adopting it. Why is that?

From where I sit, the most consistent application of LLMs at work has been through top-down corporate mandate: a company’s leadership will suggest, urge, or outright require employees to incorporate “AI” in their work. Zapier’s post on its “AI-first” mandate is one recent example. At some point, the company decided to mandate “AI” usage across their organization, joining such august brands as Shopify, Duolingo, and Taco Bell. But in this post from the summer, Zapier’s global head of talent talks about how the company’s expanding the size and scope of that initial mandate. Here’s the intro:

Recently, we shared our AI adoption playbook, which showed that 89% of the Zapier team is already using AI in their daily work. But to make AI transformation truly sustainable, we have to start at the beginning: how we hire and onboard people into Zapier to build this future with us.

I’ve written before about the problems with “adoption” as a success metric: that “usage of a thing” doesn’t communicate anything about the quality of that usage, or about the health of the system overall. But despite that, Zapier’s moved beyond mandated adoption, and has begun changing its hiring and onboarding practices — including how it evaluates employee performance. How does an “AI” mandate show up in a performance review? I’m so glad you asked:

Starting immediately, all new Zapier hires are expected to meet a minimum standard for AI fluency. That doesn’t mean deep technical expertise in every case — but it does mean showing a mindset of curiosity toward AI, a demonstrated willingness to experiment with it, and an ability to think strategically about how AI can amplify their work.

[…]

We map skills across four levels, keeping in mind that AI skills vary and are heavily role-specific.

• Unacceptable: Resistant to AI tools and skeptical of their value
• Capable: Using the most popular tools, with likely under three months of hands-on experience
• Adoptive: Embedding AI in personal workflows, tuning prompts, chaining models, and automating tasks to boost efficiency
• Transformative: Uses AI not just as a tool but to rethink strategy and deliver user-facing value that wasn’t possible a couple years ago

There’s an insidious thing nestled in here.

Andy Bell and Brian Merchant have both documented tech workers’ reactions to “AI” mandates: what it feels like to have parts of your job outsourced to automation, and how it changes what it feels like to show up for work. I’d recommend reading both posts in full; it’s possible you’ll see something of your own feelings mirrored in those testimonials. And those stories track with my own conversations with tech workers, who’ve shared how difficult it is to talk openly about their concerns at work. I’ve heard repeatedly about a kind of stifling social pressure: an implicit, unstated expectation that “AI” has to be seen as good and useful; pointing out limitations or raising questions feels difficult, if not dangerous.

But this Zapier post is the first example I’ve seen of a company making that implicit expectation into an explicit one. Here, the official policy is that attitude toward a technology should be used as a quantifiable measurement of how well a person aligns with the company’s goals: what the industry has historically (and euphemistically) referred to as culture fit. At this company, you could receive a negative performance review for being perceived as “resistant” or “skeptical” of LLMs. You’d be labeled as unacceptable.

I mean, look: on the face of it, that’s absurd. That is absurd behavior. Imagine screening prospective hires by asking their opinions about your company’s hosting provider, or evaluating employees for how they feel about Microsoft Teams. Just to be clear, I fully believe evaluations like these have happened in the industry — hiring and performance reviews are both riddled with bias, especially in tech. But this is the first time I’ve seen a company policy explicitly state that acceptance of “AI” is a matter of cultural compliance. That you’re either on board with “artificial intelligence,” or you’re not one of us.

This is where I think approaching “AI” as a failure becomes useful, even vital. It underscores that the technology’s real value isn’t improving productivity, or even in improving products. Rather, it’s a social mechanism employed to ensure compliance in the workplace, and to weaken worker power. Stories like the one at Zapier are becoming more common, where executive fiat is being used to force employees to use a technology that could deskill them, and make them more replaceable. Arguably, this is the one use case where “artificial intelligence” has delivered some measure of consistent, provable results.

But here’s the thing: this is a success only if tech workers allow it to be. I’m convinced we can turn this into a failure, too. And we do that by getting organized.

 — okay, yes, I know. I am the person who thinks you deserve a union. But it’s not just me: from game studios to newsrooms, many workers are unionizing specifically because they want contractual protections from “artificial intelligence.” Heck, the twin strikes in Hollywood weren’t about banning “AI,” but giving workers control over how and when the technology was employed. I think at minimum, we deserve that level of control over our work.

With all that said, you don’t have to be unionized to start organizing: to have conversations with your coworkers, to share how you’re feeling about these changes at work, and start talking about what you’d like to do about those changes, together. It really is that simple.

That isn’t to say organizing is easy, mind. It involves having many, many conversations with your coworkers, and looking for shared concerns about issues in the workplace. And, look: I’m writing this post at a time where the labor market’s tight, when there’s so much pressure to not just adopt LLMs but to accept them unquestioningly. In that context, I realize that inviting coworkers to share some thoughts about automation can feel difficult, if not dangerous. But it’s only by organizing — by talking and listening to each other, and acting together in solidarity — do we have a chance at building a better, safer version of the tech industry.

“Artificial intelligence” is a failure. Let’s you and I make sure it stays that way.

This has been “Against the protection of stocking frames.” a post from Ethan’s journal.

Reply via email

This hotel, though. Let me tell you about it.

It’s new, first of all. Even if you’re driving through the area for the first time, you’ll be able to spot “new construction” as something that sticks out. What’s more, this huge hotel’s been dropped on top of a mountain that’s too tiny for it. This isn’t one of the hot tourist destinations, either; this mountain’s home to a humble little ski resort, one that’s always been overshadowed by more popular tourist destinations, all of them a short drive away. Now, I need to stress here that I’m no skier — I did a single season on my high school cross-country skiing team that we will not be discussing — but I do know this resort’s historically drawn most of its customers from nearby towns: they’re not pulling in the wealthy out-of-staters. And to look at this new, massive, shiny hotel, that’s who you’d think they’re attracting.

How’d it get here? Well, we need to back up a decade or two to answer that. Because as it happens, some investor types decided to defraud the federal government.

They didn’t lead with that, of course. Through a visa program for affluent foreign investors, they had access to a tremendous amount of capital, which they then used to acquire local tourist spots and dramatically overdevelop them. As they did, they promised that all this investment would bring an influx of new businesses, which would mean more people moving to a state starved for both residents and revenue.

As you might have guessed, the money disappeared when these investors got arrested. One visible aftershock was the halted construction projects. In one town up north, there’s a crater the size of a literal city block, because all the new construction these investors promised — a slew of shops and offices, a new hotel — disappeared when they did. The investors are gone; the hole isn’t.

It also left some massive, sprawling properties in communities that never had enough foot traffic to properly support them. And here we are, back at this gigantic hotel. When we walk in, we see that the gift shop right off the lobby has been hastily boarded up. One wing of the hotel’s been blocked off to guests. At the check-in desk, the clerk has three registration forms lined up in front of her, one for each of the guests she knows will be checking in that evening. All because some rich, powerful men promised my chronically impoverished corner of the state that the things it had always and desperately needed — investment, jobs, and people — were, at long, long last, finally about to arrive.

“Artificial intelligence is here to stay. It’s not going anywhere.” I’ve heard some variation on that line many, many times since 2022; I heard it a few more times after defining “artificial intelligence” as a failed technology. Maybe you’ve heard it too.

Now, regardless of how you or I might feel about “AI,” I think we can both acknowledge just how impressively ahistorical that statement is. In the last two decades, I’ve seen so many things we knew were our future: Internet Explorer, Flash, Web 2.0, jQuery, mobile websites, NFTs¹, and more. We were told each and every single one of them was immutable, fixed, and unchanging; each and every single one of them, in turn, faded. Some of them even disappeared altogether. I’ve been in this industry long enough to know that predicted futures have a pretty short lifespan.

And that’s the moment in which I’m writing: that vision of an “AI” future feels like it’s shaking. In fact, it might be close to shattering. There’s a growing body of reporting on the rampant speculation at the heart of the current boom, with some journalists gaming out what a market crash might look like. Investors are nervous; leaders of “AI” companies are even starting to sound warning bells, presumably to position themselves for government bailouts whenever the bubble finally bursts. In the face of all this instability, stating that “AI isn’t going anywhere” feels even more detached from reality: it’s divorced from how quickly trends shift in tech, and it’s ignoring the growing cracks in the industry’s foundation.

At the same time, I think that unwavering belief is what’s instructive about it.

I mean, look. I’ve been thinking about my future quite a bit. The last decade’s made my sense of the coming decades feel fractured, and the last year has only accelerated that feeling. Friends are aging; family members have passed on; so many things I was taught to rely upon — jobs, industries, institutions, milestones, even seasons — feel like they’re being upended in front of me. When you’re told to expect a certain broad arc to your life, it’s more than a little terrifying when that map’s redrawn as you’re looking at it.

That’s why I’ve come to realize that statements about the future aren’t predictions: they’re more like spells. When someone describes something to you as the future, they’re sharing a heartfelt belief that this something will be part of whatever comes next. “Artificial intelligence isn’t going anywhere” quite literally involves casting a technology forward into time. How could that be anything else but a kind of magic?

Now. By calling them magical, I’m not attempting to diminish or disparage these kinds of statements. Far from it: when we make these statements, we’re opening up a kind of possibility space. “What if the future looked like this?” By making space to ask questions, we’re making the future feel less fixed, and far less daunting. It gives us an anchor point in what comes next, one we can move toward with intention. On an individual level, incantations like these can be a helpful goal-setting exercise; performed at scale, they can be transformative.

And not necessarily in a good way. Take the “AI” industry: backed by their belief in their (again, failed) technology and a ghastly amount of capital, they’ve embedded their technology in products, organizations, and governments alike. They’ve begun physical buildouts of vast data centers that take a tremendous toll on disenfranchised communities, and are demanding older, even more dangerous forms of energy to support their expansion. They’ve created new classes of invisible workers to power their operations, all while selling automation technology that makes work even more precarious for everyone else. This is all to say that they’ve moved very, very, very quickly to realize their vision for the future in the last three years. Hell, it’s hard to imagine a future without these platforms, and the powerful people who sell them.

But to paraphrase something Mandy Brown once said, there’s not going to be one future — there will be many. In fact, there’s another future being built right now.

Last fall, the workers at the New York Times Tech Guild walked off the job for a week and subsequently won their first union contract, one that improved pay, won them “just cause” protections, and more. For the last several months, workers at Microsoft have waged an effective and relentless pressure campaign against their employer, in order to force the tech giant to stop selling technology that facilitates the genocide in Gaza. Last week, the workers at Kickstarter United ended their record-breaking strike, having walked off the job for forty-two days to secure improved pay equity, a contractually guaranteed four-day work week, and job protections from “AI”. This week, the workers at Starbucks United, who began a strike just last week, established a blockade at one of the corporation’s distribution centers — all to bring management back to the table after months of stalled negotiations.

These are just four examples from the last year; there are many, many more. We’re surrounded by a tremendous amount of organizing right now, with workers banding together to build protections at work, to win improved pay and benefits, to advocate for human rights, to build power together. That organizing’s happening at a scale I find tremendously inspiring, and at a pace — last year; this year; last week; this week — that’s steadily increasing. This is a new future, one being built by quiet conversations with coworkers, by petitions circulated at work, by bargaining sessions, by chants and songs and protests and strikes.

That’s not to say this future is any more assured than the other one: this worker-led future needs significantly more people, including you and your coworkers. But that aside, I’m struck by the contrast between the two. One vision for the future mentions technology and technology alone, neatly eliding right over who might be impacted or harmed if that future should come to pass; the other future is centered around humans, their needs, and their hopes for something better.

Me, I’ve decided which future I want to live in. When I wrote my last book, I said the future of the tech industry is an organized, worker-led labor movement. That’s the quiet hope I’m casting into the months and years and decades that are stretching before me.

Maybe you agree with that future. If you do, well — let’s you and I start moving toward it.

This has been “The line and the stream.” a post from Ethan’s journal.

Reply via email

My favorite keyboard is the Microsoft Ergonomic Keyboard. But Microsoft is out of the keyboard hardware game. So apparently they sold the design to Incase, who now continues to sell it at a perfectly fair price.

It turns out they recently launched a new one, but some folks don’t love it. As an artist, it’s not my job to critique other art, but instead to offer my own compelling vision for the web.

I shouldn’t have to explain why I went with the classic dark blue and asparagus colors—that much is obvious. And of course, turning c into a file extension as a reminder that NCSA Mosaic was written in C (I didn’t go with WorldWideWeb because that was written in Objective C and .m kinda messes it all up).

If I’m in the mood for something lighter, I can just look into my “Fun” folder to check out new stuff from The Oatmeal or xkcd. If I feel like reading something more thoughtful, I’d dive into my “Reads” folder for The Marginalian or Sentiers. Feeling like catching up on the newest AI research? I can browse the latest research papers from arXiv that have specific keywords in the abstracts (such as prompt injection). Or I could just browse everything at once to see what piques my interest. I am the master of what information I consume, how and in what order, and no one can take that away from me by rearranging my feed or tweaking the algorithm.

What I had been doing

1. Automatically syncing my Reader by Readwise highlights into Obsidian
2. Going through the new articles manually and adding them to my blog post Markdown (also written in Obsidian)

Obsidian enables you to customize to the nth degree, so I figured there was a better way to do this but hadn’t made it a priority. Dave’s post showed me I could do this pretty quickly!

Enter Dataview plugin

I’d already installed the Dataview plugin for Obsidian for one reason or another and ended up writing a DQL query very similar to Dave’s:

LIST map(rows, (r) => elink(regexreplace(r.file.frontmatter.url, "\\?utm_.*", ""), r.title))
FROM "Resources/Readwise/Articles"
WHERE file.frontmatter.highlightedDate >= "2025-08-01"
	AND file.frontmatter.highlightedDate < "2025-09-01"
	AND file.frontmatter.url
FLATTEN file.tags AS tag
GROUP BY tag
SORT file.frontmatter.highlightedDate DESC

What this query does is:

• Pull all the articles I highlighted in a given month from the directory where I’ve synced my Readwise articles. It filters out any articles that don’t have a URL in the frontmatter, i.e. email newsletters.
• Group the linked article titles by the tag I applied in Reader.

I copy and paste this query into my blog post draft, update the tag groupings to be headers, and hand-curate the list a little further. I could use Dataview JS to structure this in a fancier way and skip some of this manual bit, but I find it’s worth slowing down at this curation stage.

You’ll notice I do have dates hardcoded in here as well. As we all know, the hardest problems in computer science are:

• People problems
• Naming things
• Wrangling dates

I kept getting weird errors and issues with data handling, so decided to just throw up my hands and enter the dates manually. I only have to update them once a month, and so this XKCD comic seemed apt.

In any case, this was a nice little quality of life update for my blogging process, and I’m now playing with all things Dataview in my Obsidian notes!

Since we adopted Jessie in 2017, I've been celebrating her adoption aniversary on social media instead of this blog. And it bit me in the arse. I used to have a lovely thread going on for years on Twitter but, of course, I haven't touched that hell space in a very long time. I was lazy and now I am paying the price. For this year's anniversary I still posted on BlueSky and Mastodon but, I want to make sure that memory is captured here too.

Sweet Jessie has been with us for eight years now and, fun fact, she is about to turn 14! She was five years old when we adopted her. It's been a priviledge that the majority of her life has now been with us.

Since living with us she has:

• lived in three different homes;
• brought a mouse in only once (and it was a baby so it doesn't count);
• went missing once (the worst);
• has had dentist appointments and teeth removed;
• became a big sister to an human;

I really hope I have many more years of posts to make. 💗

Why build a website?

Why knit a jumper with your bare hands?

Why cook a homemade meal from scratch?

Why paint in a canvas?

Why fix a broken thing?

Why write a letter?

Why anything really?

We, humans, are driven to touch and craft with our body. Deep down we crave that. Website making is a digital craft.

There, I let out a draft from my phone and it is now in my blog. Why not?

Anyway, I love how the "no thought is original" is real. Turns out, one day before I started this draft on my blog, Jim Nielsen also did a similar comparison. They're smarter than me, listen to them!

A small sample of UI, code, tools, and design from my 20 professional years of webdev.

Ep #212
TalkShop Show w/ Macho Man Randy Standards

Robbie and I chat with Dave Rupert about whiskey, web culture, the quirks of building side projects, the shifting landscape of the web, AI-driven development, spec-driven workflows, RSS’s decline, and more.

⤷ whiskey.fm · youtube · spotify · apple

Quick post on closedBy="any", a declarative way to add light-dismiss to a dialog:

<dialog closedBy="any">
  <p>Hi, I'm a dialog.</p>
</dialog>

And just like that, tapping or clicking outside the dialog will close it.

Oh yeah! Well I bet I can't use it yet. #

Here's the browser support:

Or a bit-o-js to get you started:

someDialog.addEventListener('click', ({target:dialog}) => {
  if (dialog.nodeName === 'DIALOG')
    dialog.close('dismiss')
})

More resources #

You should write one!

I'm writing this because I haven't seen enough folks using it or talking about it. Pretty nifty feature if ya ask me. So I'll make a 10m post.

If you want more <dialog> goodness, I wrote a fun post about how to make nice dialogs cuz the defaults are so poopy. Check it out and have a dialog.

Design tokens may be the latest incarnation, but software creators have been creating themeable user interfaces for quite a long time! As with all things, we can study history to learn from our past to inform our future. So let’s dig in!

1970s: The first commercial GUIs

The history of the graphical user interface (GUI) is fascinating and naturally involved a lot of research, iteration, and development before being unleashed upon the world. The first commercial computer featuring a GUI was the Xerox Alto in 1973. Behold it in all its glory:

GUIs ultimately hit the market in 1981 in the form of the Xerox Star. The Star was similar to bands like CAN and Fugazi in that sense that it wasn’t a commercial hit, but was massively influential to everything that followed.

The 70s also saw the rise of video games, especially with the runaway success of Pong. Galaxian by Atari was released in 1979 and was the first successful game that made use of a full-color RGB display.

Game & computer designers were contending with extremely limited processing/memory resources, so they were forced to get extremely creative in order to support full-color screens. Sprites were used to manage the graphics and different states for UI elements, and color themes cleverly transformed the same shapes into different characters. Themed UI elements!

1980s: Color, games, and the PC age

The 1980s ushered in an era of full-color displays, which opened many new opportunities and challenges for designers. Just look at this glorious sprite showcasing from Nintendo’s 1985 era-defining video game, Super Mario Brothers:

It’s wild that two of the most iconic characters in the history of pop culture — red-clad Mario and green-clad Luigi — are themeable UI elements born from pragmatic ingenuity to overcome technological challenges. Freaking amazing.

This ingenious sprite theming is a masterclass in creative constraints. One thing you absolutely can’t unsee once you know is learning that the clouds and the bushes in Super Mario Bros are the exact same shape, just themed differently!

To put a finer point on this: the creators established the game’s structure and functionality and understood that duplicating all of that structure & functionality merely to achieve different aesthetic results would be wasteful, expensive, and imprudent. So instead they created a themeable design system to achieve this critical separation of concerns between structure/functionality & aesthetics. Incredible!

The PC Era

Naturally, full-color displays found their way into personal computer operating systems in the 1980s. Several full-color computers hit the market in the mid-80s, and the iconic Apple II released its first full-color display in 1987.

1990s: OS-level theming, The Web, and CSS

Microsoft introduced color schemes with the release of Windows 3.1 in 1992. Users (including a young me!) could go into their preferences, choose a theme for the Windows UI, and even customize the colors. Easily the best theme was named “Hotdog Stand“:

This was one of the most sophisticated, large-scale theming implementations that truly introduced the concept of real user preference and customization to the masses. This UI customization and themeability became even more robust with the release of Windows 95.

These new operating systems unlocked new opportunities for software like Winamp to give users the ability to create their own music player skins, truly putting the “personal” in “personal computer.”

Of course, the World Wide Web also exploded onto the scene in the 1990s. 1993 saw the release of Mosaic, the world’s first commercial internet browser, but it was really the introduction of Netscape Navigator in late 1994 that made the web an absolute phenomenon.

The browser opened a portal into a million worlds, with each website providing its own unique user experience and interface. It was during this era that I found myself with my best friend making Dragonball Z fan websites on Geocities. I’ve been in love ever since.

Note: check out the brilliantly-curated and thoughtful Web Design Museum for more web history!

Accomplishing custom designs in the early web relied on hard coding styling information into the HTML using elements like <font> tag. Thankfully, CSS hit the scene in late 1996, which provided a dedicated language for styling and revolutionized how we create for the web.

2000s: The Web Grows and Native Hits The Scene

The web continued to take off and the technologies to create it continued to improve. Books like Jeffrey Zeldman‘s Designing with Web Standards and CSS books by pioneers like Molly Holzschlag and Eric Meyer helped the world’s emerging web community create beautiful and expressive web experiences.

In 2003, Dave Shea created the CSS Zen Garden, which beautifully demonstrated the concept of separation of concerns as it applies to the languages of the web.

Using the exact same HTML file, designers could use CSS to design radically different aesthetics. For me and countless others, the CSS Zen Garden drove home the importance of the separation of concerns and unlocked the real creative potential for the web as a design medium.

The web field marched into the Web 2.0 era bursting with creative expression, which was put on full display on websites like MySpace.

This customization started entering into more functional software, like then-new tools like Google Personalized Homepages (later renamed iGoogle).

Up until this point, authoring CSS to achieve sophisticated theming was extremely laborious, hard-coded, and fraught. Adding to the complexity was that the whole industry was thrust into a brand-new mobile era as soon as Steve Jobs muttered “and one more thing…” in 2007.

2010s: Sass, Design Systems, Design Tokens

CSS pre-processors like Sass and Less hit the scene in the mid-2000s, and Sass 2.0 introduced this wild little idea called variables in 2010. This was embraced by designers and developers who finally had a DRY way of defining a design language.

$primary-color: #3498db;

button {
  background-color: $primary-color;
}

This unlocked new opportunities for themeability and more dynamic styling on the web. These new capabilities coincided with the emergence of responsive web design, modular CSS methodologies like OOCSS, SMACSS, BEM, and others. In May of 2013 I introduced a thing called Atomic Design. A few months later, React was introduced. The zeitgeist was flexibility, modularity, and component-driven design/dev, which ultimately coalesced under the label “design systems.”

Design systems like Google’s Material Design emerged in 2014-2015 and had themeability in mind right out of the gate.

These design systems demonstrated to the world how its possible to deliver a unified design language to multiple products, platforms, and businesses. Holy crap was it ambitious! Still is! In order to support these vast and multifarious product UIs, the concepts, technology, and tooling around theming needed to evolve.

Design tokens origin story

While Sass variables gave designers & developers a great way to define and use a design language, Jina Anne and Jon Levine at Salesforce delivered a talk that gave the concept of these low-level design decisions a more potent name: design tokens.

Design tokens are the sub atoms — the smallest pieces — of the design system. They’re an abstraction of our UI visual design and store style properties as variables.

Jina Anne

There are a number of definitions and explainers about what design tokens are, which can be summarized like this. Design tokens are:

• The smallest (subatomic) elements of a design system
• Design decisions for a design language
• Design properties stored as variables
• Implementation/technology agnostic source of truth that can be converted into any format
• A common language for design used to connect people, disciplines, tools, and systems
• The engine of themeable user interfaces

In the mid 2010, code tools like Theo from Salesforce and Style Dictionary from Amazon emerged to transform implementation-agnostic JSON or YAML token definitions into technology-specific formats like Sass variables, iOS & Android formats, JS objects, and an important new native web technology called CSS custom properties.

CSS custom properties give the web theming superpowers — and to do it live! Seriously, check out this amazing website by Abban Dunne:

There’s a whole lot to design tokens! And a whole lot of opportunity Perhaps that’s why a Design Tokens W3C Community Group was established in 2019 to help wrangle and standardize some of the structure, naming, and architecture around design tokens.

2020s: Multi-All-The-Things, AI, and beyond

Tokens in Figma

Achieving elegant theming in design tools like Adobe Photoshop/Illustrator/XD, Sketch, and Figma has been elusive until very recently. Styles existed in tools like Sketch and Figma, but were insufficient for the level of customization digital orgs had to account for. In 2022, Tokens Studio was released to help bring more sophisticated theming to Figma, and in the summer of 2023, Figma released Figma Variables, a tool-native way to define and wield design tokens. This created the opportunity to design UIs that can more easily support multiple themes. The magic trick is really cool!

The rise of AI and themeability on demand

Of course, at the time of this writing, generative AI exploded onto the scene and is introducing a brand-new paradigm that will influence the world, including how to support themeable user interfaces. These tools are still emerging, but already we’ve found many ways AI tooling can help in the creation and adoption of design token systems (we get into all of it in our course!). It’s also easy to imagine that thes new technologies can help usher in a new era of hyper-personalized user experiences. My user experience may look and behave wildly differently than yours, which introduces all sorts of fascinating opportunities and challenges.

Our Multi-All-The-Things Reality

It’s been a hell of a journey that’s gotten us here, but we are here. We are alive in a moment where we’re responsible for designing and building for a Multi All-The-Things reality.

We have more websites, apps, screens, flows, products, ecosystems, technologies, and paradigms than at any other moment in human history. And it doesn’t show any sign of slowing down anytime soon.

No one can predict the future, but I strongly feel that organizations that have sturdy foundations, infrastructure, and systems in place will be in a better place to navigate whatever the future may bring.

Consider checking out our design tokens course

There’s SO MUCH technology, architecture, tooling, cross-disciplinary collaboration, orchestration, and gold old-fashioned human processes involved in creating robust, successful, and themeable UI systems. Achieving balance in these systems is truly an art form: constrained-yet-expressive, systematic-yet-extensible, considered-yet-customizable.

We’ve devoted the last 12 years of our lives to helping teams establish these systems, and spent 6 months distilling all of these concepts, best practices, hard-earned lessons into a comprehensive online course called Subatomic: The Complete Guide To Design Tokens.

Our course covers everything your team needs to create & maintain a successful themeable design systems at your organization. Order our course and you’ll get:

• Over 13 hours of in-depth video
• Figma & code sample architecture
• Naming & governance workflows
• PDF slides with over 150 resources
• Access to our Slack community
• Certificate of completion
• Free updates

WHEW! I suppose this post is a history lesson slash infomercial for our course. But walking through this history, I’m struck by the fact that my personal journey on this Earth coincides with much of the history of themeable user interfaces. I am so incredibly grateful that I’m on this planet during such a time of technological innovation and convergence between technology, design, and art. I’ve now spent literally half of my life professionally designing cool-looking things for the World Wide Web. And I think that’s pretty badass.

~

~

# The Code

If you are here just for the code, here it is:

@function --light-dark(--l, --d) {
  result: if(color-scheme(dark): var(--d); else: var(--l));
}

Usage is similar to the built-in light-dark(), but difference is that it can be used with any type of value:

#element {
  color-scheme: light dark;
  color: light-dark(#333, #e4e4e4);
  background-image: --light-dark(url(light.svg), url(dark.svg));
}

~

# The color-scheme() function

Powering this custom --light-dark() function is the new color-scheme() function. It’s a new addition to CSS which we only recently resolved on adding with the CSS Working Group.

The color-scheme() function allows you to query the used color scheme of an element. The function can be used in both @container queries and [the new if()](https://developer.chrome.com/blog/if-article).

In the following example I am using the function directly on an element (instead of placing it into a custom function):

#element {
  color-scheme: light dark;
  background-image: if(color-scheme(dark): url(dark.svg); else: url(light.svg));
}

The reason we need this new color-scheme() function is because the color-scheme property only lists which color schemes are supported. When set to light dark, you are indicating the element can adapt its rendering to either a light or dark version. This is controlled by your light/dark setting, with the resulting used value being one of those listed values.

FYI: You can also force a component into a specific mode by listing only 1 value for color-scheme, e.g. color-scheme: light will force the component into light mode, regardless of your OS setting.

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 BlueSky
• 🦣 Mastodon

~

The CSS Podcast is back! Together with Una I’m co-hosting season 5 of the show, and we have some good episodes coming your way! The first episode of the season – episode 092 of the full show – got published and is about CSS if() and CSS Custom Functions (@function).

Welcome back to the new season of the CSS Podcast, where Una and Bramus are your guides, your cohosts, and your CSS best friends.

In this episode we dig into two very powerful new CSS features: inline conditionals with the if() function, and custom functions.

It’s a bit of a bittersweet thing to do, because Una used to run the show together with Adam who got laid off back in April. Thankfully the three of us got to meet in person at CSS Day back in June, where Adam gave us his blessing to continue the show.

The CSS Podcast →
The CSS Podcast Episode 092 – →

~

Unlike the scrollable scroll-state queries, scrolled remembers the last direction you scrolled into, which you can use to build “hidey bars”: when scrolling down (or having scrolled down), the hidey bar hides itself. When then scrolling back up, the hidey bar reveals itself.

Here’s the code that is needed to hide a fixed header when scrolling down:

html {
  container-type: scroll-state;
}

header {
  transition: translate 0.25s;
  translate: 0 0;

  /* Slide header up when last having scrolled towards the bottom */
  @container scroll-state(scrolled: bottom) {
    translate: 0 -100%;
  }
}

~

Below is a live demo using the code above. You can try it out yourself in Chrome Canary with the experimental Web Platform Features Flag enabled. If you browser does not support scrolled scroll-state queries, the header will remain fixed in place – a nice progressive enhancement if you’d ask me 🙂

See the Pen
Hidey Bar Demo (Hide on Scroll Down, Show on Scroll Up // Scroll State Queries) by Bramus (@bramus)
on CodePen.

The feature is expected to ship to Chrome Stable in Chrome 144.

~

~

Paxos, the issuer of PayPal's PYUSD stablecoin, accidentally minted 300 trillion of the supposedly dollar-pegged token. For context, this is approximately 2.5x the global GDP, and around 125x the total number of US dollars actually in circulation.

Paxos later announced that the mint was an "internal technical error", and that they had burned the excess tokens.

While PayPal promises its customers that "Reserves are held 100% in US dollar deposits, US treasuries and cash equivalents – meaning that customer funds are available for 1:1 redemption with Paxos," there clearly isn't much in the way of safeguards to ensure that is always the case. As with most stablecoin issuers, Paxos merely issues self-reported and unreviewed portfolio reports, and monthly third-party attestations (not audits) of reserves.

• Tweet by Whale Alert
• Tweet by Paxos

One of my chefs mentioned that if they could cook the steak on the grill they could get it right the first time. This is not an acceptable attitude in the microwave era. Chefs have fragile egos and they all seem to enjoy cooking (???) so it’s obvious they’re just too attached to the food. Also they’re worried I’m planning on firing all of them. That’s true but not relevant here.

⬣

This is the sort of work I did when I was just starting out with web dev - marketing sites. It’s been 14 years since I worked a gig like this, and I was so struck by how much easier everything is now. 

First of all, the capabilities of CSS are absolutely magical. I needed to do a course to catch up on my knowledge and feel confident again but once I did… putting together layouts is a dream. 

At one point my friend asked if I could change all the places where they had yellow to blue… back in the day this would have been annoying but all I had to do was update a single custom property! I made multiple Netlify Deploy previews for him to look at with different shades of blue and it all took me under 10 minutes.

And because of improvements to CSS and the native platform you need so much less JavaScript to achieve specific layouts and functionality. When you do need JS, you can just use the regular JavaScript API, no need for third party libraries like jQuery or MooTools (lol).

Look, I am old and I am comparing this to the Dark Ages when we were still on CSS 2, but I just can't move past how much better and easier everything is!

At the same time I’m cognisant of the fact this isn’t really a job anymore. My friend had no interest in messing with a Squarespace and was willing to pay my hourly rate to build a static site because he knew he could trust me to do a good job. Most clients probably feel differently, and would prefer to either choose these low or no-code tools to make the websites themselves, or employ devs to build bloated React projects. My own day job is building an incredibly complex Web Application.

What a shame that is, as the technology has never been better for developers to build lean, accessible and attractive websites.

Thanks for reading this post via RSS! Let me know your thoughts by leaving a comment on the original post or send me an email.

A Necropolis layout from last year. I still work on Necropolis here and there, but anytime I start to pick up the thread, to find my way, the job pulls me out again. The struggle of making television has demanded almost all of my time since July 2020.

Getting to make cartoons with so many talented people has been a huge, all-consuming privilege. It’s taken me five years on the job just to get my legs under me, just to begin to feel that I know what I’m doing. It’s taken everything I have just to keep my head above water, to get something resembling our crew’s talent and effort and intention onto the screen. For that entire half-decade I have longed to make comics, to write stories for myself, to draw for myself. But there was always something that needed doing.

Recently I’ve realized that denying that part of myself, telling it to wait its turn through one more script revision, one more review, one more retake, one more episode, one more season–it’s taken a toll that I can no longer afford to pay. I don’t think I can keep going unless I take some time to write and draw and explore outside of the studio production system. As we fight through post on the third season of My Adventures With Superman and start writing the first season of Lantern, I’m looking for ways to work and lead that will get me some of that time back–and my teams are really coming through for me.

But even if I can find that time, I still need to decide how to spend it, and where to put the things I make. I need a place away from the urgency and deadlines and pressure of the studio. Tumblr has always had the best community, is where I’ve always been the most comfortable, so I’m gonna start here. I will cross-post some of what I do here to other, more hellish parts of the internet, but this is going to be home for a while.

I hope that those of you who never left don’t mind me coming back. I hope that those of you who’ve nested here in the meantime don’t mind some new-type Oldtype showing up. I just want a place to be myself, instead of another dusty piece of production equipment.

Thanks,

Jake

Reblogging this here.

A lot of folks on this and other platforms ask if I’m still working on Necropolis. I am (see above), but what started as a short-term, long-shot tv development project has become four seasons of television, now spread across two series and five years of my life.

I have been entirely subsumed by the job. But I’m trying to reconstitute myself.

I haven’t and won’t quit Necropolis, but before I can fully reengage it, I have to find my way back to making things that aren’t studio television. Once that’s done, I need to determine the correct angle of approach for Necropolis, specifically. And all that is just going to take time.

If you still care, thank you so much. Sincerely. I hope I’m able to continue (and eventually finish!) this story while you still do. I really like making this comic for you all. I would really like to see it done.

-Jake

Junior Dev: “My linting is broken, can you help?”
Me: “Sure”
get on a call with junior dev
junior dev runs linting command which ends with lots of “command failed” errors as well as a line that says “17 warnings, 2 errors”
Junior Dev: “See?”
Me: “Scroll up.”
junior dev scrolls up and sees 2 errors that say they forgot an attribute
Junior Dev: “Oh.”

I’ve had other experiences recently as well where a different junior developer also couldn’t tell me what was wrong with something. The error was right in front of them and they just didn’t scroll to the right place. They would click everywhere except for the thing that would tell them where the error was. I recognize that as a junior developers, you’re not as familiar with the tools, but the tools do provide you with information most of the time. You genuinely just need to take a few extra seconds and read what it is saying.

Note: I did ask my junior developer if it was ok to share this story. they said yes.

Over the past couple weeks, the tech community has been slowly coming to terms with a prominent person like that. He seems congenial — started a successful open source project, co-founded a reputable company — until you come across his blog filled with unhinged political diatribes. I’m speaking, of course, of DHH: Ruby on Rails creator David Heinemeier Hansson.

If you, like me, don't pay much attention to this person, the last thing you might remember him from is the fracas a few years ago over his company Basecamp banning political discussions at work. While I had my opinions about that, it seemed to fit within the general range of politics you can expect from most people. I assumed David was just a normal guy with whom I had some political differences, and went on with my life.

That all changed when I heard about the recent hostile takeover of the RubyGems package manager, which appears to have started over a lost sponsorship for giving David a conference speaking slot. My interest was piqued, so I checked out his recent post "As I remember London". By the time I finished reading, my jaw was on the floor.

DHH's politics are not normal.

Maybe they used to be, I don't know, but as of right now the dude is way the fuck outside of what most people would consider moral or acceptable.

But don't take my word for it. We can get it straight from the horse’s mouth. Let’s go through David’s "As I remember London"^[1] post and see exactly what he’s all about.

Native Brits

David's post starts off fairly anodyne:

As soon as I was old enough to travel on my own, London was where I wanted to go. Compared to Copenhagen at the time, there was something so majestic about Big Ben, Trafalgar Square, and even the Tube around the turn of the millenium. Not just because their capital is twice as old as ours, but because it endured twice as much, through the Blitz and the rest of it, yet never lost its nerve. I thought I might move there one day.

Yeah, man. I have cousins not too far away from there, so even though I live across the pond I've been lucky enough to visit a few times. London is great!

That was then. Now, I wouldn't dream of it. London is no longer the city I was infatuated with in the late '90s and early 2000s. Chiefly because it's no longer full of native Brits. In 2000, more than sixty percent of the city were native Brits. By 2024, that had dropped to about a third. A statistic as evident as day when you walk the streets of London now.

The honeymoon is over: Big Ben and Trafalgar Square are only majestic if enough passersby are “native Brits”.

That’s a little vague, but he links "native Brits" to a Wikipedia article called "Ethnic groups in London" so we can see exactly whom he’s talking about:

Greater London had a population of 8,899,375 at the 2021 census. Around 41% of its population were born outside the UK, and over 300 languages are spoken in the region.

59% of Londoners were born in the UK! How could it possibly be that only a third of them are native Brits?

The article’s first section breaks down the demographic data in a table. The first ethnicity listed? “White British” at 36.8% as of the 2021 census.

Ah.

As for other ethnic groups: the table rolls up “Asian or Asian British” at 20.8%, “Black or Black British” at 13.5%, “Mixed or British Mixed” at 5.7% and “Other” at 6.3%.^[2] No other group is even remotely close to a third.

It turns out that when DHH says “native Brits”, he’s specifically referring to white Brits. That's why it's "a statistic as clear as day when you walk the streets of London": it's his coy way of saying that too many of the 59% of Londoners born and raised in the UK are not white.

So if David means "white Brits", why doesn't he just say that? Why bother with the innuendo?

Because complaining that there aren’t enough white people sounds weird and racist! David bristles at that label, but there's a reason he's hiding behind euphemisms rather than just saying what he means. Most people don't go around thinking “boy, all these Black and Asian people make this city so much worse.”

Most people, that is, except for David:

But I think, what would Copenhagen feel like, if only a third of it was Danish, like London? It would feel completely foreign, of course. Alien, even. So I get the frustration that many Brits have with the way mass immigration has changed the culture and makeup of not just London, but their whole country.

He thinks that a city that has too many Black people feels “completely foreign”. That it’s “alien” to see too many Asian people as he walks the streets. David tries to throw "mass immigration" in there — but as we know, his problem with the "culture and makeup" is how many people are not white, whether or not they're immigrants.

Unite the Kingdom

David continues:

That frustration was on wide display in Tommy Robinson's march yesterday. British and English flags flying high and proud, like they would in Copenhagen on the day of a national soccer match. Which was both odd to see but also heartwarming. You can sometimes be forgiven for thinking that all of Britain is lost in self-loathing, shame, and suicidal empathy. But of course it's not.

Who's Tommy Robinson? According to his Wikipedia entry, he’s an “anti-Islam campaigner and one of the UK's most prominent far-right activists with a history of criminal convictions”.

Not a great start! But maybe Wikipedia just has a left wing bias?^[3]

Well…

• He’s described himself — verbatim — as opposed to Islam.
• He promised to retaliate against — also verbatim — every single Muslim in response to a terrorist attack.
• He called for the blanket deportation of — you guessed it, verbatim! — every adult male Muslim who recently immigrated to the entire EU.

How about the march he organized? HOPE not hate reported on what the speakers he invited had to say.

“It’s not just Britain that is being invaded, it’s not just Britain that is being raped. Every single Western nation faces the same problem: an orchestrated, organised invasion and replacement of European citizens is happening.”

That one’s Tommy Robinson himself.

The Dutch far-right commentator Eva Vlaardingerbroek delivered one of the day’s most incendiary speeches, appearing in a t-shirt emblazoned with the words “Generation Remigration”. She said:

“They are demanding the sacrifice of our children on the altar of mass migration. Let’s not beat about the bush — this is the rape, replacement, and murder of our people… Remigration is possible, and it’s up to us to make it happen. We are Generation Remigration.”

I had to look up the word "remigration". It means "ethnic cleansing via the mass deportation of non-white immigrants and their descendants, sometimes including those born in Europe, to their place of racial ancestry".

“This is a religious war,” said Brian Tamaki, leader of New Zealand’s Destiny Church. “Islam, Hinduism, Baháʼí, Buddhism — whatever else you’re into — they’re all false. We’ve got to clean our countries up. Get rid of everything that doesn’t receive Jesus Christ. Ban any public expression of other religions in our Christian nations. Ban halal. Ban burqas. Ban mosques, temples, shrines — we don’t want those in our countries.”

I mean… these people are clearly deranged, right? You'd think any of this would warrant at least a passing mention, but for some reason David doesn't include a single quote about what the people at this "heartwarming" march actually said.

David is well aware that these people are extremists. That's why he tries to preempt that accusation:

The easy way out of this uncomfortably large gathering of perfectly normal, peaceful Brits who've had enough is to tar them all as "far right". That's not just a British tactic, but one used across Europe, and previously in the US as well. It used to work very well, because the historical stigma was so strong, but, like hurling "nazi" and "fascist" at the most middle-of-the-road political figures and positions, it's finally lost its power.

Note that David never actually addresses the "far right" label on its merits — he just pivots to calling it overused, trying to direct your attention elsewhere like a magician distracting the audience as he performs a trick. We are meant to believe him that because people sometimes use “far right” and “nazi” and “fascist” too liberally, that must be happening here as well.

But of course, that’s not what’s happening here. Calling these people far right is "easy" for the same reason it's "easy" to say Joe Biden is liberal: it's obviously true! These are not "middle-of-the-road" positions — they're literally calling to ban non-Christian religions and to ethnically cleanse non-white citizens. It takes no stretch of the imagination to figure out why these people are far right.

Demographic Replacement

Let's say you wanted to trick me into believing a conspiracy theory.

You'd have to start with a grain of truth, right? You can't come out of the gate with the COVID vaccine nano-chips that Bill Gates uses to track us through the 5G cell towers.^[4] That'd scare me off!

No, the first step is to find some common ground. Something we can both agree on. Then you can slowly mix in the crazy stuff.

That in mind, let's continue with David’s post:

I really feel for the Brits because it's not obvious how they get themselves out of this pickle. They're still reeling from the Pakistani rape gangs that were left free to terrorize cities like Rotherham and Rochdale for years on end with horror-movie-like scenes of the most despicable, depraved abuse of British girls.

The child sexual abuse scandals were real and horrible. The perpetrators were mostly British-Pakistani, and the victims were largely white. No one is disputing that; it's the grain of truth.

But like any good con artist, David has mixed in some other not-quite-so-true things he wants you to believe as well.

For one: David really wants to make sure you know that the perpetrators were largely Pakistani: scary brown foreigners. He’s insinuating that there’s some connection between their ethnicity and sexually abusing children. It's not just that many of these abusers happened to be Pakistani; David's implying they did it because they were Pakistani. (Many of them were also British — but as we know by now, in David’s eyes that only counts if you're white.)

When it comes to the victims, though, David brings out the dog whistles. He describes them as "British girls" (read: white). "Barbaric outsiders preying upon innocent white women" is a classic racist trope that would be perfectly at home in the Jim Crow South or Nazi Germany.

I don't know. But I'm glad that there clearly are many Brits who are determined to find out. Unwilling to just let their society wither away while their bobbies chase bad tweets instead of the rampant street thefts or those barbaric rape gangs. Unwilling to resign the rest of the country to the kind of demographic replacement that befell London over the last two decades.

On top of the "barbaric rape gangs", David also brings up "rampant street thefts" — suggesting that the same scary brown foreigners are responsible. The problem is that his implication is only backed up by bigotry. The source he links to about the street thefts, for example, never mentions race or ethnicity. And in spite of the salacious rape gangs story, data show that non-white people in the UK are ever-so-slightly less likely to commit child sexual abuse.

After planting the grain of truth and making lurid insinuations, David finally gets to the crazy stuff. "Demographic replacement”: a reference to a debunked conspiracy theory that there’s a plot to replace white people in Western society. It's the same thing that motivated the deadly Charlottesville Unite the Right^[5] march's infamous chant: "you will not replace us!"

“Far Right”

David ends with a quote from Danish Prime Minister Mette Frederiksen of the Social Democrats. Someone, he says, that “nobody could credibly charge with being ‘far right’”:

There are really a lot of us Danes who believed that when people came to this ‘world’s best country’ and were given such good opportunities, they would integrate. They would become Danish, and they would never, ever harm our society. All of us who thought that way have been wrong.

Notice how moderate her words are compared to what David says and supports! Frederiksen is not saying that her country is being "invaded" or "raped", for example. She's not calling for it to be ethnically cleansed, or accusing of foreign men of being predators.

This is a running theme for David. He is desperately trying to convince you that he is not "far right", his people are not "far right", his politics are not "far right". Probably because – for all his bluster about how the label has lost its power — David knows that it's actually a huge red flag.

Personally, I don't think the label matters. I've been calling these people "far right" because it's convenient and accurate, not because I'm invested in that particular term. Shit by any other name would smell as foul, and David and his friends are extremely pungent.

Let's ditch the superlatives and review David's post objectively:

• He thinks that even if you were born in the UK, you only count as British if you're white.
• He wouldn't consider living in London specifically because it has too many people of color.
• He uses racist tropes to accuse Asian men of being dangerous predators who attack white women.
• He pushes debunked conspiracy theories about immigrants replacing white people.
• He finds a march where speakers called for banning all non-Christian religions and ethnically cleansing immigrants "heartwarming".
• Finally — and maybe most alarmingly — he argues that all of the above is normal and not extreme.

You can use whatever word you want to describe all that. But if you, like me, didn't realize that this is who DHH is, we can probably agree that he's way worse than we thought.

Mark Driscoll, the main subject of The Rise and Fall of Mars Hill podcast and all around awful human being, continues to be a troll for God online:

Scott Baker, a self-professed theologian and professor, posted the following response in this thread, which I'll quote below:

Hey, friends! Theologian here. Mark is wrong. About nearly everything, yes, but specifically here. There’s no such thing as “head of household” in a Christian marriage. That’s Rome, not Jesus. We can talk a little about it! 

The Bible is rife with patriarchy, but that patriarchy is neither commanded nor taught. It was simply the way of the world. In much the same way as the Bible deals with slavery, it does not call for an end to the institution within its pages, but it provides the theological guidance and imperatives that will lead to its abolition. The desire to preserve it - like Mark has - is evil akin to wanting to reinstate slavery.

Now this slip that the patriarchalists like to do, using the phrase “head of household,” is both deliberate and sinister. The phrase “head of household” does not appear in the Bible. Period. Don’t tell me it does, I can read in multiple languages. In Ephesians 5, Paul writes that the husband is the head of the wife, but Paul uses the term “head” to mean source, the way we still use it in “headwater.”

One way to prove that is to point out every use of the word by Paul being used in that metaphorical sense except when he’s talking abut physiology. Another is to simply point out that the head (or brain) being responsible for cognitive and executive function was not widely-known in the 1st century. Making a whole metaphor based on information Paul is unlikely to have had - let alone his audience - is nonsensical, and wholly unnecessary unless you’re using it as a proof text.

Believing that Paul’s use of the word “head” = “patriarchy” is unnecessary and far more complicated than acknowledging the simple fact that the word does not denote authority or leadership. Back to “head of household.”It’s not in the Bible, and the nearest cognate to it is saying something completely different. They know. They know that “head of household” is a more familiar term, so they elude it with “head” from Ephesians, and, voila, they claim the Bible teaches patriarchy. 

You know who does use the phrase “head of household?” Like… a lot? Rome. It’s all over their laws. It means not just authority, but *absolute* authority. I am hard-pressed to cite a better example of Scripture being used to say the same exact opposite of what it actually says.

So, no, Mark. The Bible does not teach men to be the “head of household.”I’m not even going to bother with the dumb bit about Satan. That’s just Dork being a mark… or… whatever. There is a still more excellent way. 

Note: I added the link above to the Wikipedia page on Rome and family structures.

Gotcha suckers! 🎯

My point in linking to this thread is not because I believe Scott Baker to be 100% accurate or the final argument against men as the head of a household. Or as a big gotcha to "fight the patriarchy" in a progressive way. But to show how a phrase that you might have heard over and over like "men should be the head of the household" might not be as Bible based as some folks claim it is.

It might be something that's done in your faith tradition, or culture, or your specific family. But since there are also a lot of theologians who say it's not necessarily biblical, I think it's worth unpacking what the actual origins of that idea are.

See also Sheila Way Gregoire's post "In the Case of Ties, He Wins" for a deeper look at the impact the phrase can have on marriages:

...after four different surveys, of just about 40,000 primarily evangelical respondents, looking into their marital and sexual quality, I can tell you very strongly that these different expectations have real-world consequences.

It's a slippery slope from this to... 😱

Slippery slope arguments are often, but not always, a slippery slope towards a fallacy.

Digging into an idea such as "men as head of household" shouldn't shake your faith in God or Jesus, but it should cause you to question what people are teaching if they throw around phrases like "men should be the head of the household" as if it were words spoken directly by Jesus. I'd suggest that it's worth investigating whether things like that are actually in the Bible, or if it's just something that's been repeated at you enough that you assume it's 100% true.

You can even continue to believe that men must be the head of every household if you and your household are ok with that. But don't say "...because it's biblical..." as justification for it.

What about the replies? 🤣

Predictably, Driscoll's post has stirred up a lot of conversation. But more importantly, a lot of good jokes poking fun at the idea:

Greg Johnstone (@johnstone.gregory) on Threads

I wouldn’t call her that to her face mate

Threads

Matthew Podszus (@matthew_podszus) on Threads

Men, if you’re not the commissioner of your fantasy football league, Satan is!

Threads

Deric Cahill (@deric_cahill) on Threads

Satan and I are co-leading, thank you very much.

Threads

Courtney Heard (@godless_mom) on Threads

No, sweetie, Satan isn’t in charge. Mommy just asked you to do the dishes for once. I can totally see, tho, how you might confuse “shared responsibilities” with “demonic possession.”

Threads

Dr. Jennifer Billinson (@jrbillin) on Threads

There are no men in my household, it’s 100% all Satan all the time

Threads

Leslie Gaar (@thelesliegaar) on Threads

Look if Satan takes out the trash and remembers to put the seat down, we have a deal.

Threads

Statement Tees & Things™ (@statementteesandthings) on Threads

When men think like you do, Satan already is the man of the house.

Threads

Rowan Jetté Knox (@rowanjetteknox) on Threads

Amazing. Satan can pay my bills then.

Threads

JB (@wigglemachine) on Threads

As the only person in my household, I guess that makes me the Satan 👿

Threads

Jon McEwen (@jon.mce) on Threads

Mark sometimes you gotta let go and let Satan take the wheel.

Threads

Jeremy West (@jeremywest15) on Threads

Satan and I are roommates and run the house as equals, thank you very much!

Threads

I write content. That content is consumed by people. But a lot of it has been used to train AIs for people to get a very quick answer. You can see the amount of bots visiting websites has been going up significantly. You ask a question about JavaScript and they go suck in 40 pages and it distills it down. From a user perspective I love it. I don’t want to read your life story, I want to get straight to the answer. How often do you just read the Google Summary and just close the tab?

For those people that [create content] for money, that business is going to be significantly disrupted. What happens to the people that rely on that money? There’s no shortage of people putting content on the internet right now. Will that stop? I don’t know.

It’ll stop when there is no longer any incentive to do so. Those incentives are various! Money is one. That was a partial motivator for me. Being able to support myself and my family partially through advertising on content was important. But I also found it to be fun and mentally rewarding, like it gave my life purpose. Even if the money wanes, those incentives may endure for many.

Promoting other things can be another incentive. If you can still manage to get eyes on you, the value doesn’t have to come from traditional advertising. It could be because you’re working for a company, and there is value in the DevRel. You could be taking pre-orders for your next book. You could offer a training course for sale. Your superfans can pay for superchats and supermemberships on your Twitch or whatever.

As long as there are incentives left to create technical content, people will. And AIs will continue to train on it. That does frame it as an adversarial relationship, which is a bummer (something something capitalism).

Wes specifically wondered about me!

He spent a good chunk of his life. His legacy was putting out very helpful information. CSS-Tricks is a huge swath of information. He was able to that because he was able to make money. The next CSS-Tricks isn’t going to be able to make that much money. The AIs are just going to gobble it up and contribute to our brain rot.

I certainly wrote a lot of content for that site. And so did a ton of other authors, who still do to this day. And AIs have slurped and increasing reslurp it up. My main concerns with the AI-slurp-age are:

1. It’s rude. Nobody asked me (or the other authors) if that’s OK. Now that’s the bar and they never will.
2. The business model is akin to stealing pennies.
3. AI interfaces are incentivized to not credit sources or link out. They want you to think that they are the brain, and you need not go anywhere else.

I’m slightly less concerned that AI slurpage will disincentivize all content creation. Humans love other humans, and we’ll always want to connect with each other. We want to learn together and laugh together and play together, and, as weird as it is, sharing technical content with each other is a niche in there.

Wes wondered if I “got out” at the right time. I sorta think I did. It was not premeditated, though. At the time, I was much more focused on advertising. For years leading up to the sale, I invested more and more money into the site with the goal of growth, only to see traffic stay flat. It wasn’t perfectly correlated, but flat traffic doesn’t help advertising revenue. Ramping up the amount of work for the same traffic and same money wasn’t feeling great. At the time, I assumed it was just a temporary slump, but now with enough distance, it kinda wasn’t. Fortunately, Digital Ocean didn’t really need the advertising, which is why I thought it was a perfect buyer. They had other incentives. I have no idea what they think of the purchase now, but I would hope it’s quite positive. There was a weird slump, but with Geoff still over there, I think they are doing awesome.

I feel compelled to mention that my content creation career is far from over and takes many forms:

• This site has loads of blog posts.
• The CodePen blog has loads of blog posts, and the PODCAST IS BACK! Not to mention: THE ENTIRE CODEPEN is a massive trove of content, by far the biggest I’ve been a part of building. I’ve written a ton of public code there, which is like 0.000001% of what is there.
• CSS-Tricks had lots of writing, but also video content.
• I’ve guest-posted all over the place.
• I’ve got GitHub repos.
• I write at Frontend Masters, which is my CSS-Tricks energy replacement, and whose business model around content is perfect.
• ShopTalk Show has over 10 years of weekly podcasts.
• I’ve always been at least moderately active on the most appropriate social media platforms throughout my entire career.

So. Much. Content.

I still think it’s fun and has value and plan to continue doing it, even if the incentives around doing it are constantly being battered down. I’ll need to continue to evolve how I get value out of it. I do enjoy it so much I’ll probably be explaining border-radius tricks into the dirt with a stick after the apocalypse.

Wes also said of AI:

As a user, I love it.

I feel that, too.

AI companies do slimy shit, and they know it. But I don’t wanna just take my ball and go home.

There is some real user benefit coming out of AI products right now. It’s fun to be a part of. I’m experiencing genuine productivity boosts from using AI for coding work. The evolution of user interfaces around it is fascinating.

Perhaps ironically, there is an awful lot of user content about AI — lolz.

Talk to any guitarist you know who has been playing awhile and they’ll have a story about a $200 Yamaha and how good it sounds relative to the price.

Boy do I. I own a $5,000 guitar (what I originally paid for straight-grain Brazilian Rosewood Martin replica by Dennis Overton) and I didn’t even notice it was gone for years. Now that’s mostly me being an idiot and not playing guitar as my primary instrument, but still, it’s very telling a cheap ass Yamaha was to me an un-noticable difference. I wrote then:

I still feel like an idiot for not realizing for so long. Honestly, that little $150 Yamaha sounds pretty damn good if you ask me.

We played at the High Desert Museum the other week for their “Art in the West” event.

We play at The Cellar every Wednesday night (I make it to as many as I can). Here’s a couple of tunes from a couple weeks ago that Jason Chinchen shot:

Sometimes we busk, typically in downtown Bend. One night I brought my camera to catch the band doing their thing:

Here’s a few grabs from when I’ve gotten to join:

We played a show at The Silver Moon during Bend Roots Revival and the sound guy recorded and sent us his “Board Mix” and it sounds pretty good to me! I was also on mandolin in this show.

We also played a show at River’s Place last month and since Dale Atkin’s was playing and brought his nice PA, we recorded from that as well. Here’s our opening tune “Breaking up Christmas” from that show:

But an audience of a bunch of random folks just getting excited can get it wrong!

This video of Harry Connick Jr. extending a bar just one extra beat to adjust the audience to clapping on the correct beat is extremely friggin cool.

(via Alan Smith)

Do you recall all those years you were a hot mess? Life was a series of chaotic mistakes and mishaps until out of necessity (having dependants) you developed an extensive set of strategies. The strategies work well, but are annoying to manage, so you are sometimes tempted in to thinking you're a fully functional adult now who can "just remember" to do important things. This is folly, and will only lead to disappointment and burnt potatoes.

Thanks for reading this post via RSS! Let me know your thoughts by leaving a comment on the original post or send me an email.

"Language is not merely a set of unrelated sounds, clauses, rules, and meanings; it is a totally coherent system bound to context and behavior." — Kenneth L. Pike

The web has accents. So should our design systems.

Design Systems as Living Languages

Design systems aren't component libraries—they’re living languages. Tokens are phonemes, components are words, patterns are phrases, layouts are sentences. The conversations we build with users become the stories our products tell.

But here’s what we've forgotten: the more fluently a language is spoken, the more accents it can support without losing meaning. English in Scotland differs from English in Sydney, yet both are unmistakably English. The language adapts to context while preserving core meaning. This couldn’t be more obvious to me, a Brazilian Portuguese speaker, who learned English with an American accent, and lives in Sydney.

Our design systems must work the same way. Rigid adherence to visual rules creates brittle systems that break under contextual pressure. Fluent systems bend without breaking.

Consistency becomes a prison

The promise of design systems was simple: consistent components would accelerate development and unify experiences. But as systems matured and products grew more complex, that promise has become a prison. Teams file “exception” requests by the hundreds. Products launch with workarounds instead of system components. Designers spend more time defending consistency than solving user problems.

Our design systems must learn to speak dialects.

A design dialect is a systematic adaptation of a design system that maintains core principles while developing new patterns for specific contexts. Unlike one-off customizations or brand themes, dialects preserve the system’s essential grammar while expanding its vocabulary to serve different users, environments, or constraints.

When Perfect Consistency Fails

At Booking.com, I learned this lesson the hard way. We A/B-tested everything—color, copy, button shapes, even logo colors. As a professional with a graphic design education and experience building brand style guides, I found this shocking. While everyone fell in love with Airbnb’s pristine design system, Booking grew into a giant without ever considering visual consistency.  

The chaos taught me something profound: consistency isn’t ROI; solved problems are.

At Shopify. Polaris (https://polaris-react.shopify.com/) was our crown jewel—a mature design language perfect for merchants on laptops. As a product team, we were expected to adopt Polaris as-is. Then my fulfillment team hit an “Oh, Ship!” moment, as we faced the challenge of building an app for warehouse pickers using our interface on shared, battered Android scanners in dim aisles, wearing thick gloves, scanning dozens of items per minute, many with limited levels of English understanding.

Task completion with standard Polaris: 0%.

Every component that worked beautifully for merchants failed completely for pickers. White backgrounds created glare. 44px tap targets were invisible to gloved fingers. Sentence-case labels took too long to parse. Multi-step flows confused non-native speakers.

We faced a choice: abandon Polaris entirely, or teach it to speak warehouse.

The Birth of a Dialect

We chose evolution over revolution. Working within Polaris’s core principles—clarity, efficiency, consistency—we developed what we now call a design dialect:

Result: Task completion jumped from 0% to 100%. Onboarding time dropped from three weeks to one shift.

This wasn’t customization or theming—this was a dialect: a systematic adaptation that maintained Polaris’s core grammar while developing new vocabulary for a specific context. Polaris hadn’t failed; it had learned to speak warehouse.

The Flexibility Framework

At Atlassian, working on the Jira platform—itself a system within the larger Atlassian system—I pushed for formalizing this insight. With dozens of products sharing a design language across different codebases, we needed systematic flexibility so we built directly into our ways of working. The old model—exception requests and special approvals—was failing at scale.

We developed the Flexibility Framework to help designers define how flexible they wanted their components to be:

During a navigation redesign, we tiered every element. Logo and global search stayed Consistent. Breadcrumbs and contextual actions became Flexible. Product teams could immediately see where innovation was welcome and where consistency mattered.

The Decision Ladder

Flexibility needs boundaries. We created a simple ladder for evaluating when rules should bend:

Good: Ship with existing system components. Fast, consistent, proven.

Better: Stretch a component slightly. Document the change. Contribute improvements back to the system for all to use.

Best: Prototype the ideal experience first. If user testing validates the benefit, update the system to support it.

The key question: “Which option lets users succeed fastest?”

Rules are tools, not relics.

Unity Beats Uniformity

Gmail, Drive, and Maps are unmistakably Google—yet each speaks with its own accent. They achieve unity through shared principles, not cloned components. One extra week of debate over button color costs roughly $30K in engineer time.

Unity is a brand outcome; fluency is a user outcome. When the two clash, side with the user.

Governance Without Gates

How do you maintain coherence while enabling dialects? Treat your system like a living vocabulary:

Document every deviation – e.g., dialects/warehouse.md with before/after screenshots and rationale.

Promote shared patterns – when three teams adopt a dialect independently, review it for core inclusion.

Deprecate with context – retire old idioms via flags and migration notes, never a big-bang purge.

A living dictionary scales better than a frozen rulebook.

Start Small: Your First Dialect

Ready to introduce dialects? Start with one broken experience:

This week: Find one user flow where perfect consistency blocks task completion. Could be mobile users struggling with desktop-sized components, or accessibility needs your standard patterns don’t address.

Document the context: What makes standard patterns fail here? Environmental constraints? User capabilities? Task urgency?

Design one systematic change: Focus on behavior over aesthetics. If gloves are the problem, bigger targets aren’t “"breaking the system”"—they’re serving the user. Earn the variations and make them intentional.

Test and measure: Does the change improve task completion? Time to productivity? User satisfaction?

Show the savings: If that dialect frees even half a sprint, fluency has paid for itself.

Beyond the Component Library

We’re not managing design systems anymore—we’re cultivating design languages. Languages that grow with their speakers. Languages that develop accents without losing meaning. Languages that serve human needs over aesthetic ideals.

The warehouse workers who went from 0% to 100% task completion didn’t care that our buttons broke the style guide. They cared that the buttons finally worked.

Your users feel the same way. Give your system permission to speak their language.

💬 Join the discussion on kottke.org →