Archive: February, 2026

It’s the 25th of February and it’s a beautiful day here in Brighton. I had lunch sitting outside—that’s how unseasonably warm it is. Like a little whiff of Summer to remind us of what’s yet to come.

It’s also my birthday. The beautiful weather is an auspicious augery.

Mozilla also released a new version of Firefox. I was hoping for cross-document view transitions and scroll-driven animations for my birthday, but alas I may have to wait another year.

Later, Jessica is going to take me out for some excellent Japanese food before we head on to a session in a cosy pub. I can think of no better way to celebrate my birthday than playing a rake of jigs and reels.

I’m 55 now. It feels like a meaningful number. I think I’ve moved down an option in the select menus that ask for your age range.

I got letters in the post from my pension provider reminding me that 55 is the age when you can technically start taking money out of your pension. Something that retired people do.

I have to admit, this birthday has me entertaining retirement options. I’m already down to just three days a week. It wouldn’t take much to wind that down over the next few years. There’d be even more opportunities to savour the sunshine on a sunny day.

Anyway. Just pondering. You know, the kind of thoughts a 55-year old has.

Webspace Invaders · Matthias Ott

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.

Constraints and the Lost Art of Optimization — Den Odell

The entire intellectual and creative output of a team that reinvented personal computing fits in a space that, today, we wouldn’t think twice about wasting on a single font file.

Somewhere in the years that followed we’ve lost the creative solutions, the art of optimization, that being constrained in that way produces.

The best engineers I’ve worked with carry this instinct even when others might think it crazy. They impose their own constraints. They ask what this would look like if it had to be half the size, or run twice as fast, or use a tenth of the memory. Not because anyone demanded it, but because just by thinking there could be a better, more efficient solution, one often emerges.

Smaller and dumber - daverupert.com

The principle of least power expressed nicely:

Smaller, dumber things have more applications, go more places, and require less maintenance.

I guess I kinda get why people hate AI

To be clear, I think AI will be ultimately extremely helpful. I still am using it on my projects. I am going to use it at my next job. I, personally, don’t hate AI.

But I can’t deny that the vibes right now are awful.

Not just bad, awful. It’s not just the “chat we’re cooked you’re the permanent underclass” stuff influencers say. It’s not just the “everybody is fucked” hyperbole CEOs sprout. It’s the actual, day-to-day experience with the technology. I’m a programmer—AI actually helps me a lot. But for normal people, their interactions are profoundly more negative, and none of the people behind this technology seem to care.

blakewatson.com - I used Claude Code and GSD to build the accessibility tool I’ve always wanted

You know my thoughts on generative tools based on large language models, but this example of personal empowerment is undeniably liberating.

The Mythology Of Conscious AI

This superb essay by Anil Seth won the 2025 Berggruen Prize Essay Competition.

The future history of AI is not yet written. There is no inevitability to the directions AI might yet take. To think otherwise is to be overly constrained by our conceptual inheritance, weighed down by the baggage of bad science fiction and submissive to the self-serving narrative of tech companies laboring to make it to the next financial quarter. Time is short, but collectively we can still decide which kinds of AI we really want and which we really don’t.

Performance-Optimized Video Embeds with Zero JavaScript – Frontend Masters Blog

This is a clever technique for a CSS/HTML only way of just-in-time loading of iframes using details and summary.

How to raise children

It’s wild to me that we parent our children to fit into society, then get together with our friends and talk about how broken society is. I’ve seen people rail against our broken educational system, then demand their children get straight As in school. I’ve seen people complain about not having any time to themselves and then schedule every minute of their kid’s life.

There is more we can learn from children than they can learn from us.

Mostly we need to support children and let them know that they are loved.

Training your replacement | Go Make Things

I’ve had a lot of people recently tell me AI is “inevitable.” That this is “the future” and “we all better get used to it.”

For the last decade, I’ve had a lot of people tell me the same thing about React.

And over that decade of React being “the future” and “inevitable,” I worked on many, many projects without it. I’ve built a thriving career.

AI feels like that in many ways. It also feels different in that non-technical people also won’t shut the fuck about it.

Permacomputing principles

Here are some design princples I can get behind: long-term thinking, resilience, flexibility and seamfulness.

A considered approach to generative AI in front-end… | Clearleft

