Journal tags: v

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!

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.

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!

Towards the end of 2025, I wrote:

I think I might change things up in 2026. Instead of waiting until the end of the year to write all the little reviews at once, I think I should write a review as soon as I finish a book. Instead of holding onto my reckons for months, I can just set them free one at a time.

I’ll get the ball rolling with the first book I read in 2026.

I’ve mentioned before that one interesting lens to apply to modern retellings of the Greek myths is how they treat deities. Are gods and goddesses real in this story? Or is it a non-interventionist tale with a purely human cast? In her book The Shadow Of Perseus, Claire Heywood wrote about Perseus, Medusa, and Andromeda without any supernatural characters. Having been impressed by that, I figured I’d go back to investigate her debut, Daughters Of Sparta.

The framing device is one I hadn’t come across before. It follows the diverging stories of sisters Helen and Clytemnestra, flipping back and forth between the two throughout their lives. I’ve read plenty of takes on the Trojan war, and I’ve read plenty of takes on Clytemnestra’s revenge, but I think this is the first time they’ve been combined like this.

Overall, it works. There are inevitable time jumps. Some time periods are bound to get more attention than others. And at some point, the narrative just has to wrap up, even though we know there’s pleny more that follows afterwards.

All in all, a good addition to the list of modern retellings of classical Greek stories.

If you’re the kind of person who likes Web Day Out, you’re probably also the kind of person who likes State Of The Browser.

Web Day Out is all about what you can in web browsers right now, with an emphasis on immediately practical techniques and technologies. State Of The Browser is similar, but with room for fun demos that push the boundaries.

State Of The Browser is on Saturday, 28 February.

Web Day Out is on Thursday, 12 March.

It would be a shame if you had to choose between these two excellent events.

Well, you don’t have to!

If you buy a ticket for Web Day Out you can get a whopping 50% off the ticket price for State Of The Browser. Or if you can’t make it in person, your Web Day Out ticket gets you a free online ticket!

You might be thinking, “Well, much as I’d love to go to both events, I don’t think I can convince my boss to give me two conference days.” Worry ye not! State Of The Browser is on a Saturday, so unless you’re working an extremely extended work week, you still only need to take one day away from your desk to go to two events.

So don’t delay: get your ticket for Web Day Out. Then you’ll get an email with details on how to get your 50% discount for State Of The Browser (or your free online ticket, whichever you prefer).

But wait! What if you already bought a ticket for State Of The Browser? Check your email. You’ve been sent a very, very generous discount code for Web Day Out to thank you for getting your ticket nice and early.

I’ll see you at State Of The Browser in London …and then I’ll see you at Web Day Out in Brighton!

For the past few years, I’ve been taking a trip to Spain at the end of September for the Cáceres Irish Fleadh. Last year I convinced my friends Liam and Monica to come along and they had a great time.

Like me, Liam just loves playing in sessions. Also like me, Liam likes to spend the gloomy short days of January thinking about travelling somewhere …and then playing in sessions there.

I told him I’d put together a list of potential trips for the discerning session hound. I figured I might as well share it here too…

First of all, there are Irish music festivals. Alas, most festivals don’t happen in the sunny climes of Spain. As you’d expect, most of them are in Ireland.

I’m heading to Carlingford at the end of this month for a weekend of Féile na Tána. I haven’t been before but it looks good. There’ll be the usual amalgam of workshops, concerts, and sessions.

Myself and Jessica will fly in to Belfast, then take the train down to Newry and get to Carlingford from there. You could fly into Dublin and get the train up to Dundalk, but the only Gatwick flights to Dublin are Ryan Air, and I’d rather entrust my instrument to EasyJet.

At the end of March we’re heading to Tullamore Trad Fest. That’s another one we haven’t been to before. Again, there’ll be workshops, concerts, and sessions.

Tullamore is just an hour away from Dublin by train and has plenty of accommodation options. We’ve booked into a nice-looking B&B.

There’s no avoiding Ryan Air for this trip and I want to take my good mandolin, so I’ve gone ahead and booked a separate seat for it. I don’t want to take any chances with an airline that actively seeks to elevate misery.

The festival I heartily recommend is Belfast Trad Fest at the end of July. It’s super convenient to get to with EasyJet flights from Gatwick—go to Belfast city airport, which is right downtown.

The festival offers a really good accommodation deal in modern student flats. The workshops are top-notch, and best of all, it has a really well-organised session trail. You can easily play in sessions all afternoon and evening.

This year, for the first time ever, Belfast trad fest is immediately followed by the all-Ireland fleadh, which promises to be pandemonium. I’ve never been to the fleadh before but I’m going to stick around Belfast for it.

You could head to the Willie Clancy Festival in Miltown Malbay at the start of July (the website seems to be having some issues right now). But good luck finding accommodation. The event is so big now that unless you’re camping, there’s not much chance of finding a place to stay. If you make it there though, non-stop sessions await. Non-stop chaos awaits too. That’s part of the deal. Great workshops though!

There are other festivals I haven’t been to but I’ve heard great things about. The Pádraig O’Keeffe Festival in Kerry in October sounds fantastic, especially if you like your polkas and slides. But it’s in Castleisland, which doesn’t have much in the way of accommodation. So unless you’ve got transport, it’s going to be tricky.

There’s a trad fest in Kilkenny in March. I’ve never been but they’ve got a session trail. You’d need to fly into either Dublin or Cork and then get on a bus. Either way, it’s Ryan Air from Gatwick.

