Marcin’s history of “molly guards” in hardware and software:
Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.
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!
There are two wolves inside you…
My Builder side won’t let me just sit and think about unsolved problems, and my Thinker side is starving while I vibe-code. I am not sure if there will ever be a time again when both needs can be met at once.
There have been so many advances in HTML, CSS and browser support over the past few years. These are enabling phenomenal creativity and refinement in web typography, and I’ve got a mere 28 minutes to tell you all about it.
I’ve been talking to Rich about his Web Day Out talk, and let me tell you, you don’t want to miss it!
It’s gonna be a wild ride! Join me at Web Day Out in Brighton on 12 March 2026. Use JOIN_RICH to get 10% off and you’ll also get a free online ticket for State of the Browser.
In an age of abundance, restraint becomes the only scarce thing left, which means saying “no” is more valuable than ever.
I’m as proud of the things I haven’t generated as the things I have.
Generated code is rather a lot like fast fashion: it looks all right at first glance but it doesn’t hold up over time, and when you look closer it’s full of holes. Just like fast fashion, it’s often ripped off other people’s designs. And it’s a scourge on the environment.
I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.
I really enjoyed this chat with Marc:
I recently sat down with Jeremy Keith for a spontaneous conversation that quickly turned into a deep dive into something we both care a lot about: events, community, and why we keep putting ourselves through the joy and pain of running conferences.
People use “enshittification” to describe platform decay. What I’m describing here is one of the mechanisms that makes that decay feel personal. It’s the constant conversion of your attention into a KPI.
A fascinating talk looking at the history of the intersection of knitting and stitching with wartime cryptography and resistance.
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!
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:
select and the friends we made along the wayTickets 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.
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.
The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
That was the hard part when programmers were punching holes in cards. It was the hard part when they were typing COBOL code. It was the hard part when they were bringing Visual Basic GUIs to life (presumably to track the killer’s IP address). And it’s the hard part when they’re prompting language models to predict plausible-looking Python.
The hard part has always been – and likely will continue to be for many years to come – knowing exactly what to ask for.
Maureen has written a really good overview of web feeds for this year’s HTMHell advent calendar.
The common belief is that nobody uses RSS feeds these days. And while it’s true that I wish more people used feed readers—the perfect antidote to being fed from an algorithm—the truth is that millions of people use RSS feeds every time they listen to a podcast. That’s what a podcast is: an RSS feed with enclosure elements that point to audio files.
And just as a web feed doesn’t necessarily need to represent a list of blog posts, a podcast doesn’t necessarily need to be two or more people having a recorded conversation (though that does seem to be the most common format). A podcast can tell a story. I like those kinds of podcasts.
The BBC are particularly good at this kind of episodic audio storytelling. I really enjoyed their series Thirteen minutes to the moon, all about the Apollo 11 mission. They followed it up with a series on Apollo 13, and most recently, a series on the space shuttle.
Here’s the RSS feed for the 13 minutes podcast.
Right now, the BBC have an ongoing series about the history of the atomic bomb. The first series was about Leo Szilard, the second series was about Klaus Fuchs, and the third series running right now is about the Cuban missile crisis.
The hook is that each series is presented by people with a family connection to the events. The first series is presented by the granddaughter of one of the Oak Ridge scientists. The second series is presented by the granddaughter of Klaus Fuch’s spy handler in the UK—blimey! And the current series is presented by Nina Khrushcheva and Max Kennedy—double blimey!
Here’s the RSS feed for The Bomb podcast.
If you want a really deep dive into another pivotal twentieth century event, Evgeny Morozov made a podcast all about Stafford Beer and Salvadore Allende’s collaboration on cybernetics in Chile, the fabled Project Cybercyn. It’s fascinating stuff, though there’s an inevitable feeling of dread hanging over events because we know how this ends.
The podcast is called The Santiago Boys, though I almost hesitate to call it a podcast because for some reason, the website does its best to hide the RSS feed, linking only to the silos of Spotify and Apple. Fortunately, thanks to this handy tool, I can say:
Here’s the RSS feed for The Santiago Boys podcast.
The unifying force behind all three of these stories is the cold war:
The core idea of the event is to get you up to speed on the most powerful web platform features that you can use right now. I love that because it aligns perfectly with what I’ve been working on over the last couple of years: finding ways to break old habits to get the most out of CSS.
Here’s the schedule for Web Day Out—what a fantastic collection of talks!
| 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!
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:
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!
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.
Can you ship AI-generated code without creating a maintenance nightmare six months from now? Can you debug it when it breaks? Can you modify it when requirements change? Can you onboard new engineers to a codebase they didn’t write and the AI barely explained?
Most teams haven’t realized this shift yet. They’re optimizing for code generation speed while comprehension debt silently accumulates in their repos.
One team I talked to spent 3 days fixing what should have been a 2-hour problem. They had “saved” time by having AI generate the initial implementation. But when it broke, they lost 70 hours trying to understand code they had never built themselves.
That’s comprehension debt compounding. The time you save upfront gets charged back with interest later.