Last week, the Safari team formally expressed their opposition to the WebMCP API. In Safari’s explanation of why they oppose WebMCP, they captured something I’ve been trying to articulate.

In the comment explaining the Safari team position, Mike Wyrzykowski writes:

When a site’s actions are hard for an agent to use, that is a gap in the page’s own semantics, and the fix, in our opinion, is to close it in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit. 

Amen.

In fact, this sentiment should guide any efforts to change the web to support AI agents better. It’s possible that not every enhancement for AI can be structured in a way that supports all of the web’s shared layers, but we should strive to do so first before reaching for solutions that only benefit AI and not the humans the web is supposed to serve.

The Safari teams continues:

Our deeper concern is architectural. An agent acting on a user’s behalf is, in effect, assistive technology: it should operate a site as the user would, and the site should not single it out for different treatment. 

And on accessibility:

The proposal says WebMCP “is not designed for ingestion by accessibility technology”, the same fork: richer, actionable semantics reach agents while screen-reader and keyboard users get less.

All of this reminds me of a recent discussion on the Web Incubator Community Group (WICG) mailing list about a proposed standard to help AI understand domain authority. The proposed standard is designed to solve the following problem:

AI assistants often misidentify or misrepresent domains because there is no consistent, machine-readable, domain-controlled source of identity data. Today, models rely on scraped pages, inconsistent metadata, third-party aggregators, or outdated indexes. There is no canonical place where a domain can declare who they are, what they represent, or which resources are authoritative.

The proposed solution suggests adding a JSON-LD document to every website to solve the problem.

Humans struggle with domain authority as well. People have trouble telling what websites are legitimate and which aren’t. If we’re solving this problem for AI, perhaps we can find a solution that works for end users too.

And let’s set aside for the moment the irony that AI is supposed to replace all of our jobs and become a super intelligence and at the same time we also need to add special AI training wheels for it to use the web.

I’d like to see the Safari team’s response to the Web MCP API canonized as a W3C Design Principle. Maybe a slight rewrite like this:

When a site’s actions are hard for an AI agent to use, that is a gap in the page’s own semantics, and we should first seek to close it in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit. 

We can put it right next to the W3C’s Priority of Constituencies:

If a trade-off needs to be made, always put user needs above all…

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

You’ll notice AI agents aren’t in that priority of constituencies, but assuming agents stick around, it might be worth considering where we’d put them.

I hope we can all agree that user needs come before agent needs. We should keep this in mind as we consider proposals to modify the web to support AI.

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

This notion of delivering "optimistically" while planning for failure is something I've written about before, but the set-it-and-forget-it nature of this latest stab at it makes it my favorite yet. And funny enough, while it's just another take on careful Progressive Enhancement, this one actually feels more like "graceful degradation" to me! Hmm. I won't dwell on that one.

Anyway, last week, Brian Kardell pointed out to me over on Bluesky that the problem Self-Destructing CSS addresses reminded him of one that commonly occurs with Web Components, when developers hide custom elements until they are "defined" by their JavaScript. That's an anti-pattern I covered in my Web Components course, and it's common because it aims to work around a very real issue: often, we don't want our users to see a component until it's "ready."

That (anti)-pattern looks like this:

:not(:defined) {
  visibility: hidden;
}

Let's break that down. CSS gives us the pseudo-state :defined which will match any custom element once it is defined by JavaScript. For example, if you have an element <my-element> in your HTML, it starts out essentially a div with a more descriptive name. That "~div" could be useful on its own, but typically developers will define its custom behavior using the customElements APIs now built into browsers (effectively turning it into a "web component," if you please). That element definition looks like this:

customElements.define('my-element', class extends HTMLElement {
  /*...lifecycle additions can go here */
});

Once defined, my-element will be selectable in CSS via :defined, along with all of the other "defined" HTML elements. To be clear, that includes every built-in element defined by the browser, so that :defined selector alone isn't terribly useful on its own, and might do better paired with an element selector instead. That said, if we're trying to style all undefined custom elements to hide them before they're defined, then a selector that matches the opposite of :defined is pretty handy. That's how folks arrived at hiding content with :not(:defined) { visibility: hidden; }.

Unfortunately, while this pattern is clever, it's also risky: if JS fails to run or load in any reasonable amount of time, those elements will remain hidden. I've seen this pattern cause content to be invisible for long periods while popular budget-tier devices struggle to churn through massive JavaScript bundles, even if they're on a fast network.

After a brief delay, hiding content entirely just isn't worth whatever effect you're hoping to achieve.

Improving :not(:defined) with Self-Destructing CSS

As I commented in this HTML standard issue about it, this situation is a great use case for self-destructing CSS.

So moving forward, if you need to hide un-enhanced Custom Elements, I suggest you do not do this:

:not(:defined) {
  visibility: hidden;
}

And instead, do this!

@keyframes hideBriefly {
  0%, 100% { visibility: hidden; } 
}
:not(:defined) { animation: hideBriefly 2s; }

Here, just as before, as soon as your element gets defined, the hiding will instantly and automatically unapply. But it will also unapply itself after two seconds no matter what, should the JavaScript take that long to do its thing, or fail to run at all. That last part is critical, because in our medium, we can't expect things to just work like they do on our machine. In fact, they usually don't.

Anyway, that's Self-Destructing CSS for web components. Go play some defense out there on behalf of your users! Oh, and if you want to take this the extra mile, make sure that your initially-delivered HTML is useful/meaningful/functional before the JavaScript loads. Otherwise, you might as well just hide it without a fallback, I guess!

I wrote about it over at the silverorange blog.

adactio.com/links/22420

• Setting an incorrect tabindex value or forgetting to set it at all.
• Forgetting to call the focus() function to move the focus to the right element.
• Not preventing the default browser behavior when handling arrow keys.
• Focusing disabled or hidden inputs by mistake.
• Implementing a keyboard navigation pattern that doesn't match your users' expectations.
• Not properly handling all text directions.
• Not restoring the previously selected element on refocus.
• And more.

Introducing focusgroup

• You don't need to write any tabindex roving code yourself or import a library for it.
• Using focusgroup is easy; a single HTML attribute is often the only thing you need to add.
• The arrow keys are handled for you, across all text directions and skipping over disabled and hidden elements.
• The keyboard navigation patterns that focusgroup provides are based on guidelines from the ARIA Authoring Practices Guide.
• Focusgroup also works for elements in shadow DOM.

• Sites will load faster!
• You will get a more consistent keyboard navigation experience across websites.
• While tabbing will let you navigate through the main sections of a page, the top, right, bottom, and left arrow keys will work as you'd expect and let you access the various elements or inputs inside of a section.

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

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