I’ve also never been to the Ennis Trad Fest in county Clare in November but I’ve heard good things. Accommodation for the 2026 event is already in short supply though.

But you don’t need a festival to play in sessions. In fact, the kind of sessions you end up in at festivals have a different vibe to the usual sessions, simply because they’re formed of a hodge-podge of visiting players.

There a few spots in Ireland where you’re guaranteed a session pretty much any night of the week.

I love Galway. There are afternoon sessions in Taafe’s and Tigh Cóilí as well as evening sessions in the Crane and other places. You’d need to fly into Dublin and get the train from there. It takes about two hours.

Galway is busy in the summer time and accommodation can be pricy, but if you go off-season you can find some cheaper options.

Ennis has music most nights. There’s a regular bus service between Ennis and Shannon airport that’s nice and quick. You’d need to fly Ryan Air from Gatwick though.

And then there’s Belfast again. Even when the trad fest isn’t happening, Belfast has sessions seven nights a week. Check out the Belfast session guide Instagram account for up-to-date details.

I recommend staying in The Flint, but make sure you ask for a room on the top floor far away from the nightclub if you’re there on a weekend.

So, to recap, here are some festivals to check out:

• Féile na Tána in Carlingford, county Louth in January (I’m going),
• Tullamore Trad Fest in county Offaly in March (I’m going),
• Kilkenny Trad Fest also in March,
• Scoil Samhraidh Willie Clancy in Miltown Malbay, county Clare in July,
• Belfast Trad Fest at the end of July (I’m going),
• Fleadh Cheoil na hÉireann also in Belfast at the start of August (I’m going),
• Cáceres Irish Fleadh in Spain in September (I’m going),
• The Pádraig O’Keeffe festival in Castleisland, county Kerry in October, and
• Ennis Trad Fest in county Clare in November.

And then for year-round session action, you can visit:

• Galway,
• Ennis, and
• Belfast

The datalist element is all fucked up on iOS. Again.

I haven’t “upgraded” my iPhone to iOS 26 and I have no plans to. The whole Liquid Glass thing is literally offputting. So I wouldn’t have known about the latest regression in Safari if a friend hadn’t texted me about the problem.

He was trying to do a search on The Session. He was looking for the tune, The Road To Town. He started typing this into the form on the home page of the site. He got as far as “The Road To”. That’s when the entire input was obscured by a suggestion from the associated datalist.

This is incredibly annoying and seems to be a pattern of behaviour for Safari. Features are supported …technically. But the implementation is so buggy as to be unusable.

I’ll probably have to do some user-agent sniffing, which I hate. And it won’t be enough to just sniff for Safari on iOS 26. Remember that every browser on iOS is just Webkit in a trenchcoat.

Time to file a bug and then wait God knows how long for an update to get rolled out.

Update: I filed a bug, but in the meantime it looks like user-agent sniffing is going to be impossible.

Stop me if this sounds familiar to you…

There’s a conference you heard about it. It sounded really good but you never got ’round to getting a ticket. You were too busy thinking about work stuff. It was just one of those things that remained in the idle thought stage.

Then the day of the conference rolls around. You’re sitting in front of your computer seeing the social media posts from people at the event who are having a ball. The talks sound really good and you wish you could be there. You wonder why you never got ’round to getting that ticket.

Maybe you’ve experienced that when FFconf is happening and people like me are in the audience posting about some revelatory insight we’ve just received. Or maybe you see the blog posts and pictures from an event like dConstruct and you realise that you missed your chance to experience something special.

I’ve certainly experienced it when I’m not in Düsseldorf or Berlin for Beyond Tellerrand and all my friends are posting about how excellent it is.

It’s kind of like FOMO but instead of fear of missing out, it’s more like regret at missing out: RAMO.

I’m giving you advance warning. If you have anything at all to do with front-end development and you don’t come to Web Day Out, you are definitely going to experience RAMO.

Seriously, it is shaping up to be something very special indeed. Check out the schedule to see what I mean:

• I can’t believe it’s not JavaScript
• A pragmatic guide to browser support
• Progressive web apps from the trenches
• Build for the web, build on the web, build with the web
• Breaking with habits
• What’s new in web typography?
• Customisable select and the friends we made along the way
• The browser is the playground

Tickets are just £225+VAT. Now is the time to get yours. It’s the second week of the new year. You’ve settled back into work. Now in the depths of Winter, you need something to look forward to, something that’s going to get you excited about making websites. That’s Web Day Out.

And if you need to convince your boss, I’ve got you covered.

Here’s the new year, same as the old year. Well, not the same, but pretty similar.

At the end of 2024, I wrote:

It was a year dominated by Ukraine and Gaza. Utterly horrific and unnecessary death courtesy of Putin and Netanyahu

See what I mean?

2025 added an extra dose of American carnage with Trump’s psychotic combination of cruelty and incompetence directed at the very foundations of the country. I’ve got to be honest, I’m tired of the USA living rent-free in my head so I’ve issued an eviction notice. It’s not that I don’t have sympathy and empathy for what’s happening there, but a majority of the country voted for this …again. Like a dog voting to have its nose rubbed in its own shit. Maybe this time the lesson will stick.

Anyway, leaving world events aside (yes, please!), I also said this at the end of last year:

For me personally, 2024 was just fine. I was relatively healthy all year. The people I love were relatively healthy too. I don’t take that for granted.