A thoughtful approach from Sam:

1. Use AI only for tasks you already know how to do, on occasions when the time that would be spent completing the task can be better spent on other problems.
2. When using AI, provide the chosen tool with something you’ve made as an input along with a specific prompt.
3. Always comprehensively review the output from an AI tool for quality.

An in-depth guide to customising lists with CSS - Piccalilli

Think you know about styling lists with CSS? Think again!

This is just a taste of the kind of in-depth knowledge that Rich will be beaming directly into our brains at Web Day Out…

A programmer’s loss of identity - ratfactor

We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, “heirloom programmers”?

Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.

If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.

Deep Blue

My social networks are currently awash with Deep Blue:

…the sense of psychological ennui leading into existential dread that many software developers are feeling thanks to the encroachment of generative AI into their field of work.

How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

I recently wrote:

The issue isn’t with the code itself, but with the understanding of the code.

That’s the difference between technical debt and cognitive debt.

John has written lots more on this.

10 Thoughts On “AI,” February 2026 Edition | Whatever

1. I don’t and won’t use “AI” in the text of any of my published work.
2. I’m not worried about “AI” replacing me as a novelist.
3. People in general are burning out on “AI.”
4. I’m supporting human artists, including as they relate to my own work.
5. “AI” is Probably Sticking Around In Some Form.
6. “AI” is a marketing term, not a technical one, and encompasses different technologies.
7. There were and are ethical ways to have trained generative “AI” but because they weren’t done, the entire field is suspect.
8. The various processes lumped into “AI” are likely to be integrated into programs and applications that are in business and creative workflows.
9. It’s all right to be informed about the state of the art when it comes to “AI.”
10. Some people are being made to use “AI” as a condition of their jobs. Maybe don’t give them too much shit for it.

Molly guard in reverse – Unsung

Marcin’s history of “molly guards” in hardware and software:

Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.

JS-heavy approaches are not compatible with long-term performance goals

Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.

But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.

Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.

Not long now ’till Web Day Out — just three weeks!

It’s also not that long until the start of a new financial year so if you’ve got training budget that needs to be used this year, send your team to Web Day Out. Not only is it excellent value for money, it’s also going to have an incredibly high density of knowledge bombs per talk.

CSS! Progressive web apps! Web typography! Browser support! And much more.

If you like the sound of Web Day Out, you’ll also like State Of The Browser, which is just ten days away. In-person tickets for that event are now sold out, but online streaming tickets are still available.

Better yet, if you buy a ticket to Web Day Out, you automatically get a free online streaming ticket for State Of The Browser!

So get your ticket in the next ten days, enjoy State Of The Browser from the comfort of your own home, and then enjoy a trip to Brighton for Web Day Out on Thursday, 12 March. See you there!

Reduce the JS Workload with no- or lo-JS options

This is an excellent one-stop shop of interface patterns:

This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.

I miss thinking hard.

There are two wolves inside you…

My Builder side won’t let me just sit and think about unsolved problems, and my Thinker side is starving while I vibe-code. I am not sure if there will ever be a time again when both needs can be met at once.

I don’t like magic.

I’m not talking about acts of prestidigitation and illusion. I mean the kind of magic that’s used to market technologies. It’s magic. It just works. Don’t think about it.

I’ve written about seamless and seamful design before. Seamlessness is often touted as the ultimate goal of UX—“don’t make me think!”—but it comes with a price. That price is the reduction of agency.

When it comes to front-end development, my distrust of magic tips over into being a complete control freak.

I don’t like using code that I haven’t written and understood myself. Sometimes its unavoidable. I use two JavaScript libraries on The Session. One for displaying interactive maps and another for generating sheet music. As dependencies go, they’re very good but I still don’t like the feeling of being dependant on anything I don’t fully understand.

I can’t stomach the idea of using npm to install client-side JavaScript (which then installs more JavaScript, which in turn is dependant on even more JavaScript). It gives me the heebie-jeebies. I’m kind of astonished that most front-end developers have normalised doing daily trust falls with their codebases.

While I’m mistrustful of libraries, I’m completely allergic to frameworks.

Often I don’t distinguish between libraries and frameworks but the distinction matters here. Libraries are bits of other people’s code that I call from my code. Frameworks are other people’s code that call bits of my code.

