Journal tags: work

There’s just under a month to go until UX London 2026—exciting!

You can peruse the full schedule if you need to decide wether you’re coming for just one day or for all three. The event is designed to flow together, from discovery day to design day to delivery day, but each individual day is also designed to be a standalone experience by itself.

Day one on Tuesday, June 2nd has a focus on research:

1. Maria Isachenko will talk about how You don’t need more research time: You need a system that keeps research in product decisions.
2. Melin Edomwonyi covers Validation as a UX superpower.
3. Marley Dizney Swanson will present From insight to impact: A hypothesis-driven framework for product teams.
4. Luisa Berta will be talking about Turning failure into opportunity.

Day two on Wednesday, June 3rd is all about the nitty-gritty details of design:

1. Julia Petretta kicks things off with From onboarding to “a-ha!”: Designing the moments that really matter.
2. Andrea Grigsby has a case study called Why must things be this way? Designing with intention.
3. Piccia Neri puts a positive spin on accessibility with her talk, The best creative brief.
4. Hidde de Vries will explain why The future of UX is green: On the Web Sustainability Guidelines.

Day three on Thursday, June 4th will cover collaboration and design systems:

1. Ben Callahan will impart Wisdom from the trees.
2. Lucy Blackwell and Alex Edwards will give a case study on Putting the user at the centre of your design system.
3. Rachel Ilan Simpson will take us From 0 to scale: Building and transforming design at startups & scale-ups.
4. Matt LeMay will cover why The communication of the thing IS the thing

And those are just the morning talks!

On each day you’ll have your choice of workshop for the afternoon.

1. Feyikemi Akinwolemiwa will cover Future friction: Horizon scanning for UX.
2. Natasha den Dekker will help you answer the question How well do you know your users? Exploring assumptions through play
3. Chris How’s workshop is Yippee IA: Information architecture for digital designers
4. Oore Babatunde will help you put together UX practitioner’s code of ethics.
5. Lucrezia Ponzano will take you From chaos to clarity: A tactical workshop for real alignment.
6. Ben Callahan will guide you through Assessing organisational culture.

After your afternoon workshop there’ll be one final closing talk at the end of each day before we head to the bar. I haven’t announced those speakers yet, but believe me when I say they’re going to be quite special!

UX London 2026 is shaping up to be an excellent three days of design. Get your ticket now if you haven’t already got one.

(And just between you and me, you can use the discount code JOIN_JEREMY to get a whopping 20% off any ticket price!)

People talk about the effectiveness (or lack thereof) of large language models as though all tasks are comparable. But it strikes me that there are three broad categories of work that large language models are applied to:

1. Compression.
2. Transformation.
3. Expansion.

Compression is when you feed a large language model something big that you want to make small. Summarise this book. Give me the gist of this meeting. Large language models are generally pretty good at this, which makes sense given that they themselves are kind of like compressed artifacts.

Transformation is when large language models convert from one format into another. Turn this audio into text. Turn this jumble of data into structured JSON. A large language model can handle these tasks pretty well. There’ll probably be a few errors so make sure that’s not a deal-breaker.

Expansion is when you give a large language model a prompt to generate something from scratch. An image. A presentation. An email. A poem. This is where slop lives. The output inevitably betrays its origins, glistening with a sheen of mediocrity.

Laurie spotted this three-way split a while back:

Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.

I hope that when the bubble finally bursts, we’ll see the surviving large language models put to work on the first two categories. The boring stuff. The work that’s tedious for humans.

But tedious is as tedious does. Something I consider drudgery might be the very thing that gives you life. Like Giles says:

I have a feeling that everyone likes using AI tools to try doing someone else’s profession. They’re much less keen when someone else uses it for their profession.

The big exception seems to be programming. Apparently there are plenty of coders who never before expressed an interest in being managers who are now happily hanging up their coding spurs in favour being the overseer of non-human workers.

It’s a reasonable outlook. It could even be considered a user-centred approach. Users don’t care about the elegance of your code; they care about accomplishing their tasks.

Programming is something of an exception to the efficacy of large language models in general. Instead of relying on the subjectivity of painting, poetry, or prose, programming can be objectively tested. Throw enough money at the worst people in the world and they’ll give you tokens you can use to get the machines to test their own output. So you can get a large language model to create something reasonably good from scratch as long as that something is code.