Again, same. No major health issues in 2025. My loved ones are well. My gratitude grows.

I’ve already written about how much music I played in 2025. I’m hoping to continue that trajectory in 2026 with lots of sessions. We’re four days into the year and I’ve already had two excellent sessions. There are another three lined up this week.

One of the highlights of 2025 was my trip with Jessica to Donegal. Learning Irish by day, playing in sessions by night, all while surrounded by gorgeous scenery. I’ve already got a return trip planned for 2026. I’m also planning to be back in Belfast for the annual tradfest.

Other 2025 highlights include:

• Curating an excellent edition of UX London.
• Releasing the new Salter Cane album and playing those songs live—I want to do more of that in 2026.

Most of my travel in 2025 was either for music or family.

I made three trips to the States to see the in-laws: California, Florida, and most recently, Arizona. I can’t say I feel very comfortable going to the States right now, especially to Florida, where people openly display their intolerance on their T-shirts, and Arizona where they openly display their guns.

I went back to my hometown of Cobh a few times during the year to visit my mother.

Aside from those family trips, I went to Belfast, Donegal, Galway, and Clare in Ireland, Cáceres in Spain, Namur in Belgium, and Amsterdam. Only that last one was work-related. I always make sure to get to CSS Day.

Meanwhile here on my website, I posted 695 times in 2025. That includes 345 notes, 262 links, and 86 blog posts. Here are some I’m quite fond of:

• The web on mobile
• Portugeating
• Style your underlines
• Hounds Of Love
• Research
• Bóthar
• Why use React?
• Tunes and typefaces

All in all, 2025 was a grand year for me. It wasn’t all that different from the year before. I’m at an age where the years aren’t all that differentiated from one another. I’m okay with that because I’m also at an age where I know what brings me joy and satisfaction, and I can focus on those things.

So here’s to 2026, which I hope I will spend doing more of what I did in 2025: playing music, speaking Irish, eating good food, hanging out with friends, reading good books, travelling to interesting places, and staying relatively healthy.

I read 28 books in 2025. Looking back over that list, there are a few recurring themes…

I read less of the Greek mythology retellings than last year but I seem to have developed a taste for medieval stories like Matrix, Nobber, and Haven.

I finally got ‘round to reading some classics of post-apocalypse fiction like Earth Abides and I Am Legend.

I read lots of short story collections: Salt Slow, Bloodchild And Other Stories, The Bloody Chamber And Other Stories, Folk, and The End of the World is a Cul de Sac. There’s quite a dollop of horror in some of those.

I’m clearly hankering for the homeland because I read a lot of books set in Ireland: The Country Girls, Haven, Prophet Song, The End of the World is a Cul de Sac, and Nobber.

And there’s the usual smattering of sci-fi from the likes of Nnedi Okorafor, Adrian Tchaikovsky, Arkady Martine, Becky Chambers, and Emily St. John Mandel.

Here’s what I thought of these 28 books, without any star ratings…

Earth Abides by George R. Stewart

I started this one in 2024 and finished it in the first few weeks of 2025. It’s a classic piece of post-apocalypse fiction from 1949. It’s vivid and rich in detail, but there are some odd ideas that flirt with eugenics. There’s a really strange passage where the narrator skirts around describing the skin colour of his new-found love interest. I get the feeling that this was very transgressive at the time, but it’s just a bit weird now.

The Last Song Of Penelope by Claire North

The final book in Claire North’s Songs Of Penelope trilogy is the one that intersects the most with The Odyssey. There’s a looming sense of impending tragedy because of that; we’ve spent the last two books getting to know the handmaids of Ithica and now here comes Odysseus to fuck things up. I enjoyed the whole trilogy immensely.

Short Stories In Irish by Olly Richards

This is a great way to get used to reading in Irish. The stories start very simple and get slightly more complex as throughout the book. None of the stories are going to win any prizes for storytelling, but that’s not the point. If you’re learning Irish, I think this book is a great tool to augment your lessons.

Sea Of Tranquility by Emily St. John Mandel

Nothing will ever top the brilliance of Station Eleven but I still enjoyed this time-travel tale set in the interconnected Emily St. John Mandel cinematic universe.

The Heart In Winter by Kevin Barry

A very Irish western. The language is never dull and the characters are almost mythological in personality.

Matrix by Lauren Groff

One woman’s life in a medieval convent. What’s really engrossing is not just the changes to the protaganist over her lifetime but the changes she makes to the community.

Hera by Jennifer Saint

I didn’t enjoy this quite as much as Jennifer Saint’s previous books. Maybe that’s because this is set almost entirely in the milieu of gods rather than mortals.

A Psalm For The Wild-Built by Becky Chambers

A short book about a tea-making monk meeting a long-lost robot and going on a road trip together. It’s all quite lovely.

Bloodchild And Other Stories by Octavia Butler

A superb collection of short stories. Bloodchild itself is a classic, but every one of the stories in this collection is top notch. Some genuinely shudder-inducing moments.

Salt Slow by Julia Armfield

Staying with short story collections, this one is all killer, no filler. Julia Armfield knows how to grab you with a perfect opening line. Any one of these stories could be the basis for a whole novel. Or a David Cronenberg film.

The Voyage Home by Pat Barker

The third book in Pat Barker’s retelling of the aftermath of the Trojan war is just as gritty as the first two, but this one has more overt supernatural elements. A grimly satisfying conclusion.

Folk by Zoe Gilbert