Think of React. In order to use it, you basically have to adopt its idioms, its approach, its syntax. It’s a deeper level of dependency than just dropping in a regular piece of JavaScript.

I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to). But the truth is that I also really dislike the extra layer of abstraction it puts between me and the browser.

Now, whenever there’s any talk about abstractions someone inevitably points out that, when it comes to computers, there’s always some layer of abstraction. If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.

I get that. But I still draw a line. When it comes to front-end development, that line is for me to stay as close as I can to raw HTML, CSS, and JavaScript. After all, that’s what users are going to get in their browsers.

My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.

Over the years, I’ve stopped doing front-end development for client projects at work. Partly that’s because I’m pretty slow; it makes more sense to give the work to a better, faster developer. But it’s also because of my aversion to React. Projects came in where usage of React was a foregone conclusion. I wouldn’t work on those projects.

I mention this to point out that you probably shouldn’t adopt my inflexible mistrustful attitude if you want a career in front-end development.

Fortunately for me, front-end development still exists outside of client work. I get to have fun with my own website and with The Session. Heck, they even let me build the occasional hand-crafted website for a Clearleft event. I get to do all that the long, hard stupid way.

Meanwhile in the real world, the abstractions are piling up. Developers can now use large language models to generate code. Sometimes the code is good. Sometimes its not. You should probably check it before using it. But some developers just YOLO it straight to production.

That gives me the heebie-jeebies, but then again, so did npm. Is it really all that different? With npm you dialled up other people’s code directly. With large language models, they first slurp up everyone’s code (like, the whole World Wide Web), run a computationally expensive process of tokenisation, and then give you the bit you need when you need it. In a way, large language model coding tools are like a turbo-charged npm with even more layers of abstraction.

It’s not for me but I absolutely understand why it can work in a pragmatic commercial environment. Like Alice said:

Knitting is the future of coding. Nobody knits because they want a quick or cheap jumper, they knit because they love the craft. This is the future of writing code by hand. You will do it because you find it satisfying but it will be neither the cheapest or quickest way to write software.

But as Dave points out:

And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.

I shudder!

But again, this too is nothing new. We’ve all seen those codebases that contain mysterious arcane parts that nobody dares touch. coughWebpackcough. The issue isn’t with the code itself, but with the understanding of the code. If the understanding of the code was in one developer’s head, and that person has since left, the code is dangerous and best left untouched.

This, as you can imagine, is a maintenance nightmare. That’s where I’ve seen the real cost of abstractions. Abstractions often really do speed up production, but you pay the price in maintenance later on. If you want to understand the codebase, you must first understand the abstractions used in the codebase. That’s a lot to document, and let’s face it, documentation is the first casuality of almost every project.

So perhaps my aversion to abstraction in general—and large language models in particular—is because I tend to work on long-term projects. This website and The Session have lifespans measured in decades. For these kinds of projects, maintenance is a top priority.

Large language model coding tools truly are magic.

I don’t like magic.

Progress Without Disruption - Christopher Butler

We’ve been taught that technological change must be chaotic, uncontrolled, and socially destructive — that anything less isn’t real innovation.

The conflation of progress with disruption serves specific interests. It benefits those who profit from rapid, uncontrolled deployment. “You can’t stop progress” is a very convenient argument when you’re the one profiting from the chaos, when your business model depends on moving fast and breaking things before anyone can evaluate whether those things should be broken.

We’ve internalized technological determinism so completely that choosing not to adopt something — or choosing to adopt it slowly, carefully, with conditions — feels like naive resistance to inevitable progress. But “inevitable” is doing a lot of work in that sentence. Inevitable for whom? Inevitable according to whom?

Every culture has its myths and legends. Greece has its gods and warriors. England has its stories of Arthur. Ireland has the Tuatha Dé Danann, The Ulster Cycle, and more.

But while the Arthurian legends and the Greek myths have been retold many times, the stories of ancient Ireland have remained largely untouched.

Kim Curran’s book The Morrigan takes on this challenge.

The blurb for the book compares it Madeline Miller’s Circe, which is a bold comparison. The writing in The Morrigan isn’t in the same league as Circe, but then again, very little is.

Structurally, the comparison makes complete sense.