If you had asked me about the threat model of large language models two years ago, I probably would’ve been worried for artists, writers, and musicians. I thought that software had enough inherent complexity to be relatively safe.

Now my opinion has completely reversed. Software is almost certainly the killer app for large language models.

I think the artists, writers, and musicians will be okay, or at least as okay as they ever were. It turns out that humans like things made by other humans.

And y’know what? If I had to choose which endeavour I’d rather see automated away—programming or art—it’s no competition.

Don’t get me wrong—it would be nice if everyone got paid for doing what they enjoy. It’s just that I’m okay with software engineers not being at the front of that line.

I remember when I first started getting paid money to make websites. “Really?” I thought, “Someone is willing to pay me to do something I’d do anyway?” I kept waiting for the jig to be up. Instead I saw my profession grow and expand.

Perhaps there’s a long-overdue compression happening.

Or maybe it’s more like a transformation.

Times are tough out there. I know that a lot of people are looking for work, which can be a very stressful experience.

One of the things that can make the job search stressful is uncertainty. There’s a real taboo around talking about salaries. This taboo ends up benefiting employers and punishing potential employees. There’s an information gap that can be exploited (see also: job postings that don’t list salary ranges).

That’s why I’m always pleased when people voluntarily share their income. Here are some of the people who have done this over the years:

• Dan Mall (US)
• Alistair Hey (UK)
• Jamie Tanna (UK)
• Tom Withers (UK)
• Matt Brunt (UK)
• Carolina Gilabert (UK)
• Xe Iaso (Canada)
• Kristófer Reykjalín (Canada/US/Iceland)

Because the jobs are generally in software or design, you can sort of make apples-to-apples comparisons. You can definitely get the general gist of what kind of salary to expect for certain roles.

In the interest of full transparency, I figured I’d share my own income numbers, though as you’ll see, they’re not very representative of a normal career:

• 2003: £15,434 (freelance)
• 2004: £15,900 (freelance)
• 2005: £14,125 (freelance)
• 2006: £43,009 (freelance/Clearleft)
• 2007: £34,900 (Clearleft)
• 2008: £33,833 (Clearleft)
• 2009: £35,549 (Clearleft)
• 2010: £37,174 (Clearleft)
• 2011: £40,666 (Clearleft)
• 2012: £39,750 (Clearleft)
• 2013: £39,500 (Clearleft)
• 2014: £48,655 (Clearleft)
• 2015: £46,499 (Clearleft)
• 2016: £52,106 (Clearleft)
• 2017: £56,492 (Clearleft)
• 2018: £59,498 (Clearleft)
• 2019: £59,670 (Clearleft)
• 2020: £43,807 (Clearleft)
• 2021: £48,344 (Clearleft)
• 2022: £60,446 (Clearleft)
• 2023: £55,721 (Clearleft)
• 2024: £47,104 (Clearleft)
• 2025: £42,133 (Clearleft)

The first thing you’ll notice is that agency work isn’t nearly as well paid as in-house work at a technology company. So don’t embrace agency life for the money. Speaking personally, the benefits are in autonomy and variety. Those are things I value highly.

Also, I haven’t put any job titles or levels on there because they’ve never really been codified for me. I just made up my own job titles as I went along. Again, this is not very helpful to you if you’re looking for a job at a typical company.

You’ll see that things got weird in 2020, which is to be expected because things did get weird in 2020. I was furloughed, and I also took some more time off. I got a taste for it, which is why I went down to a four-day week and later a three-day week, which is what I’m doing now. So those last five years of numbers are loopy—I’m making less than before, but if you were to adjust it for a five-day week, I’m still getting paid more than before …if that makes sense.

Perhaps the most unusual thing about my career trajectory is that I’ve been at the same place for twenty years now. That’s pretty much unheard of in tech. It’s far more usual to see people switch companies—and get a salary bump—every couple of years.

So I’m not sure if there’s any value in me sharing my numbers like this. But like I said, I admire when other people do it so I figured I’d throw mine out there.

Perhaps you’d like to share your numbers too.

Four years ago I wrote about something that has long puzzled me in the world of front-end development. Trust:

The mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

That post got some thoughtful responses but I never really understood the imbalance of trust and suspicion:

I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

But something happened recently that helped me understand that mindset better.

I wrote a while back about how the datalist element on iOS has been completely fucked up. It’s worse than if Safari simply didn’t support it.

Breaking the web like that should be a five-alarm fire, but nobody is in any rush to fix it. I recall a similar lackadaisical attitude when Safari completely broke their implentation of IndexedDB.

I had it in my head that browser features followed a forward path generally. They’d be iterated on and improved on to iron out any glitches, but it was reasonable to expect things to get better with each new version of a browser.

Now I see that’s not necessarily the case.

Had I used an over-engineered JavaScript library instead of the datalist element, I wouldn’t be facing the current situation of having to use browser-sniffing to avoid sending a standard HTML element to any browser on iOS.

Sure, that third-party JavaScript would mean that users are downloading more code, and it probably wouldn’t work well with assistive technology, but as long as I didn’t touch it, it would continue to work. That should be true of web standards—I should be able to use them secure in the knowledge that they won’t suddenly shit the bed.

Perhaps I should be grateful to Apple for dispelling my naïveté. I now have much more empathy and understanding for web developers who are suspicious of web standards and prefer to use third-party libraries instead.

Good job, Apple. Happy anniversary.

You should come to UX London in the first week of June. Why? Because it’s going to be awesome, that’s why!

You probably knew that already. You probably already decided to get a ticket because you’re smart like that.

But don’t dilly-dally! Early-bird tickets are available now but in just over one week, they won’t be.

So get your ticket by Friday, March 27th. If you get your ticket now, it’s a win for everyone. You get a cheaper ticket. We know for sure that you’re coming.

Every time someone buys a conference ticket in plenty of time, the conference organiser sleeps a little better at night.

If you need to convince your boss, you can give them these reasons to attend. I even made an email template you can use a starting point for making the case.

You could come for all three days of UX London, or you can pick just one day.

Tuesday, June 2nd is discovery day with a focus on user research. You’ll hear from great speakers like Melin Edomwonyi and Maria Isachenko as well as getting workshops from Natasha den Dekker and Feyikemi Akinwolemiwa.

Wednesday, June 3rd is design day where it’s all about the nitty-gritty details. Not only will there be great talks from Andrea Grigsby, Julia Petretta, and Hidde de Vries, there’s going to be the best-named workshop ever from my colleague Chris How: Yippee IA!

Thursday, June 4th is delivery with a focus on design systems and collaboration. Alex Edwards, Lucy Blackwell, Rachel Ilan Simpson and Ben Callahan will all be giving talks (and Ben’s doing a workshop too).

That’s not even close to the final line-up. I’m confirming more speakers right now and getting very, very excited about how it’s all shaping up.

You know you don’t want to miss this one. So get your early-bird ticket now while you still can.

If you wanted to make a really crude approximation of project management, you could say there are two main styles: waterfall and agile.

It’s not as simple as that by any means. And the two aren’t really separate things; agile came about as a response to the failures of waterfall. But if we’re going to stick with crude approximations, here we go:

• In a waterfall process, you define everything up front and then execute.
• In an agile process, you start executing and then adjust based on what you learn.

So crude! Much approximation!

It only recently struck me that the agile approach is basically a cybernetic system.

Cybernetics is pretty much anything that involves feedback. If it’s got inputs and outputs that are connected in some way, it’s probably cybernetic. Politics. Finance. Your YouTube recommendations. Every video game you’ve ever played. You. Every living thing on the planet. That’s cybernetics.

Fun fact: early on in the history of cybernetics, a bunch of folks wanted to get together at an event to geek about this stuff. But they knew that if they used the word “cybernetics” to describe the event, Norbert Wiener would show up and completely dominate proceedings. So they invented a new alias for the same thing. They coined the term “artificial intelligence”, or AI for short.

Yes, ironically the term “AI” was invented in order to repel a Reply Guy. Now it’s Reply Guy catnip. In today’s AI world, everyone’s a Norbert Wiener.

The thing that has the Wieners really excited right now in the world of programming is the idea of agentic AI. In this set-up, you don’t do any of the actual coding. Instead you specify everything up front and then have a team of artificial agents execute your plan.