A collection of loosely-connected short stories dripping with English supernatural folk horror. The world-building is impressive and the cumulative effect really gets under your skin.

Death of the Author by Nnedi Okorafor

The description of the Nigerian diaspora in America is the strongest part of this book. But I found it hard to get very involved with the main character’s narrative.

Bear Head by Adrian Tchaikovsky

The sequel to Dogs Of War and just as good. On the one hand, it’s a rip-roaring action story. On the other hand, it’s a genuinely thought-provoking examination of free will.

A History Of Ireland in 100 Words by Sharon Arbuthnot, Máire Ní Mhaonaigh, and Gregory Toner

Every attendee at Oideas Gael in Glencolmcille received a free copy of this book. I kept it on the coffee table and dipped into it every now and then over the course of the year. There are plenty of fascinating tidbits in here about old Irish.

Haven by Emma Donoghue

Medieval monks travel to the most inhospitable rock off the coast of Kerry and start building the beehive huts you can still see on Skellig Michael today. Strong on atmosphere but quite light on plot.

Doggerland by Ben Smith

Fairly dripping with damp atmosphere, this book has three characters off the coast of a near-future Britain. The world-building is vivid and bleak. Like The Sunken Land Begins to Rise Again by M. John Harrison, it’s got a brexity vibe to the climate crisis.

Bee Speaker by Adrian Tchaikovsky

I found this third book in the Dogs Of War series to be pretty disappointing. Plenty of action, but not much in the way of subtext this time.

Yellowface by Rebecca F Kuang

Surprisingly schlocky. Kind of good fun for a while but it overstays its welcome.

Nobber by Oisín Fagan

Gory goings-on in a medieval village in county Meath. For once, this is a medieval tale set in harsh sunlight rather than mist-covered moors. By the end, it’s almost Tarantino-like in its body count.

Orbital by Samantha Harvey

A fairly light book where nothing much happens, but that nothing much is happening on the International Space Station. I liked the way it managed to balance the mundane details of day-to-day life with the utterly mind-blowing perspective of being in low Earth orbit. Pairs nicely with side two of Hounds Of Love.

The End of the World is a Cul de Sac by Louise Kennedy

Louise Kennedy is rightly getting a lot of praise for her novel Trespasses, but her first book of short stories is equally impressive. Every one feels rooted in reality and the writing is never less than brilliant.

A Prayer for the Crown-Shy by Becky Chambers

The second short book in the Monk and Robot solarpunk series. It’s all quite cozy and pleasant.

Our Wives Under The Sea by Julia Armfield

I said that each short story in Julia Armfield’s Salt Slow could be a full-length novel, but reading her full-length novel I thought it would’ve been better as a short story. It’s strong on atmosphere, but it’s dragged out for too long.

I Am Legend by Richard Matheson

Another classic of post-apocalyptic fiction that looks for a scientific basis for vampirism. It’s a grim story that Richard Matheson tells in his typically excellent style.

The Country Girls by Edna O’Brien

Reading this book today it’s hard to understand how it caused such a stir when it was first published. But leaving that aside, it’s a superb piece of writing where every character feels real and whole.

The Bloody Chamber And Other Stories by Angela Carter

If I’m going to read classic short horror stories, then I’ve got to read this. Twisted fairy tales told in florid gothic style.

Rose/House by Arkady Martine

An entertaining novella that’s a whodunnit in a haunted house, except the haunting is by an Artificial Intelligence. The setting feels like a character, and I don’t just mean the house—this near-future New Mexico is tactile and real.

Prophet Song by Paul Lynch

I haven’t finished this just yet, but I think I can confidentally pass judgement. And my judgement is: wow! Just an astonishing piece of work. An incredible depiction of life under an increasing totalitarian regime. The fact that it’s set in Ireland makes it feel even more urgent. George Orwell meets Roddy Doyle. And the centre of it all is a central character who could step right off the page.

There you have it. A year of books. I didn’t make a concious decision to avoid non-fiction, but perhaps in 2026 I should redress the imbalance.

If I had to pick a favourite novel from the year, it would probably be Prophet Song. But that might just be the recency bias speaking.

If you’re looking for some excellent short stories, I highly recommend Salt Slow and The End of the World is a Cul de Sac.

About half of the 28 books I read this year came from the local library. What an incredible place! I aim to continue making full use of it in 2026. You should do the same.

It’s getting towards the end of the year. That’s when I put together a post reviewing the books I’ve read in the previous twelve months.

I think I might change things up in 2026. Instead of waiting until the end of the year to write all the little reviews at once, I think I should write a review as soon as I finish a book. Instead of holding onto my reckons for months, I can just set them free one at a time.

And I think I’m done with ratings. Stars. I’m not sure why I ever started, to be honest. Probably because everyone else was doing it. But they kind of just get in the way. I spend far too long deliberating about how many stars to give a book when I should be spending that time describing the effect that the book had on me.

In any case, books, movies, music …it’s all entirely subjective. Assigning stars gives a veneer of something measurable, countable, and objective. That’s not how art works.

But that’s just my opinion.

I think I’ve also developed more of an aversion to scoring things the more it’s crept into everyday life. It feels like you can’t perform any kind of transaction without being asked later to rate the experience.

I remember the first time I was ever in an Uber. This was many years ago in San Francisco. I was with a bunch of friends at an after-party for An Event Apart in the TypeKit offices. Someone suggested that we move on to a second location and proceeded to whip out the Uber app.