Circe starts with the titular nymph in the world of the gods of Olympus before moving on to more mortal affairs, coming to a head with the events of The Odyssey, when Odysseus’s story dominates.

The Morrigan starts with the titular goddess in the world of the gods of the Túatha Dé before moving on to more mortal affairs, coming to a head with the events of The Táin, when Cú Chulainn’s story dominates.

I took me a little while to adjust to the tone, but once I did, I thoroughly enjoyed this retelling. It manages to simultaneously capture the bloody, over-the-top feeling of The Táin while also having a distinctly modern twist. By the last third, I was completely engrossed.

After finishing Circe I went on a spree of reading many, many modern retellings of Greek myths. Now that I’ve finished The Morrigan I want to do the same for the Irish legends.

But I can’t. Apart from re-reading a translation of The Táin, there’s not much else out there for me.

Kim Curran does have another book that’s just been released; Brigid (the goddess? the saint? both?). If it’s anything like The Morrigan, it’s going to be a must-read.

I hope these books are the first of many.

I watched a good film last night. Tornado from the same writer and director of the also-excellent Slow West.

Tornado is a Scottish Samurai Western set in the 1790s. Although it’s not likely that many Samurai would’ve been in Scotland during the sakoku period, I was willingly able to suspend my disbelief …until something quite minor happened on screen.

One of the characters is seen playing a concertina. “Hang on”, I thought, “1790s? That’s not right!”

And indeed, once the film was over I reached for my laptop and confirmed that the concertina is very much a 19th century invention.

Look, it’s not that I know when most musical instruments were invented, but I happened to know about the concertina’s origin because of a different technology.

See, the concertina was invented by one Charles Wheatsone. He invented quite a few things. He, along with William Cooke, more or less created the electric telegraph, around the same time as Samuel Morse.

I only know this because of the excellent book by Tom Standage called The Victorian Internet:

The remarkable story of the telegraph and the nineteenth century’s online pioneers.

Prompted by that book, I found out more about Wheatstone, including the fact that he invented the concertina. So that’s why I found myself slightly taken out of the action when watching that film last night. In the 1790s, nobody was playing the concertina in Scotland or anywhere else.

Today, though, the concertina is thriving, especially in Ireland. It’s particularly popular in County Clare. Though, as I’m writing this, I’m listening to the playing of a Kerryman, Cormac Begley.

I’ll be seeing him play tonight in the Brighton Dome where he’ll be providing the music for the superb Teaċ Damhsa production, MÁM. This’ll be my second time experiencing it. Táim ar bís!

What’s new in web typography? | Clagnut by Richard Rutter

There have been so many advances in HTML, CSS and browser support over the past few years. These are enabling phenomenal creativity and refinement in web typography, and I’ve got a mere 28 minutes to tell you all about it.

I’ve been talking to Rich about his Web Day Out talk, and let me tell you, you don’t want to miss it!

It’s gonna be a wild ride! Join me at Web Day Out in Brighton on 12 March 2026. Use JOIN_RICH to get 10% off and you’ll also get a free online ticket for State of the Browser.

Saying “No” In an Age of Abundance - Jim Nielsen’s Blog

In an age of abundance, restraint becomes the only scarce thing left, which means saying “no” is more valuable than ever.

I’m as proud of the things I haven’t generated as the things I have.

Stop generating, start thinking - localghost

Generated code is rather a lot like fast fashion: it looks all right at first glance but it doesn’t hold up over time, and when you look closer it’s full of holes. Just like fast fashion, it’s often ripped off other people’s designs. And it’s a scourge on the environment.

Coding Is When We’re Least Productive – Codemanship’s Blog

I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.

CSS in 2026: The new features reshaping frontend development - LogRocket Blog

Jemima runs through just some of the exciting new additions to CSS:

Replacing 150+ lines of JavaScript with just a few CSS features is genuinely wild. We’re able to achieve the same amount of complexity that we’ve always had, but now it’s a lot less work to do so.

And Jemima will be opening the show at Web Day Out in Brighton on the 12th of March if you want to hear more of this!

Jeremy Keith – beyond tellerrand Podcast

I really enjoyed this chat with Marc:

I recently sat down with Jeremy Keith for a spontaneous conversation that quickly turned into a deep dive into something we both care a lot about: events, community, and why we keep putting ourselves through the joy and pain of running conferences.