That’s right; it’s a return to waterfall. But that’s not as crazy as it sounds. Waterfall was wasteful because execution was expensive and time-consuming. Now that execution is relatively cheap (you pay a bit of money to line the pockets of the worst people in exchange for literal tokens), you can afford to throw some spaghetti at the wall and see if it sticks.

But you lose the learning. The idea of a cybernetic system like, say, agile development, is that you try something, learn from it, and adjust accordingly. You remember what worked. You remember what didn’t. That’s learning.

Outsourcing execution to machines makes a lot of sense.

I’m not so sure it makes sense to outsource learning.

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.

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.

Toward the end of 2021, I wrote about working a four-day week. It really suited me. So much so that I’ve gone one further. For the past year or so I’ve been working a three-day week.

I work on Tuesday, Wednesday, and Thursday. From Friday to Monday, my days are my own.

This really changes the dynamic of the week. It no longer feels like an extended weekend. What I mean is that usually we think about the working week as the default and the weekend as the exception. That’s been flipped on its head for me. The three days I spend working feel like the exception.

Once again, this decision meant earning less money. But I’ve decided that I value time more than money. I know that’s a privileged position to be in. Many people have to expend all their time in order to make just enough money.

I’ve made some choices along the way that certainly help. I don’t have children. I don’t have a car. I live in a modest flat and I’ve paid off the mortgage. I live in a country where healthcare is free.

So I don’t have too many expenses. My biggest expenses are travel-related; getting to the States to see family, or travelling to Irish music festivals wherever they may be.

But still, working a three-day week means I can make enough to cover my expenses and still put some money aside for the future.

Now, this wouldn’t work for everyone. My work tends to be the kind that doesn’t require much direct collaboration (which is also why I mostly work from home). I imagine it could get frustrating being on a team of people working different numbers of days.

I’m also really lucky to have the choice to do this. I know that many workplaces wouldn’t allow this kind of lifestyle. Clearleft is different.

In my last conference talk, I touched on this:

I think you could you could divide management into two categories like you can do with programming languages. There is a very imperative school of management where it’s all about measurements, it’s all about those performance reports, it’s all about metrics, time tracking. Maybe they install software on your machine to track how long you’ve been working. It’s all about measuring those outputs.

That’s one approach to management. Then there’s a more declarative approach, where you just care about the work getting done and you don’t care how people do it. So if they want to work from home, let them work from home. If they want to work strange hours, let them work strange hours. What do you care as long as the work gets done? This is more about giving people autonomy and trust.

I’m very happy that Clearleft takes the declarative approach.

And I can reiterate what I said when I stopped working on Fridays:

I haven’t experienced any reduction in productivity. Quite the opposite. There may be a corollary to Parkinson’s Law: work contracts to fill the time available.

Now that I don’t work on Mondays, bank holiday weekends don’t mean much to me anymore. Or to put it another way, every weekend is like a bank holiday weekend. If I want to travel somewhere on a Friday and come back on a Monday, I don’t need to book any time off. That’s really nice.

I’ve got four days in a row to do with as I wish. I had to fight the urge to immediately launch into some new project or side-hustle to fill the time. I’m savouring it instead.

I’ve got time to take care of The Session. I’ve got time to read. I’ve got time to cook. I’ve got time to spend learning Irish. Mostly I’ve got time to just be.

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.

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

I’m very happy to announce that the one and only Jake Jaffa-The-Cake Archibald will be speaking at Web Day Out!

Given the agenda for this event, I think you’ll agree that Jake is a perfect fit. He’s been at the forefront of championing user-centred web standards, writing specs and shipping features in browsers.

Along the way he’s also created two valuable performance tools that I use all the time: SVGOMG and Squoosh, which has a permanent place in my dock—if you need to compress images, I highly recommend adding this progressive web app to your desktop.

He’s the man behind service workers and view transitions—two of the most important features for making websites first-class citizens on any device.

So what will he talk about at Web Day Out? Image formats? Offline functionality? Smooth animations? Something else entirely?

All will be revealed soon. In the meantime, grab yourself a ticket to Web Day Out—it’s just £225+VAT—and I’ll see you in Brighton on Thursday, 12 March 2026!