I remember looking at the little icon of the car moving in real time as it approached our location. So futuristic!

We all bundled into the car and off we went. The driver was a really nice guy. But at some point he made a navigational error and took us off track. He fixed it, but I remember my friend who had summoned the Uber was kind of miffed.

When we were getting out of the car, the driver apologised profusely before driving off. My friend—who was basically showing me how this whole Uber thing worked—explained that he would now give a less than stellar review for the driver, becuase of that directional snafu.

“Ah, come on”, I said, “he was a nice guy.”

“This is how the app gets accurate data”, he responded.

“But …it’s a person”, I said.

Something about reviewing a person felt so wrong to me. Books, movies, music …I get it. But applying the same logic to a human being. That just didn’t sit right with me.

Now we’re expected to review humans all the time. It still feels wrong to me.

That’s probably why I’m done with ratings. No more stars from me.

There’s the old adage “nobody gets fired for buying IBM”. Or to put it more broadly, “everyone else is doing it.”

It’s dispiriting how often this explanation is given as justification for a dubious design decision, from home-page carousels to cookie banners.

Nic Chan has written a great post about designing a contact form and how the process was derailed by the client pointing to other people’s contact forms …even when they’ve got very, very different user needs.

It’s especially depressing when “everyone else is doing it” is used a substitute for any kind of accountability.

Building an email service that’s going to track when people click on links in an email? That sounds dodgy. On the other hand, everyone else is doing it.

Building a straightforward website, but making it a single-page app with client-side React that will be barely work on some devices and networks? That seems over-engineered. On the other hand, everyone else is doing it.

Sometimes the “everyone else is doing it” phenomenon leads to a chain reaction where nobody even knows why anyone ever did it in the first place.

Remember Flash? Remember when almost every website had a Flash intro? Everyone knew they were annoying and uneccessary, but everyone else was doing it.

Instead of getting rid of the intros, we got “skip intro” links instead. This link was guaranteed to have a 100% clickthrough rate.

I’ve noticed something similar with conference talks. So many of them begin with a little spiel about the speaker, their background, and their work experience.

This might be interesting information, but this isn’t the right time or place for it. It’s already on the conference website, in the conference programme, and has probably just been reiterated by the conference host who just introduced the speaker.

When I’ve asked why people do this, the responses generally come down to “everyone else is doing it.” It’s become an expected part of the conference talk, just like a Flash intro used to be an expected part of a website.

When I’m curating a conference, I like to send speakers some information to help them prepare their talk. Some of this is practical stuff, like the tech set-up. Some of it is guidance for the slides, like ensuring sufficient colour contrast. And then there’s this:

Please don’t begin your talk with an introduction about yourself and your work history. You’ll be introduced on stage so it would be a shame to just repeat all that again. Also, it just gets in the way of the actual content of your talk. No need to provide your bona-fides.

Personally, I just find it super cringe. That’s why I don’t do it if I’m giving a talk myself.

As a host however, it’s a big part of my job. It’s way less cringe to have someone else big you up before the talk then doing it yourself.

Safari, Chrome, and Edge all allow you to install websites as though they’re apps.

On mobile Safari, this is done with the “Add to home screen” option that’s buried deep in the “share” menu, making it all but useless.

On the desktop, this is “Add to dock” in Safari, or “Install” in Chrome or Edge.

Firefox doesn’t offer this functionality, which as a shame. Firefox is my browser of choice but they decided a while back to completely abandon progressive web apps (though they might reverse that decision soon).

Anyway, being able to install websites as apps is fantastic! I’ve got a number of these “apps” in my dock: Mastodon, Bluesky, Instagram, The Session, Google Calendar, Google Meet. They all behave just like native apps. I can’t even tell which browser I used to initially install them.

If you’d like to prompt users to install your website as an app, there’s not much you can do other than show them how to do it. But that might be about to change…

I’ve been eagerly watching the proposal for a Web Install API. This would allow authors to put a button on a page that, when clicked, would trigger the installation process (the user would still need to confirm this, of course).

Right now it’s a JavaScript API called navigator.install, but there’s talk of having a declarative version too. Personally, I think this would be an ideal job for an invoker command. Making a whole new install element seems ludicrously over-engineered to me when button invoketarget="share" is right there.

Microsoft recently announced that they’d be testing the JavaScript API in an origin trial. I immediately signed up The Session for the trial. Then I updated the site to output the appropriate HTTP header.

You still need to mess around in the browser configs to test this locally. Go to edge://flags or chrome://flags/ and search for ‘Web App Installation API’, enable it and restart.

I’m now using this API on the homepage of The Session. Unsurprisingly, I’ve wrapped up the functionality into an HTML web component that I call button-install.

Here’s the code. You use it like this:

<button-install>
  <button>Install the app</button>
</button-install>

Use whatever text you like inside the button.

I wasn’t sure whether to keep the button element in the regular DOM or generate it in the Shadow DOM of the custom element. Seeing as the button requires JavaScript to do anything, the Shadow DOM option would make sense. As Tess put it, Shadow DOM is for hiding your shame—the bits of your interface that depend on JavaScript.

In the end I decided to stick with a regular button element within the custom element, but I take steps to remove it when it’s not necessary.

There’s a potential issue in having an element that could self-destruct if the browser doesn’t cut the mustard. There might be a flash of seeing the button before it gets removed. That could even cause a nasty layout shift.