A bunch of the UX London speakers have been saying very nice things about the event over on LinkedIn. I’m going to quote a few of them for my future self to look at when I’m freaking out about curating the next event…

Valentina D’Efilippo:

Still buzzing … UX London smashed all expectations!

Huge shoutout to Jeremy Keith and the entire Clearleft team for their tireless efforts in making this event truly special. Three days packed with inspiration, insights, and true gems – I left feeling inspired, grateful, and already looking forward to next year’s event!

Eleni Beveratou:

Huge thanks to my fellow speakers for the inspiring talks, and to the team at Clearleft (Jeremy Keith, Louise Ash, and so many more!) for putting together such a brilliant event.

Videha Sharma:

I’ve loved learning and sharing this week! Feeling super inspired and looking forward to building new friendships!

Carolina Greno:

Last week in UX London I got to witness event planning mastery, I was in awe. Things ran smoothly and people were united under a premise: to share knowledge and build community.

This doesn’t happen by chance, it’s the mastery that pros like Jeremy and Louise bring to the table.

Sayani Mitra

Bold, thought-provoking talks. Hands-on workshops that challenged and stretched thinking. And a real sense of community that reminded me why spaces like this matter so much.

Nina Mathilde Dyrberg:

The conference was packed with inspiration, thoughtful conversations, and a strong focus on accessibility and inclusivity. Thank you Luke Hay, Jeremy Keith, Louise Ash, and the whole Clearleft team for creating such a welcoming and inspiring space!

Craig Abbott:

Jeremy Keith, Richard Rutter, Louise Ash, Chris How, Sophie Count, Luke Hay and the rest of Clearleft, take a bow! Hands down one of the best conference experiences I’ve had!

The curation was excellent, the talks complimented each other so well, it was almost like we’d all met up and rehearsed it beforehand!

ÌníOlúwa Abíódún:

A huge thank you to Jeremy Keith, Louise Ash and the Clearleft team for the opportunity and the brilliant conference you’ve put together.

It’s been inspiring to experience every moment of it.

Laura Dantonio:

Shoutout to the organisers for curating such a rich experience—3 themed days focused on Discovery, Design, and Delivery.

We remember through stories. And this event was full of them. Already looking forward to next year.

And I’m just going to quote Rachel Rosenson’s post in its entirety:

Spoke at UXLondon last week—and while the talks were great, it was something off-stage that really stuck with me.

After the Day 1 talks wrapped, a bunch of us speakers grabbed a drink, and someone pointed out: Every single speaker that day—every one—was a woman. 5 talks. 4 workshops. All women.

And it wasn’t a “Women in Tech” day. It was just… the conference.

No one made a fuss. No banners. No “look at us go!”

Just incredible women, giving incredible talks, like it was the most normal thing in the world. (Spoiler: it should be.)

Jeremy Keith mentioned how frustrating it is that all-male line-ups are still so common—and how important it is to actively design for inclusion. Major props to Jeremy and the Clearleft team for curating a line-up that was intentional without performativity.

It was refreshing. No tokenism. No checkbox energy. Just great voices on great stages. And a big honor to be one of them.

UX London happened last week.

Working on an event is a weird kind of project. You spend all your time and effort on something that is then over in the blink of an eye.

I’d been preparing for this all year. 95% of my work happened before the event—curating the line-up, planning each day. There wasn’t all that much for me to do at the event itself other than introduce the speakers and chat with the attendees.

Maybe it was because there was very little left in my control, but the night before the event I found myself feeling really anxious and nervous. I was pretty sure the line-up was excellent, but anything could happen. I really wanted everyone to have a great time, but at that point, there wasn’t much more I could do.

Then the first day started. Every talk was superb. Everyone got really stuck into their workshops. By the end of the day, people were buzzing about what a great time they’d had.

My nervousness was easing. But that was only one day of three.

The second day was just as good. Again, every talk was superb. I began to suspect that the first day wasn’t just a fluke.

The third day confirmed it. Three days of top-notch talks—nary a dud in the whole line-up!

It was, dare I say it, the best UX London yet. Not just because of the talks and workshops. The attendees were absolutely lovely! There was a really good buzz throughout.

By the end of the event I felt a huge sense of relief.