So far I haven’t seen this problem myself but I should probably use something like Scott’s CSS in reverse: fade in the button with a little delay (during which time the button might end up getting removed anyway).

My connectedCallback method starts by finding the button nested in the custom element:

class ButtonInstall extends HTMLElement {
  connectedCallback () {
    this.button = this.querySelector('button');
    …
  }
customElements.define('button-install', ButtonInstall);

If the navigator.install method doesn’t exist, remove the button.

if (!navigator.install) {
  this.button.remove();
  return;
}

If the current display-mode is standalone, then the site has already been installed, so remove the button.

if (window.matchMedia('(display-mode: standalone)').matches) {
  this.button.remove();
  return;
}

As an extra measure, I could also use the display-mode media query in CSS to hide the button:

@media (display-mode: standalone) {
  button-install button {
    display: none;
  }
}

If the button has survived these tests, I can wire it up to the navigator.install method:

this.button.addEventListener('click', async (ev) => {
  await navigator.install();
});

That’s all I’m doing for now. I’m not doing any try/catch stuff to handle all the permutations of what might happen next. I just hand it over to the browser from there.

Feel free to use this code if you want. Adjust the code as needed. If your manifest file says display: fullscreen you’ll need to change the test in the JavaScript accordingly.

Oh, and make sure your site already has a manifest file that has an id field in it. That’s required for navigator.install to work.

Here’s the schedule for Web Day Out—what a fantastic collection of talks!

Web Day Out

10:00 – 10:30	I can’t believe it’s not JavaScript	Jemima Abu
10:30 – 11:00	A pragmatic guide to browser support	Rachel Andrew
11:30 – 12:00	Progressive web apps from the trenches	Aleth Gueguen
12:00 – 12:30	Build for the web, build on the web, build with the web	Harry Roberts
14:00 – 14:30	Breaking with habits	Manuel Matuzovič
14:30 – 15:00	What’s new in web typography?	Richard Rutter
15:30 – 16:00	Customisable <select> and the friends we made along the way	Jake Archibald
16:00 – 16:30	The browser is the playground	Lola Odelola

Seeing all of those talk titles in a row is getting me very, very excited for this day!

I hope that you’re excited too, and I hope you’ve got your ticket already.

If you need to convince your boss to send you (and your team) to Web Day Out I’ve put together some reasons to attend along with an email template that you can use as a starting point.

Also, if your company is sending a group of people anyway, consider sponsoring Web Day Out. You get a bunch of conference tickets as part of the sponsorship deal.

Hope to see you in Brighton on Thursday, 12 March 2026!

This isn’t a rhetorical question. I genuinely want to know why developers choose to build websites using React.

There are many possible reasons. Alas, none of them relate directly to user experience, other than a trickle-down justification: happy productive developers will make better websites. Citation needed.

It’s also worth mentioning that some people don’t choose to use React, but its use is mandated by their workplace (like some other more recent technologies I could mention). By my definition, this makes React enterprise software in this situation. My definition of enterprise software is any software that you use but that you yourself didn’t choose.

Inertia

By far the most common reason for choosing React today is inertia. If it’s what you’re comfortable with, you’d need a really compelling reason not to use it. That’s generally the reason behind usage mandates too. If we “standardise” on React, then it’ll make hiring more straightforward (though the reality isn’t quite so simple, as the React ecosystem has mutated and bifurcated over time).

And you know what? Inertia is a perfectly valid reason to choose a technology. If time is of the essence, and you know it’s going to take you time to learn a new technology, it makes sense to stick with what you know, even if it’s out of date. This isn’t just true of React, it’s true of any tech stack.

This would all be absolutely fine if React weren’t a framework that gets executed in browsers. Any client-side framework is a tax on the end user. They have to download, parse, and execute the framework in order for you to benefit.

But maybe React doesn’t need to run in the browser at all. That’s the promise of server-side rendering.

The front end

There used to be a fairly clear distinction between front-end development and back-end development. The front end consisted of HTML, CSS, and client-side JavaScript. The back end was anything you wanted as long as it could spit out those bits of the front end: PHP, Ruby, Python, or even just a plain web server with static files.

Then it became possible to write JavaScript on the back end. Great! Now you didn’t need to context-switch when you were scripting for the client or the server. But this blessing also turned out to be a bit of a curse.

When you’re writing code for the back end, some things matter more than others. File size, for example, isn’t really a concern. Your code can get really long and it probably won’t slow down the execution. And if it does, you can always buy your way out of the problem by getting a more powerful server.

On the front end, your code should have different priorities. File size matters, especially with JavaScript. The code won’t be executed on your server. It’s executed on all sorts of devices on all sorts of networks running all sorts of browsers. If things get slow, you can’t buy your way out of the problem because you can’t buy every single one of your users a new device and a new network plan.

Now that JavaScript can run on the server as well as the client, it’s tempting to just treat the code the same. It’s the same language after all. But the context really matters. Some JavaScript that’s perfectly fine to run on the server can be a resource hog on the client.

And this is where it gets interesting with React. Because most of the things people like about React still apply on the back end.

React developers

When React first appeared, it was touted as front-end tool. State management and a near-magical virtual DOM were the main selling points.

Over time, that’s changed. The claimed speed benefits of the virtual DOM turned out to be just plain false. That just left state management.

But by that time, the selling points had changed. The component-based architecture turned out to be really popular. Developers liked JSX. A lot. Once you got used to it, it was a neat way to encapsulate little bits of functionality into building blocks that can be combined in all sorts of ways.

For the longest time, I didn’t realise this had happened. I was still thinking of React as being a framework like jQuery. But React is a framework like Rails or Django. As a developer, it’s where you do all your work. Heck, it’s pretty much your identity.

But whereas Rails or Django run on the back end, React runs on the front end …except when it doesn’t.

JavaScript can run on the server, which means React can run on the server. It’s entirely possible to have your React cake and eat it. You can write all of your code in React without serving up a single line of React to your users.

That’s true in theory. The devil is in the tooling.

Priorities

Next.js allows you to write in React and do server-side rendering. But it really, really wants to output React to the client as well.

By default, you get the dreaded hydration pattern—do all the computing on the server in JavaScript (yay!), serve up HTML straight away (yay! yay!) …and then serve up all the same JavaScript that’s on the server anyway (ya—wait, what?).

It’s possible to get Next.js to skip that last step, but it’s not easy. You’ll be battling it every step of the way.

Astro takes a very different approach. It will do everything it can to keep the client-side JavaScript to a minimum. Developers get to keep their beloved JSX authoring environment without penalising users.

Alas, the collective inertia of the “modern” development community is bound up in the React/Next/Vercel ecosystem. That’s a shame, because Astro shows us that it doesn’t have to be this way.

Switching away from using React on the front end doesn’t mean you have to switch away from using React on the back end.

Why use React?

The titular question I asked is too broad and naïve. There are plenty of reasons to use React, just as there are plenty of reasons to use Wordpress, Eleventy, or any other technology that works on the back end. If it’s what you like or what you’re comfortable with, that’s reason enough.

All I really care about is the front end. I’m not going to pass judgment on anyone’s choice of server-side framework, as long as it doesn’t impact what you can do in the client. Like Harry says:

…if you’re going to use one, I shouldn’t be able to smell it.

Here’s the question I should be asking:

Why use React in the browser?

Because if the reason you’re using React is cultural—the whole team works in JSX, it makes hiring easier—then there’s probably no need to make your users download React.

If you’re making a single-page app, then …well, the first thing you should do is ask yourself if it really needs to be a single-page app. They should be the exception, not the default. But if you’re determined to make a single-page app, then I can see why state management becomes very important.

In that situation, try shipping Preact instead of React. As a developer, you’ll almost certainly notice no difference, but your users will appreciate the refreshing lack of bloat.

Mostly though, I’d encourage you to investigate what you can do with vanilla JavaScript in the browser. I totally get why you’d want to hold on to React as an authoring environment, but don’t let your framework limit what you can do on the front end. If you use React on the client, you’re not doing your users any favours.

You can continue to write in React. You can continue to use JSX. You can continue to hire React developers. But keep it on your machine. For your users, make the most of what web browsers can do.

Once you keep React on the server, then a whole world of possibilities opens up on the client. Web browsers have become incredibly powerful in what they offer you. Don’t let React-on-the-client hold you back.

And if you want to know more about what web browsers are capable of today, come to Web Day Out in Brighton on Thursday, 12th March 2026.

The line-up for Web Day Out is now complete! The final speaker to be added to the line-up is the one and only Manuel Matuzovič.

You may know Manuel from his superb Web Accessibility Cookbook (full disclosure: I had the honour of writing the foreword to that book). Or perhaps you’re familiar with the crimes against markup that he documents at HTMHell. But at Web Day Out, he’s going to be talking about CSS.

The past few years have seen a veritable explosion in CSS capabilities. It’s one thing to hear about all the new stuff in CSS, but how do you actually start using it?

You may need to unlearn what you have previously learned. That’s what Manuel’s talk will be covering:

Manuel built a new project from scratch with modern CSS and questioned every line of code he wrote.

In this talk, he presents what he has learned and encourages you to review your best practices.

You can see why I’m so excited about this—it’s perfect for the agenda of Web Day Out:

Do you feel like you’re missing out on some of the latest advances in HTML, CSS, and JavaScript APIs? Web Day Out is your chance to get up to speed on what matters.

There’ll be eight brilliant speakers for your entertainment:

1. Jemima Abu
2. Rachel Andrew
3. Jake Archibald
4. Aleth Gueguen
5. Manuel Matuzovič
6. Lola Odelola
7. Harry Roberts
8. Richard Rutter

You won’t want to miss this, so get your ticket now for the ludicrously reasonable price of just £225+VAT!

See you in Brighton on 12 March 2026!

I find Brian Eno to be a fascinating chap. His music isn’t my cup of tea, but I really enjoy hearing his thoughts on art, creativity, and culture.

I’ve always loved this short piece he wrote about singing with other people. I’ve passed that link onto multiple people who have found a deep joy in singing with a choir:

Singing aloud leaves you with a sense of levity and contentedness. And then there are what I would call “civilizational benefits.” When you sing with a group of people, you learn how to subsume yourself into a group consciousness because a capella singing is all about the immersion of the self into the community. That’s one of the great feelings — to stop being me for a little while and to become us. That way lies empathy, the great social virtue.

Then there’s the whole Long Now thing, a phrase that originated with him:

I noticed that this very local attitude to space in New York paralleled a similarly limited attitude to time. Everything was exciting, fast, current, and temporary. Enormous buildings came and went, careers rose and crashed in weeks. You rarely got the feeling that anyone had the time to think two years ahead, let alone ten or a hundred. Everyone seemed to be passing through. It was undeniably lively, but the downside was that it seemed selfish, irresponsible and randomly dangerous. I came to think of this as “The Short Now”, and this suggested the possibility of its opposite - “The Long Now”.

I was listening to my Huffduffer feed recently, where I had saved yet another interview with Brian Eno. Sure enough, there was plenty of interesting food for thought, but the bit that stood out to me was relevant to, of all things, prototyping:

I have an architect friend called Rem Koolhaas. He’s a Dutch architect, and he uses this phrase, “the premature sheen.” In his architectural practice, when they first got computers and computers were first good enough to do proper renderings of things, he said everything looked amazing at first.

You could construct a building in half an hour on the computer, and you’d have this amazing-looking thing, but, he said, “It didn’t help us make good buildings. It helped us make things that looked like they might be good buildings.”

I went to visit him one day when they were working on a big new complex for some place in Texas, and they were using matchboxes and pens and packets of tissues. It was completely analog, and there was no sense at all that this had any relationship to what the final product would be, in terms of how it looked.

It meant that what you were thinking about was: How does it work? What do we want it to be like to be in that place? You started asking the important questions again, not: What kind of facing should we have on the building or what color should the stone be?

I keep thinking about that insight: “It didn’t help us make good buildings. It helped us make things that looked like they might be good buildings.”

Substitute the word “buildings” for whatever output is supposedly being revolutionised by generative models today. Websites. Articles. Public policy.

If you’re building software, it’s generally a good idea to avoid the Not-Invented-Here syndrome. This is when you insist on writing absolutely everything from scratch even if it would make more sense to use a third-party provider.

Need your app to take payments? Don’t try to become your own payment provider—use an existing provider instead.

Need your app to send email? Don’t try to code all that up yourself—just use an existing service.

This same thinking seems to apply to JavaScript libraries too. If you don’t use a library or framework, you’ll just end up writing your own library or framework instead, right?

Except that’s not the way that JavaScript frameworks work. At least not any more.

There was a time when JavaScript libraries really did abstract away browser differences that you probably didn’t want to deal with yourself. In the early days of jQuery—before querySelector existed—trying to work with the DOM could be a real pain. Libraries like jQuery helped avoid that pain.

Maybe it was even true in the early days of Angular and React. If you were trying to handle navigations yourself, it probably made sense to use a framework.

But that’s not the case any more, and hasn’t been for quite a while.

These days, client-side JavaScript frameworks don’t abstract away the underlying platform, they instead try to be an alternative. In fact, if you attempt to use web platform features, your JavaScript framework will often get in the way. You have to wait until your framework of choice supports a feature like view transitions before you get to use it.

This is nuts. Developers are choosing to use tools that actively get in the way of the web platform.

I think that most developers have the mental model of JavaScript frameworks completely backwards. They believe that the framework saves them time and effort (just like a payment provider or an email service). Instead these frameworks are simply limiting the possibility space of what you can do in web browsers today.

When you use a JavaScript framework, that isn’t the end of your work, it’s just the beginning. You still have to write your own code that makes use of that framework. Except now your code is restricted to only what the framework can do.

And yet most developers still believe that using a JavaScript framework somehow enables them to do more.

Jim Nielsen has a great framing on this. JavaScript libraries aren’t like payment providers or email services. Rather, it’s the features built into web browsers today that are like these third-party providers. When you use these features, you’re benefiting from all the work that the browser makers have put into making them as efficient as possible:

Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing new their offerings.

So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself.

Want to do nifty page transitions? Don’t use a library. Use view transitions.

Want to animate parts of the page as the user scrolls? Don’t use a library. Use scroll-driven animations.

Want to make something happen when the user clicks? Don’t use a library. For the love of all that is holy, just use a button.

If you agree that using a button makes more sense than using a div, then I encourage you to apply the same thinking to everything else your app needs to do.

Take advantage of all the wonderful things you can do in web browsers today. If instead you decide to use a JavaScript framework, you’re basically inventing from scratch.

Except now all of your users pay the price because they’re the ones who have to download the JavaScript framework when they use your app.

UX London will be back in 2026. It’s on June 2nd, 3rd, and 4th:

Each day features a morning packed with inspiring talks followed by an afternoon of practical hands-on workshops. It’s the perfect blend!

As with last year, each day will be themed:

• 2 June 2026: discovery day
• 3 June 2026: design day
• 4 June 2026: delivery day

You can come for a single day, but for best value, you should come for all three days.

I’m starting to put the line-up together now—hoping to match the excellence of last year’s event—and I’ll start announcing speakers early in the new year.

But if you trust me, then I highly recommend getting a super-early bird ticket now. They’ll only be available for another couple of weeks. You get a significant discount if you buy now.

Oh, and while I’m in the process of putting the line-up together, you should know that you can submit a talk or workshop proposal:

We always pay ALL our speakers for their time as well as covering the cost of accommodation and economy travel.

Don’t be shy! Pitch early, pitch often.

(That said, I wouldn’t recommend pitching a talk that focuses on “AI”. It’s not just that the bubble will probably have burst by the time UX London rolls around, it’s also that UX London doesn’t tend to focus on tools, whether they’re graphic design tools like Figma or generative tools like whatever people are using to turbo-charge their output of slop. If you’ve got a case study you want to talk about that happened to use some “AI” tool, great! But don’t make that the focus of the talk. Tell me about the problem and the solution.)