For this year’s UX London, I put a lot of time and effort into curating the line-up. There were some safe bets. There were some risky bets. They all paid off.

I’m incredibly grateful to all of the fantastic speakers and workshop hosts who really gave it their all. And I’m so, so grateful to everyone who came. It’s a tough time for events right now, and I really appreciate every single person who made it to this year’s UX London. Thank you!

The only downside to pouring my heart and soul into this year’s line-up is that I left nothing in the tank for next year. I’m already starting to worry—how am I going to top UX London 2025?

I don’t use large language models. My objection to using them is ethical. I know how the sausage is made.

I wanted to clarify that. I’m not rejecting large language models because they’re useless. They can absolutely be useful. I just don’t think the usefulness outweighs the ethical issues in how they’re trained.

Molly White came to the same conclusion:

The benefits, though extant, seem to pale in comparison to the costs.

Rich has similar thoughts:

What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.

I genuinely look forward to being able to use a large language model with a clear conscience. Such a model would need to be trained ethically. When we get a free-range organic large language model I’ll be the first in line to use it. Until then, I’ll abstain. Remember:

You don’t get companies to change their behaviour by rewarding them for it. If you really want better behaviour from the purveyors of generative tools, you should be boycotting the current offerings.

Still, in anticipation of an ethical large language model someday becoming reality, I think it’s good for me to have an understanding of which tasks these tools are good at.

Prototyping seems like a good use case. My general attitude to prototyping is the exact opposite to my attitude to production code; use absolutely any tool you want and prioritise speed over quality.

When it comes to coding in general, I think Laurie is really onto something when he says:

Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.

In other words, despite what the hype says, these tools are far better at transforming than they are at generating.

Iris Meredith goes deeper into this distinction between transformative and compositional work:

Compositionality relies (among other things) on two core values or functions: choice and precision, both of which are antithetical to LLM functioning.

My own take on this is that transformative work is often the drudge work—take this data dump and convert it to some other format; take this mock-up and make a disposable prototype. I want my tools to help me with that.

But compositional work that relies on judgement, taste, and choice? Not only would I not use a large language model for that, it’s exactly the kind of work that I don’t want to automate away.

Transformative work is done with broad brushstrokes. Compositional work is done with a scalpel.

Large language models are big messy brushes, not scalpels.

Meetings can be frustrating. But they don’t have to be.

A lot of the frustration comes from unmet expectations. You go into the meeting expecting one outcome, and when it doesn’t materialise, you declare the meeting a waste of time. But had you gone into that same meeting with different expectations, perhaps you would emerge from it in a happier state.

We were talking about this at Clearleft recently and I suggested that a simple little taxonomy of meetings might be a good starting point for avoiding frustration.

Divergent meetings

In a divergent meeting the goal is to generate ideas. These meetings often happen early in a project.

Quantity matters more than quality. Plenty of “yes, and…” rather than “no, but…” to create lots of suggestions. This is not the meeting to point out potential problems with the suggestions.

Convergent meetings

In a convergent meeting the goal is to come to a decision.

The meeting might begin with lots of options on the table. They need to be winnowed down. Poke at them. Dissect them. Ideally dismiss lots of them.

This is not the time to introduce new ideas—save that for a divergent meeting.

Just having those two categories alone could save you a lot of grief. The last thing you want is someone participating in a convergent meeting who thinks it’s a divergent meeting (or the other way around).

Those two categories account for the majority of meetings, but there’s one more category to consider…

Chemistry meetings

In a chemistry meeting there is no tangible output. The goal is to get to know one another.

In a large organisation this might be when multiple departments are going to work together on a project. At an agency like Clearleft, a chemistry meeting between us and the client team is really useful at the beginning of our partnership.

Again, the key thing is expectations. If there are people in a chemistry meeting who are expecting to emerge with a framework or a list or any kind of output, they’re going to be frustrated. But if everyone knows it’s a chemistry meeting there’s no expectation that any decisions are going to be made.

There you have it. A tiny taxonomy of meetings:

1. divergent
2. convergent
3. chemistry

This tiny taxonomy won’t cover every possible kind of meeting, but it probably covers 90% of them.

Ideally every meeting should be categorised in advance so that everyone’s going in with the same expectations.

If you find yourself trying to categorise a meeting and you think “Well, it’s mostly convergent, but there’s also this divergent aspect…” then you should probably have two separate shorter meetings instead.

And if you’re trying to categorise a meeting and you find yourself thinking, “This meeting is mostly so I can deliver information” …that meeting should be an email.

It’s just over one month until UX London. You should grab a ticket if you haven’t already!

The format of UX London is quite special. While the focus of each day is different—discovery, design, and delivery—each day unfolds like this…

There are four talks in the morning. You get your brain filled with ideas and learn from fantastic speakers. It’s a single track—everyone’s getting the same shared experience.

Then after a lunch, you choose from one of four workshops. Whatever you choose, it’s going to be hands-on. You can leave your laptop at home.

A day of listening to talks could get exhausting. A workshop that lasts all day could be even more exhausting. But somehow by splitting the day between both activities, the energy level is just right!

That said, we don’t want the day to end with everyone spread across four different workshop rooms. That’s why there’s one final talk at the end of each day.

These closing talks are a bit different to the morning talks. Whereas the focus of the morning talks is on practical skills that you can apply straight away, the closing talks are an opportunity to sit back and have your mind expanded. They’ll be fun and thought-provoking.

Paula Zuccotti is closing out day one with a talk about two of her projects: Every Thing We Touch and Future Archeology:

This talk invites audiences to reconsider the meaning of the objects they encounter every day and reflect on what their possessions might reveal about who we are and what we value, both now and in the years to come.

Sarah Hyndman will wrap up day two with a fun interactive talk about your senses:

Join a live expedition into our inner world to explore why we see, feel and remember.

Finally, Rachel Coldicutt is going to finish UX London with a rallying cry:

Introducing the Society of Hopeful Technologists and discussing how, in modern technology development, your practice is probably more political than you realise.

I can’t wait! Get yourself a ticket for a day or for all three days.

And as a little thank you for tolerating my excitement, use the discount code JOINJEREMY to get 20% off your ticket.

In exactly six weeks time, UX London is happening!

I am ridiculously excited about this year’s line-up—I can’t wait to see the talks and get hands-on in the workshops.

If you haven’t yet got your ticket, now is the time. There’s a flash sale this week: use the discount code FLASH20 to get a whopping 20% of any ticket. Do it before the end of Friday!

Whether you’re coming for all three days or choosing one focused day, you’re in for a treat.

• Day one on Tuesday, 10 June is discovery day.
• Day two on Wednesday, 11 June is design day.
• Day three on Thursday, 12 June is deliver day.

Head on over to the website to get all the details and then get your discounted ticket.

See you there!

For the past couple of years, myself and Jessica have been going to the Belfast Tradfest in the Summer. It’s an excellent event with great workshops, sessions, and concerts. And it helps that Belfast is such a lovely city to spend a week in.

What struck me the first time we were participating in workshops there was the great mix of age ranges. It always warms my heart to see young people getting really into the music.

Then I found out about their bursary sponsorship scheme:

For many young musicians, financial barriers stand in the way of this invaluable experience. Your support can make a real difference by sponsoring a bursary that covers the cost of tuition for a deserving student.

Last year, I decided to forego one month’s worth of donations to The Session—the contributions that help cover the costs of hosting, newsletters, geocoding, and so on. Instead the money went towards bursary sponsorships for Belfast Tradfest.

It was a great success that managed to cover places for quite a few young musicians.

So we’re doing it again.

Normally, I wouldn’t mention the ins-and-outs of TheSession.org over here on adactio.com but I thought you might like to partake in this year’s fund drive:

For the month of April 2025, any donations made to The Session will go towards bursary sponsorships for young musicians to attend workshops at this year’s Belfast Trad Fest:

thesession.org/donate

Maybe you’ve liked something I’ve written here. Maybe you enjoyed Resilient Web Design, the free book I published online. You can also read HTML5 For Web Designers and Going Offline for free now too.

I’ve never asked for any recompense for my online ramblings, but if you’ve ever wanted to drop me some money to thank me for something I’ve put out there, now’s your chance.

Any contribution you make will go towards fostering the next generation of traditional Irish musicians, something that’s very dear to my heart.