I landed on a live studio recording of Seth Lakeman performing Rollback the Years from the 2025 album The Granite Way. I’m a sucker for raw vocal harmonies, and when they kicked in toward the first chorus, I felt tears in my eyes. When I heard the line “Roll the years back to a life we once knew”, I felt something more.

Coming from an organic oral tradition literally meaning “of the people”, folk music is one of the most raw and human-centred genres of music. Folk music has always served as an expressive way to tell stories, share ideas, or protest. When people couldn’t read or write, folk music was a way to communicate. Folk music is about community, hardship, adventure, love, heartbreak, the human condition.

Skipping ahead in the video, I found an excerpt of a track Lonesome Woods by Hannah James and Toby Kuhn. The opening of the recording features voice, cello and body percussion. There was something very profound that struck me about this track. The arrangement was so simple, yet Hannah’s bare feet on the wooden board and the sound of her hands on her own skin coupled with her silky voice and a single cello made the whole experience feel incredibly raw and real. I felt like I was there with them in the forest clearing. And then the opening lyrics of this track started to make a lot of my feelings make sense.

Through lonesome woods I took my way. So dark so dark as dark could be. The leaves were shivering on every tree. Oh don’t you think that griefs me.

And then, nearing the Golden Ratio of the track, Hannah and Toby are on the top of a hill. Hannah has an accordion now and she's playing her wooden board with shoes on, and they’re playing together, facing each other, and smiling infectiously, fully enjoying this moment of human-centred expression in the sun and the wind. And I wished I were there with them to experience it. And then I cried.

And then I thought for a while. I took myself on a walk. And I thought some more. And then I was able to put into words what I was feeling.

After clicking on this random link shared on the internet on a normal Thursday, I had uncovered a deep grief. A deep grief about how the technology industry has become so abhorrently hostile to the human experience that it has inadvertently distracted me from real and true humanity held deep within art and music; a deep grief borne from realising I thought I’d lost one of the founding concepts of my identity since I first touched a piano at the age of five. I felt all of this even though I am actively engaging in playing music every day.

I think I am in an abusive relationship with the technology industry. Yes, this is probably about AI. Stay with me.

Last week I spoke to a very good friend of mine who works as a senior software engineer. They told me that they don’t really write code anymore as part of their job; they only talk out loud to Claude. This surprised me. They also said that now they feel like an administrator rather than a software engineer — someone who merely assigns and reviews tasks — and, despite feeling “more productive”, they also don’t feel that good about the whole thing.

But I felt something weird during this conversation. Given I was surprised that this friend had seemingly embraced using AI day-to-day, and given how much I respect them, I suddenly felt like I should be doing the same. I started questioning my worth, my value, my productivity. Don’t get me wrong, I’ve tried using AI in my day-to-day activities, albeit very lightly. Given the type of work I do, it would be remiss of me not to explore the options. But there’s a deep discomfort that comes with me reaching for generative AI, not least because I have never been able to generate very good results.

Anyway, here’s where the abusive part comes in.

You simply cannot breathe without seeing, hearing, or engaging in any kind of technical conversation about AI. AI has dominated the Zeitgeist so catastrophically that the only way to escape is to turn off the WiFi and delete all the apps. Every single piece of fucking software has some kind of shitty AI add-on, forced into your face at regular intervals whilst you’re trying to go about your life or do your job or check your email or write an email or read an email or talk to a human support agent or read a recipe or open an issue on an open-source project or watch a YouTube video or open your IDE or do a fucking internet search. The cognitive overload of AI trying to Make You More Productive™️ whilst you’re actually trying to be productive is so shockingly absurd. And yet, we are being made to feel like we are stagnating, being left behind, not good enough, that we are luddites should we not adopt this imposing technology. We are being told we’re missing out, even though we’re probably doing just fine. The technology is gaslighting us.

This week, I spoke to another friend about how their company is now mandating AI usage for all employees. There is no reason for this mandate, only that someone who knows someone said that at another company where everyone adopted AI they were able to fire all the software engineers and make bank. So if I’m reading this correctly, the message is: “You must adopt this tool, or you will be fired. But we’re going to fire you soon anyway. Good luck.”

I do not enjoy using generative AI. Not only because have I seen few benefits for me personally. Not only because has it ruined the experience of trying to search for accurate and reliable information. Not only because of the way the chat-bot-style LLMs are built to project some kind of sickening quasi-human personality. Not only because mandated generative AI use is burning out my friends. Not only because this technology has caused numerous people to die. Not only because AI is draining water from areas that need it most. Not only because billions of dollars are going directly to AI organisations whilst millions of humans exist in poverty. Not only because using AI is an incredibly lonely experience where human collaboration and conversation has been replaced by weird conversations with computer algorithms. Not only because of the implicit bias generative AI displays as a result of the data it was trained on. Not only because people are doing some really weird things with AI like trying to sell apps that keep your dead relatives “alive”. Not only because apparently AI performs better when you threaten it. Not only because the pivot to AI has wrongly centred the worker value conversation around how much an individual can do rather than what they can contribute (not much has changed since I wrote this article almost a year ago).

I just enjoyed my work better when I wasn’t bombarded by a single piece of technology 24 hours a day seven days a week, that seems to have very, very bad implications for humans and the planet, actually. I'd rather go back to the era of the JavaScript framework debates.

What’s even more personally terrifying: what if I need to find a new job in the near future? There are seemingly no non-generative-AI-centred options left for someone like me. I’m afraid that every opportunity will either be for a company building some kind of generative AI experience, or one that mandates the use of generative AI in your daily responsibilities, or one that refuses to use AI at the expense of their financial success and the stability of my employment. At this point I cannot escape. I am at the mercy of the profession I chose. I have a family to feed and a mortgage to pay. Retraining is not an option right now. I must force myself to adapt.

And what will the future look like when this time comes? Will the industry’s mass cognitive decline be so far gone that none of this will matter anyway?

Through lonesome woods I took my way. So dark so dark as dark could be. The leaves were shivering on every tree. Oh don’t you think that griefs me.

Anyway. All of this is to say that I would like you to go and listen to some folk music today.

Video essay version

I’ve always been on the fringes of open source; I’ve contributed to a few projects here and there, such as the Astro docs, Google Lighthouse, and some others, and most of my code on GitHub is open source for the wider community. But, contributing to open source projects can be scary: big codebases, unfamiliar tech, lots of new people, and a sea of open issues can make it hard to know where to start.

However, open source isn’t really all about code, it’s about community. Since my involvement in npmx, I’ve experienced first-hand what a welcoming and inclusive approach to open source can do to empower anyone to make a variety of contributions to help make The Web ecosystem a great place to be and work.

And so, with that experience and some great examples of what good looks like in open source, and because npmx just announced their alpha release, I thought I’d put together a guide on how to get involved in open source to help you get started.

Throughout this guide, I’ll be using some specific open source terms. Here's what they mean:

• Open source: a software development model that encourages open collaboration, with source code, documentation, and discussion around the development of the project freely available to the public.

• Issue: A ticket used to track bugs, features, questions, or tasks.

• Pull Request (PR): a request to merge any changes into the main project, and to review and discuss those changes.

• Maintainer: a key contributor to the project who leads, manages, and steers the direction of the project. Maintainers are responsible for reviewing and merging pull requests, managing issues, and taking care of the community, usually acting as the final decision-makers. Some maintainers may also be called stewards.

• Contributor: anyone who has contributed anything to an open source project, whether it is code, documentation, testing and reviewing pull requests, design, finding issues, community management, or anything else related to the project.

Where this guide provides specific examples on things such as pull requests and issues, the examples will be specific to GitHub, as that's where all the action is happening for npmx.

1. Find a cool project

The first step is to find a project that you are excited about. Maybe it’s a library or tool you already use that you want to help improve, or perhaps its a project that you really want to see succeed, or it could be that some of your friends are working on something fun.

Your interests matter more than the popularity of the project, and your time is valuable. If you care about the problems that the project is solving, you’ll be more motivated to contribute and invest more of your time in the project.

Making ten contributions to a single project is much more valuable for you than making ten contributions to ten different projects.

And don’t worry if you don’t feel like you’re unqualified to contribute: you are.

2. Read the community guidelines

Before making your first contribution, look for the project’s community guidelines or code of conduct. You can usually find this type of document in the root of a project repository, named CODE_OF_CONDUCT.md or similar.

A code of conduct should help you understand what you can expect from the community: how people treat each other, how conflict is handled, and what behaviour is encouraged or discouraged. A great example is the npmx code of conduct, outlining the community’s standards and the responsibilities of the project maintainers.

If your chosen project doesn’t have a code of conduct or community standards, you might consider skipping it. That being said, your first contribution could be to create these community standards from one of the many templates available. If you’re comfortable agreeing to the code of conduct for your chosen project, move on to the next step!

3. Browse closed pull requests

Take a look at some closed pull requests to help you understand more about the project culture and direction, and how maintainers and contributors work together. It will also give you an idea of how the community standards are being upheld. Some questions you can ask yourself:

• What kind of work is being contributed?

• Are reviews kind and constructive?

• How are mistakes or incomplete work handled?

• If the project is busy, how are multiple pull requests addressing the same issue handled?

• What’s missing from contributions?

If you’re browsing a project on GitHub, you can find the closed PRs by navigating to the pull requests page, and filtering by closed.

4. Check the contributors list

Next, take a look at the contributors list. A healthy and active project often has:

• Many contributors (not just one or two people doing everything)

• Recent activity

• A visible breadth of contributors

While you can’t conclude everything from avatars and usernames, immediate visual diversity can be a strong signal that the project is welcoming to all kinds of people. This, in my opinion, always makes for a more exciting project to get involved with. It's been really wholesome to see how many contributors have been working on npmx so far.

5. Explore open issues

Exploring open issues will help you get an idea of what needs to be worked on. Issues may be bugs, tasks, larger feature requests, or discussions about ideas that are not yet set in stone. Project maintainers will often use helpful issue labels to categorise issues based on skills or areas of the project. When you’re just starting out, it’s a good idea to look for issues with the label good first issue, or you could filter issues by your area of expertise.

For example, when joining a new project, I often use the issue filter to surface good first issues, or issues labelled front or front end, a11y or accessibility, or docs, as those are my areas of expertise. Another good label to look for is help wanted, as this type of issue is usually more of a discussion around planning an approach to solving a problem.

For your first contribution, I recommend choosing a small, low-lift issue. A lot of the time investment when making your first contribution is taking time to understand the code or the documentation, learning the process of contributing, and ultimately, building relationships with other contributors and maintainers as you move through the process. Choosing a smaller issue means less cognitive overheads for you, and more opportunity to make a meaningful impact. For example, my first contribution to npmx was a pull request to fix the alignment of the logo in the header. This pull request fixed a very small issue that was reported by another contributor that allowed me to open my first pull request with minimal effort.

In a very active open source project, there may be multiple open pull requests that address the same issue. This could feel a little daunting at first (and it’s sometimes tricky for maintainers to manage), but it’s usually not a big deal and can be managed effectively. If you’re worried about this and don’t want to attempt something that is already in progress, GitHub helpfully identifies which issues have open PRs on the issues list with an icon, which I’ve highlighted on the image below.

6. Read the contributing guide

When you’ve found an issue you’d like to make a contribution for, it’s time to understand how the process works. Well-maintained open source projects will have a contribution guide in the project, which you can usually find in the root of a project repository, named CONTRIBUTING.md. A contributing guide is usually geared towards contributing to code or documentation, and will include instructions on how to set up the project, maintaining a consistent code style, testing, and how to format your pull requests.

If you get stuck or notice something confusing or outdated whilst you’re trying to set up the project, you may have found your first opportunity for a contribution! In fact, when setting up the npmx project, I wasn’t sure how the code formatting worked because it wasn’t clear in the contributing guide. And so, after discussing with other maintainers, I opened a pull request to clarify how code is formatted.

7. Chat with the community

Many projects have a Discord, Slack, or other space for chatting with the community, which will usually be linked somewhere in the project repository or in the project itself. If you want help or just want to chat about the project and what issues would be good to tackle, it’s a great idea to join one of those spaces. It’s also a good opportunity to check that the community standards are being upheld and that you feel welcomed by the maintainers and contributors when you join.

Also, don’t feel like you need to jump in and get involved straight away. It can be daunting to jump into an active chat stream of people who are actively working on a project. Take your time, and do a little lurking until you feel comfortable enough to take part.

8. Open a pull request

If you’ve found an open issue and you know how to tackle it, you can usually do the work and open a pull request without asking for it to be assigned to you. That being said, in a very active project it is always helpful to leave a comment on an issue stating that you intend to work on it.

Communication in open source is key, especially with many people working asynchronously on a project across multiple time zones, day and night. But on the other hand, a very active project can feel very noisy and overwhelming, and more often than not, maintainers will appreciate your initiative when it comes to direct contributions, rather than the extra admin of assigning people to issues, and the extra time it takes for contributors to wait for permission.

To open a code-based pull request, fork the repository to your own GitHub account using the fork button on the main page of the repository, and clone your fork of the repository to your local machine.

When you've cloned the repository to your local machine, create a new branch off of main to make your changes. When you push those changes to your own GitHub fork, you'll see a banner at the top of your repository page with a "Compare & pull request" button.

Click this button to write a title and description for your PR, making sure to follow the contributing guidelines. Then, click "Create pull request". In an active project, you probably won't need to message the maintainers to notify them that you've submitted a PR, as they'll be watching for pull requests coming in. I know you're probably really excited to make your first contribution, but be patient in waiting for a review and approval!

9. Not every PR needs an issue

If you spot a typo, a small refactor, or an improvement worth making, you can propose it directly with a PR rather than creating an issue. Make sure to include a clear description of the change and why it’s useful, especially if it’s your first contribution. Even if your pull request is not accepted, you’ve practised the contribution workflow, so you’re ready for the next issue.

Even if someone else submits a similar PR before you, your work won’t be wasted. Maintainers may still merge your pull request, borrow ideas from it, or use it to improve the final solution. This happened to me on an early PR for npmx, where I made a small change to the Open Graph images for the package pages, which will eventually be superseded by a full redesign of the Open Graph images across the project.

10. Not every contribution has to be code

In open source, all contributions are valuable, whether or not they make it into the project codebase or documentation. Finding and reporting issues, requesting or suggesting features, reviewing and testing pull requests, opening PRs that don’t get merged, updating documentation, and welcoming people into the community are all valuable ways to get involved. Participating in open source projects gives you a wealth of opportunities to use your existing strengths, or learn new skills to add to your experience.

Get involved

In my experience, open source really is about humans, rather than code. Open source projects have huge potential to bring people together and solve problems for the people that work on The Web, making the ecosystem (and, optimistically, the world) better for everyone to benefit.

If you’re looking for a great open source experience to get involved in, I would highly recommend the npmx project, who welcomed me with open arms from the outset. Find an open issue, give it a try, and join us in the npmx Discord to experience a truly wholesome community approach to building great tools for The Web. Start small, and have fun!

However, many of the songs I've wanted to learn over the years have been impossible to find transcriptions for; most drum transcription sites tend to hold catalogues of the rock classics in bulk, rather than niche jazz performances by emerging artists, for example. There's also an increasingly frightening amount of "AI generated drum transcription tools" surfacing on The Internet, and we all know how useful that's going to be (not useful). And so, I took to transcribing the songs I wanted to learn myself.

It turns out (according to my drum teacher), that I'm pretty darn good at transcribing drum tracks, and I really enjoy it. Slowing the tracks down using the Amazing Slow Downer, carefully listening to the intricacies of the part, and translating it to a written score has given me a deeper insight into a variety of playing styles and techniques, and as a result it's really helped improve my playing. At some point I thought to myself: I can't be the only one searching for these weird and obscure songs to play drums to, right?

And so, I decided to put my drum transcriptions on The Internet, on a brand new Website of their own, for everyone in the world to enjoy.

Today, I'm releasing DRUMSAUCE, a catalogue of free PDF drum transcriptions, created by my own human ears and hands.

About the website

The website consists of five main areas. The home page shows the three latest transcriptions, there's a transcriptions area, which currently shows all transcriptions (there are only three so far!) but will need some categorising, searching and filtering at some point, but I didn't want to over-engineer it too soon. There's the single transcription page, such as Painted Lady by Salin which contains the album cover art, a preview of the first page of the PDF, a download link, and an embedded YouTube video. There's a little about page, and finally, a request form where you can make a transcription request. Additionally, if you're into RSS feeds, you can also subscribe to the DRUMSAUCE RSS feed!

The tech

Honestly, I don't want to talk too much about the tech behind the website, because ultimately it doesn't really matter. I used a framework to create a static site (and the astute among you will inspect the DOM to see what framework that is, or you know, stalk me on GitHub), and I deployed it to a well-known deployment platform that has support for forms.

However, I will mention that pdfjs-dist is a great little library for working with PDFs on the web, and it's what powers the PDF preview on the transcription pages. I thought about using an image as the preview instead, but I didn't want to create too much extra effort for myself when adding new transcriptions to the site. All I need to do when adding a new transcription is:

• add a new object to a data.json file that contains an array of transcriptions

• find the MusicBrainz release ID for the track

• upload the new pdf to the repo

Regarding the MusicBrainz release ID, I use this to show the album cover art for the transcription. Ideally, I wouldn't be requesting resources from random third-party remote servers. However, I did this to minimise effort on my part. When the list of transcriptions fills up, this may have to be revisited.

You can just make stuff

It's bewildering to think that in the 19 days since I wrote my (not) a 2025 wrap up post, where I bemoaned ungraciously that I had zero time for creative projects, I completely redesigned my website and launched a whole new project. I guess this is my rebellion era.

p.s. I also made a website for guitarists in 2020.

The fashion industry has trained us to think that the only way to feel stylish is to buy something new. Indyx breaks that fast-fashion cycle by celebrating the closet you have and teaching you how to shop smarter for things you love and will actually wear.

Prior to 2025, I had only used Indyx to catalog my wardrobe and keep track of everything I owned. But I didn’t really understand how I utilised my wardrobe, and whether everything I had was serving me. And so, on 1st January 2025 I decided to start tracking every single item and outfit I wore for the entire year to see what secrets it would unfold.

My tracking goals

I love my clothes, and I love fashion as a vehicle for self-expression and exploration. But, since my teenage years I have had the tendency to impulse-buy individual items on a whim without any thought to how wearable those items are with the rest of my wardrobe. I also have a track record of impulsively reinventing myself through the vehicle of clothing over and over again, which manifests in selling most of my current wardrobe and purchasing new or second-hand things to replace them in a completely different style. I’ve experienced this cycle a number of times in my adult life. More sensible people will ensure that new purchases can be worn with existing items before they hand over their hard-earned money, but I was never really a sensible shopper. I wanted beautiful things, regardless, and I wanted them now.

With all that said, my goals with regards to tracking everything I wore in 2025 were an attempt to curb this cycle of behaviour, and address three main goals:

• I wanted to buy less

• I wanted to wear more of what I had

• I wanted to understand how I utilised my wardrobe

Adding items and oufits to the app

Adding items to the Indyx app is pretty straightforward. Either upload an image or take a photo of an item laying flat, and the app will remove the background to make it look as good as possible. I prefer to add official product images to the app, because they look better all lined up together, but where I couldn’t find a flat-lay official product image, I took a photo (I still don’t like how these look).

When you add an item, there are a bunch of other optional details you can fill in, such as whether the item was second hand, the date you acquired it, colours, tags, and the price you paid. When you add a price, Indyx calculates the “cost per wear” based on how many times you wore an item. When using the app for the first time in 2023 and cataloguing all items, I wasn’t often sure of the purchase dates, so I opted not to add any dates for any of the items, which is why the image below states that I wore these boots 44 times in 0 days. An improvement I would like to see here is for the acquired date to fall back to the date the item was created in the app.

All of this cataloguing is quite a lot of admin, and I the only thing I have found useful is how many times I wore each item. I never need to filter items by colour, for example, because most of my items are black.

All items are available to view on the main screen, where you can search and filter items or customise the view (which is behind an Insider subscription, for some reason). You can also create collections of items, which have been really useful when deciding what to pack without looking through your wardrobe for all the work travel I did in 2025.

You add outfits in a separate area of the app, and you can arrange and resize items to your liking on the canvas.

How tracking works

You can track items and/or outfits you wear by clicking on the calendar icon at the top right of the main screen, clicking on the day, and selecting items and outfits. You can also add a selfie of your outfit each day, but I didn’t decide it was useful for me; it was also a little annoying to have to skip the mandatory selfie screen each day. Given you may add a number of outfits or items per day, you can also choose a specific item or outfit to act as the cover image for the calendar view.

What I tracked

Given I work from home and sometimes don’t leave the house in a day, I added a base outfit first thing in the morning, without any accessories such as shoes or outerwear. I always wear a necklace, but I didn’t add jewellery to the outfits to avoid having to create a whole separate outfit if I decided to wear a different necklace with the same base outfit one day.

Alongside the base outfit, I added other single items such as shoes, coats and jewellery as I wore them on any particular day. Most days I would select an existing outfit or create a new outfit after I’d got dressed, and as I got ready to leave the house, I would make sure I added the coat, shoes, bag or any other accessory that I decided to wear. When I went out-out, such as for a special occasion or travel for a work trip, I tracked the full outfit including all accessories, shoes and outerwear. I’m not sure of this logic or why I chose to do it this way.

All of this admin was inconvenient at first, but it quickly became muscle memory to keep track of everything as I wore it. The only thing I didn’t keep track of were gym/yoga outfits, but I did keep track of when I got changed during the day, such as when I changed into more comfortable clothes such as hoodies and tracksuit bottoms in the evening after work.

What I learned

Honestly, the only new thing I learned was the total estimated cost of my wardrobe, which I had been ignoring for a very long time. Given this number accumulated over many years, however, I’m not even sure it’s that important.

Was it worth it?

We only have so much time in a day. If I added up all the time I spent clicking around in Indyx to catalogue clothing, finding a good official flat lay product image on The Internet and adding all the required meta information to each item, putting together outfits every morning that didn’t already exist, and cataloguing items each time I put on a jacket and shoes to leave the house or when I put my lounge clothes on after work, maybe I could have read a whole book, or, you know, just had a little bit more time to relax in a day.

Did I buy less?

Qualitatively, I feel like I curbed my impulsive buying somewhat. One of the main catalysts for this was that when I found something I liked, I could look through the app to see if I had something similar, and I usually did, so I didn’t buy the new thing. Also, at the end of December, I did my six-monthly wardrobe spring clean, where I take everything out, decide if items are still serving me, give the wardrobe a vacuum to get rid of the accumulated dust, and put it all back in again. Usually, my bi-annual clear outs involve a lot of selling and donating, but this time, I only wanted to get rid of one oversized sweatshirt (because it really wasn’t the right colour for me, and it was really very too big), which I actually just gave to my husband.

Quantitively, the data also shows good results in the area. Given I’ve been tracking the cost of each item in the app since 2023, the data shows in 2025, I spent 45% less than in 2024, and 20% less than in 2023. Whether this is a result of tracking in the app, a result of wanting to be more intentional in how I curate my wardrobe, or a bit of both, is unclear.

Did I wear more?

I didn’t realise this in 2025, but I actually feel like I have more flexibility in what I wear since I stopped tracking on 1st January 2026. Looking back, I feel like I wore less of my wardrobe over the year, or at least fewer combinations of items. If I was in a rush and I didn’t have the time to create a new outfit in the app, I would instead reach for an outfit that already existed in the app so I could assign it to the day in a couple of clicks, rather than wear what I actually wanted to wear. In hindsight, tracking everything constrained my creativity and expression a little.

Do I understand how I utilised my wardrobe?

As is seemingly tradition for many tech companies these days, Indyx provided a “wrapped” at the end of 2025, which consisted of a few slides of how you used your wardrobe. At the time of writing I cannot access my wrapped again, but all I can remember is that I wore around 2% of all possible 11k+ outfit combinations (I’m not sure how this is calculated but surely I don’t possess 11k+ sensible outfit combinations), and that my most worn item is my black belt, which I wore 118 times since I bought it in on sale in summer 2025, and it came in at 31p per wear.

With regards to usage tracking, which you only have access to with an Insider subscription (which is currently £60 a year), the data hasn’t proved that useful. This is mainly because it doesn’t provide any actionable insights, and I’m not sure that it can. The composition data is just data and I’m sure is pretty representative of any standard wardrobe.

The utilisation statistics are encouraging, though. Indyx describes (in the question mark tooltip) how utilisation is calculated: “Items that were logged to your calendar at least once in the defined period divided by the total number of items in your wardrobe. A higher % means that you’re actively wearing more of your wardrobe.” According to this data, I wore 90% of my wardrobe in 2025, which, despite not wearing things because I couldn’t be bothered to log them to the app, and feeling like I didn’t wear as much of my wardrobe, is actually pretty good going.

Final thoughts

I feel pretty accomplished in that I achieved my goal of tracking everything for a whole year, that I spent less on clothes in 2025, and that I wore 90% of my wardrobe during the year. Again, I’m not sure than the latter two achievements are entirely related to tracking everything in Indyx, but it probably was contributing a factor.

Would I do something like this again? Probably not. For the last 11 days, I’ve felt so free not having to track everything in the app, but I also can't help feeling like I’ve forgotten to do something throughout the day, given tracking items became such a big part of my daily routine in 2025.

All in all, I think I can say that I achieved my wardrobe-related goals of 2025. I bought less, I wore more (even though it didn’t feel like it), and I understood how I used my wardrobe, even if the data didn’t give me any actionable insights.

I say rebuild and not redesign because I started to actually rebuild my website in Nordcraft, given it’s always beneficial to dogfood the products you are working on. However, my current website repo received its first commit in Jan 21 2022 and has received 986 commits since. It is home to a huge variety of content, it has been a personal labour of love of mine, and rebuilding it from the ground-up amidst all my other priorities felt extremely overwhelming.

Personal websites and the evolution of mine

At the start of the year, my friend Henry posted an incredible essay. In A Website To End All Websites: How to win the war for the soul of the internet and build the Web We Want, Henry urges us to build personal websites. More on this in a moment. But it was reading this article that inspired me to finally make my website what I wanted it to be in the way I wanted to.

Before the redesign, my website was extremely over-engineered and also messy in places, mostly due to how it’s been a playground for experimentation at work over the years. Whilst working at Contentful, Netlify and Sentry I frequently used my website to showcase features of those platforms, which often led to me building some very unnecessary things that no one used. Some of these features were cool, such as little banners based on the referring page powered by Netlify Edge Functions and the HTTP referrer header, but when I was laser-focussed on web performance at Sentry, I ripped all of those cool features out in the quest to get my Time to First Byte (TTFB) as low as possible. I even stopped using custom fonts.

After reading Henry’s essay, it dawned on me that my website was no longer as personal as it could be, given I had used it to do job stuff for so long. It had become a mish-mash of performance-hacking to the detriment of design and personality, a bloated wasteland of unvisited URLS such as the “blog posts filtered by topics” pages thanks to a GraphQL trick I wrote about at Contentful, a useless events page that merged my Twitch schedule and conference event entries from a CMS and localised the time for visitors using a Netlify Edge Function that got no traffic whatsoever, and it contained a very corporate article search powered by a post-build script that sent JSON to Algolia that no one ever used except me. And when I talk about the website being over-engineered, boy was it over-engineered. The only instances of hard-coded strings existed as page titles; every other bit of text came from the CMS. This constrained my creativity, especially when it came to the home page.

All this is to say that my website didn’t feel personal anymore. And so, this was the main goal of the redesign: to reclaim my personality on my own domain; to free my online home from the shackles of employment-based responsibility; to make something that was mine. Plus, the previous design was intended to be a marketing funnel for my Twitch channel (that’s literally the brief I gave Anatole) given that is what I was focussed on growing at the time. It sounds ridiculous now I type it out loud, but it made sense at the time. A lot of people discovered my website organically through links to my blog posts, and I wanted to make sure they knew I did live coding on Twitch. And now that I’ve retired from Twitch, it seemed fitting to evolve my website into the next thing.

In a true moment of clarity, thanks to Henry, I chose not to rebuild my website, but to redesign it; the tech stack is still Eleventy, Contentful and Netlify. I did it in a week. I lost sleep, I dreamt about coding, I bugged my friends for their thoughts and opinions and I couldn’t think about anything else. But I did it. (I also did it without a designer, which feels like a big deal for me. Maybe my years of experience are starting to pay off.)

As promised, I’d like to share some of the fun things I created in the redesign, and links to all the good articles that helped.

I started with a vibe

I started this redesign with a vibe based around my current Internet profile picture, which is a photo of me taken whilst speaking on stage at the What The Stack conference in Macedonia in September 2025. The talk I gave was set in 1995, and I was wearing a very excellent vintage shirt from the ‘90s to match the vibe. (Click here to watch the recording.)

The Shirt is at the heart of what this website redesign became.

The only solid plans I had for the design was to simplify the colour palette and use only #000 and #fff, the pink used on my previous design, and a complementary green. I was going for a kind of early 2000s punk/emo gig or music journalism vibe, with big bold lines, contrasting and seemingly chaotic fonts, and grunge-inspired textures.

For the grunge-inspired stuff, I used three little design details.

Distorted text using SVG filters

You’ll notice that some of the text on the page you’re reading is slightly distorted. Check out the active “Articles” link in the header, for example. This little text distortion effect is created using an SVG filter, which uses feTurbulence and feDisplacementMap. I’m using just one filter across the site for “design consistency” (whatever that means), which lives in the footer, so I can access it on every page.

Copy

<svg width="0" height="0" class="svg__filter">
  <defs>
    <filter id="distort">
      <feTurbulence 
	      type="turbulence" 
	      result="noise" 
	      numOctaves="1" 
	      baseFrequency="0.01 0.01"></feTurbulence>
      <feDisplacementMap
        in="SourceGraphic"
        in2="noise"
        scale="6"
        xChannelSelector="R"
        yChannelSelector="R"></feDisplacementMap>
    </filter>
  </defs>
</svg>

To apply the SVG filter to an element using CSS, you can use the filter property. For example, here’s how I add the filter to the active link in the header. Notice how the id attribute given to the SVG matches the value of the url value.

Copy

[data-active="blog"] {
  filter: url(#distort);
}

For a more in-depth read about distorting text with SVG, I recommend reading this article by Henry Desroches.

High-contrast and halftone images

In order to maintain the grunge-inspired feel across the site, I wanted to stylise the images. I thought about getting rid of most of the images, for example on the cards on the list of articles, but the site needed some real-life colour, so I kept them in. An interesting Internet search led me to a very detailed article by Lean Rada on Creating a halftone effect with CSS.

Using this article as inspiration, I created my own halftone effect by creating an oversized pseudo element, and paired this with a CSS contrast filter and mix-blend-mode: hard-light to make the images really pop.

I built this as a mixin (yes, I’m still using Sass), and included it anywhere I needed it.

Copy

@mixin half_tone {
  overflow: hidden;
  filter: contrast(150%);

  &::before {
    content: "";
    top: -50%;
    left: -50%;
    right: -50%;
    bottom: -50%;
    position: absolute;
    transform: rotate(20deg);
    background: radial-gradient(circle at center, #000, #fff);
    background-size: 0.15em 0.15em;
  }

  * {
    mix-blend-mode: hard-light;
    object-fit: cover;
  }
}

Where I didn’t use the halftone effect on images such as the home page and about page, I used a CSS contrast filter set to 200%.

Textured backgrounds

Some of the solid colour backgrounds needed a bit of texture to either make things stand out a bit more in the foreground, like the hero section at the top of the home page, or blend more into the background, such as where you can see my photo and short bio on the blog article page. To generate the textures for these backgrounds, I used a Background Texture Maker by Alan Smith that generates CSS that uses a base64 encoded SVG to create a repeating background image. It also, coincidentally, uses SVG filters. This is the CSS I'm using for the background texture on the hero on the home page.

Copy

.hero__cloud__underlay {
  background-size: 150px 150px;
  background-repeat: repeat;
  background-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 150 150' xmlns='http://www.w3.org/2000/svg'%3E %3Cfilter id='noiseFilter'%3E %3CfeTurbulence type='fractalNoise' baseFrequency='3' numOctaves='2' result='noise' /%3E %3CfeColorMatrix type='saturate' values='0' result='grayscale' /%3E %3CfeComponentTransfer%3E %3CfeFuncA in='grayscale' type='linear' slope='0.4' result='updated' /%3E %3C/feComponentTransfer%3E %3CfeMerge%3E %3CfeMergeNode in='noise' /%3E %3CfeMergeNode in='updated' /%3E %3C/feMerge%3E %3C/filter%3E %3Crect width='100%25' height='100%25' opacity='0.46' filter='url(%23noiseFilter)'/%3E %3C/svg%3E");
}

What I also love about this background texture is that it works in both light and dark mode without needing to provide different background-image values based on the theme.

The vibes were received

When I showed a deploy preview to my friends, they understood the vibe; they got the memo. And the fact that I was able to communicate the vibe so clearly made me feel very accomplished indeed.

“I get mid-late 2000s punk flyer”

“Feels like a piece of London rock venue promotional material from ~2010 (complimentary)”

“This site makes me think of cheap rock punk gigs I used to go to when I was younger and I'm absolutely all for it”

Scroll trigger animations

On the home page I needed a bit of something something on scroll, and so I thought on larger screens it would be fun to horizontally scroll my name as you scroll down the page. I thought I could use CSS scroll-timeline for this, but I couldn’t get it to work very well. I either gave up too soon or this is not what scroll-timeline is for, so I opted to use the ScrollTrigger plugin from GSAP. I’ve never used GSAP before, but it’s been on my list to try since around 2015; it was about time.

The GSAP API is really intuitive, and it gives really smooth results. This is the code for the scrolling name that triggers if the prefers-reduced-motion preference is not set to reduce.

Copy

gsap.to(".hero__name", {
  x: "100%",
  ease: "none",
  scrollTrigger: {
    trigger: "html",
    start: "top top",
    end: "bottom top",
    scrub: true,
  },
});

I also had a little fun with moving and scaling the image of me at the time same, which also uses GSAP.

Copy

gsap.to(".hero__img", {
  scale: 1.2,
  y: "-20%",
  ease: "none",
  scrollTrigger: {
    trigger: "html",
    start: "top top",
    end: "bottom top",
    scrub: true,
  },
});

There are a couple of other little scroll trigger animations powered by GSAP dotted around the site as well.

View transitions

I started writing an article about cross-document view transitions a few months ago, and haven’t had time to finish it. Whilst researching for the article, I went extremely overboard with the page transitions on the previous design (regular readers might have noticed), so I toned it down in the redesign, whilst adding some stand-out details.

Default page transitions

This block of CSS adds a fade transition when navigating between pages. I tried providing a different animation-duration for prefers-reduced-motion but I really didn’t know whether the fade should be quicker or slower, so I only apply the view transitions when there is no-preference.

Copy

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }

  ::view-transition-group(root) {
    animation-duration: 0.4s;
  }
}

Hero image and name transitions

What’s nice about view transitions is that when they’re enabled, you can add a view-transition-name property to elements via CSS, and if the browser can match elements with the same property names across different pages, it will transition them automatically without any further configuration. I use this technique to move my name and image between the home and about pages.

Rather than messing around with any custom animations (which you can do, but I’ve found it to be a very tiresome process that doesn't always produce the same results every time), I used the default view transitions behaviour by just adding a view-transition-name to both the image and name banner to transition them between the pages.

Try navigating between the home page and about page to see how powerful this little block of code is. This is all I’m using in the way of view transitions for the hero name and hero image, coupled with the view transition activation code above.

Copy

/* home page */
.home__hero__name {
  view-transition-name: hero-name;
}

.home__hero__img {
  view-transition-name: hero-img;
}

/* about page */
.about__hero__name {
  view-transition-name: hero-name;
}

.about__hero__img {
  view-transition-name: hero-img;
}

Article title transitions

I also use the default view transition behaviour on article headings, so when you click on an article card, the article title transitions to the top of the page on the article layout. Given each view transition needs a unique name, this needed to be done inline on the element itself. Luckily, each of my articles coming from the CMS has a unique ID, so I used that to create a unique view-transition-name.

Copy

<!-- on the card component -->
<h2 class="card__title" 
  style="view-transition-name: heading-${item.sys.id}">${heading}</h2>

<!-- on the article layout -->
<h1 class="post__h1" 
  style="view-transition-name: heading-${post.sys.id}">${post.title}</h1>

The article layout

When I spoke at Front End North in July 2025, I was very inspired by a talk given by the wonderful Nils Binder titled Unwrapping Web Design, in which he challenged the audience to stop making the same old boring website designs we’ve been making since 2010 and think a little more creatively about page layouts. In the talk, Nils showcased some interesting layouts that used irregular grid column widths, and generally just got a little bit creative with the whole concept of a layout.

I have attempted to channel Nils’ advice in the new article layout on larger screens especially, which uses the following grid layout to try and break out of the two or three column standard.

Copy

.article {
  gap: 2rem;
  display: grid;
  grid-template-columns: 1fr;
  grid-template-areas:
    "title"
    "aside"
    "content"
    "author"
    "bsky";
  align-items: flex-start;
  flex-direction: column;

  @media screen and (min-width: utils.$post_breakpoint_md) {
    gap: 1rem;
    display: grid;
    grid-auto-columns: auto;
    grid-template-rows: auto 1fr auto;
    grid-template-areas:
      "title title author"
      "aside content author"
      "bsky bsky bsky";
    grid-template-columns: 2fr 6fr 2fr;
  }

  @media screen and (min-width: utils.$post_breakpoint_lg) {
    gap: 3rem;
    grid-template-areas:
      "bsky title title author"
      "bsky aside content author";
    grid-template-columns: 1fr 2fr 6fr 2fr;
  }

  @media screen and (min-width: utils.$post_breakpoint_xl) {
    grid-template-columns: 1fr 1fr 7fr 2fr;
  }
}

Showing Bluesky replies on blog posts

As well as showing Bluesky likes on articles, which I wrote about in 2024, I now show replies to that post as well. This was a bigger undertaking than I anticipated and involved much recursion to render embeds within embeds within embeds, and replies to replies to replies.

The code is a mess, but it was fun. I will do a full write-up of how I achieved it in due course, but the main takeaways were this:

• To have some level of moderation over the replies shown, I’m using an authenticated endpoint to fetch the replies as myself. This means I can hide replies on Bluesky that I don’t want to show on my articles.

• I’m fetching the replies client-side via a serverless function so they are always up to date. However, I am not sure how scaleable this will be. I managed to rate limit myself once during development when I had too many localhost tabs open, so I have a feeling this might happen on high-traffic articles. If this is noticeable, I’ll probably end up writing a daily cron job to save the replies to JSON in my website repo, which I’ll fetch from the client. Alternatively I could fetch the replies at build time, but that also means I’ll have to rebuild my website regularly (probably daily) in order for the replies to stay as up to date as possible. This also means that if I ever need to hide replies, I’ll need to run the cron job immediately. I don’t think I want this level of administration in my life.

• As a result of using a serverless function to fetch the replies data, there is no way to reliably cache an authentication token unless I use a separate service to store it. This means I am requesting an authentication token on every request for the replies. I don’t like this and this is why I am considering using a cron job to fetch the replies and store them at regular intervals.

• The above two bullet points are why I am delaying the full write-up of how I show the replies on my articles, because I want to find the best solution.

Overall, I love seeing the Bluesky replies under an article. There's something really wholesome about it.

Spotlighting my weird newsletter

In the previous design, I included a link to my newsletter on the home page and next to blog posts. However, this was just a link, and didn’t look very official. Yes, it’s supposed to be purposefully weird, but I guess that only goes so far.

My newsletter is powered by Buttondown, and they provide you with a block of HTML with a simple sign-up form that you can drop in anywhere on your website and style to your heart’s content. Now, interested readers can subscribe to my newsletter from any page directly. I also tell you a little bit more about what you’ll get with the newsletter. Scroll down and try it out, I dare you.

It’s done

Now that I’ve released the redesign, I’m looking forward to more sleep and more relaxed shoulders. Fixing up this website in just a week whilst doing a job and being a parent and going to yoga and practising drums and doing other things has been a wild ride, and I’m actually really happy with it. There are also some other things I’d like to add to the website, such as newsletter archives and some other little details, but that can wait.

If you’re now feeling motivated to redesign your website or make your first website(!), check out this list of human-made and human-curated personal sites for inspiration.

The world is your oyster. And so is The Web.

I’ve been regularly attending yoga classes since April 2025, and I’m very proud of attending a total of 58 classes in 2025. Yoga started as a way to explore a different way of self-care and recovery after a very difficult 2024 and start to 2025, but it quickly became something I gravitated towards, and made part of my regular routine. Slow flow or restorative flow sessions are my favourite. This type of session, comprising meditative sequences of asanas (postures) and reflective thinking has given me a new appreciation for the uniqueness and abilities of my body, has greatly improved my strength and flexibility (I can touch my toes for the first time in my adult life!), and has gifted me with the space to try and be truly present, to quieten my raging mind (to an extent), and to look inward to understand myself more.

Vinyasa yoga is one of the more dynamic styles of yoga, comprising an energetic flow of different movements, rather than more static yoga asanas. I took a few of these sessions in 2025, but every time I found myself fighting against it rather than embracing the practice. Today, I figured out why. As the teacher urged the class to keep pushing ourselves, to find more strength, to keep going, for just a few more breaths, all I could hear was my inner monologue screaming I’m fucking tired. Now, this could probably be attributed to the pre-menstrual full-body pain and desperate fatigue, for when I got home, the period goddesses descended upon me, but I also think it surfaced something else.

Vinyasa yoga reminds me of the relentlessness of life. Find more strength: just a few more breaths/minutes/hours/days/weeks. Keep going. Keep grinding, bro.

I don’t want to keep going. I want to rest. I want to recover. I’m fucking tired.

For a few weeks now, a 2025 wrap up post has been on my mind. It’s the thing you do when you’re a person on The Internet Who Has a Blog, after all. But I don’t want to write a wrap up post. I’m fucking tired.

I could talk about how at the start of 2025 I was in debilitating pain and thought I would never type again. I could talk about how I learned how to code with my voice as a result of this. I could talk about how I changed jobs and moved from Sentry to Nordcraft, and about all the educational videos I made and the 23 blog posts I wrote. I could talk about the seven conferences I spoke at, or the one I emceed at, and that I went to Denmark to visit the Nordcraft office three times, and about how all of the travelling completely burned me out and how I never want to leave my house again, at least in 2026.

I could also talk about how I decided to retire from streaming on Twitch to make room in my life for other creative things, and how my studio now feels horribly surreal and empty without my streaming setup, and how that makes me feel a deep sadness that I can’t quite articulate. I could also talk about how I have the most beautiful group of Internet Friends who I am truly grateful for every single day, and how our friendship blossomed after attending a conference together, and how we ate pie and mash on one of the hottest days of the year in the UK, and how they are so smart and so creative, and how privileged I am to be accepted, welcomed, and loved by them.

I could also talk about how I turned 40, and how I received some wonderful letters from people on The Internet to mark the occasion. I could also talk about how I sent the 100th issue of my newsletter, and how I surpassed 500 subscribers, and how much of an achievement that feels like.

I could also talk about my wonderful child, who challenges me to be more patient and compassionate and loving every single day. I could talk about how he is eight years old now, and going through some kind of separation anxiety phase, where he knows he doesn’t need me as much anymore, but he still wants to need me, and as a result I have no time in the evenings to truly relax or indulge in the right headspace to be creative, because he won’t go to sleep until I do. I could also talk about how his school schedule is so demanding I wonder if the school leadership ever consider that parents actually have jobs and other conflicting responsibilities when they request my attendance at all manner of afternoon soirees. I could talk about how I have to turn up, how I have to be there for him, because the look on his face when he finally picks me out in a crowd of people is something I cherish.

I could talk about all the creative things I have done this year, except I haven’t had the time, energy, or space to do many. I could talk about how my second very large cross stitch is almost complete after 18 months of working on it. I could talk about how I resumed my drum lessons in September after taking a break for a year, and how that has truly reenergised me. I could talk about how I find time to play the piano here and there, and how I recorded a couple of performances for the group chat that were enjoyed and well received, and I could talk about how I started to create so many new pieces of music by noodling on the piano and writing a cool idea on a scrap of paper that were subsequently abandoned because I didn’t feel like anything was fucking good enough. I could talk about how I’m aching to create music again, how I have so many ideas in my head I can’t sort through them in any meaningful way, and how I am just yearning for the space and time and energy to just fucking make something.

I could also talk about how I’ve been trying to rebuild and redesign my website, and have been doing so since April 2025, and how I have absolutely zero time to sink into this because work is so incredibly busy and also I’m fucking tired. I could also talk about all the other ideas I’ve had for websites and side projects, and how I feel a constant lingering sense of guilt and failure that I have manifested absolutely nothing I truly wanted to. I could talk about how maybe 2026 could be different, but how it’s very hard to visualise right now, because I have a very busy first quarter of 2026 coming up at work where I am creating a new video course. I could talk about how I’ll be making around 50 videos, and how it’s all rather stressful and awkward timing-wise because in February I am having major mouth surgery, and I won’t be able to speak properly for a few weeks, and you definitely don’t want to see me on camera with a fat swollen face.

I could also talk about how 2025 has been a disgusting year for the world, in particular the technology industry, and how fucking AI has invaded every fibre of our online experience, and how no one whatsoever wants this, but we just have to accept those fucking AI sparkles littering every corner of apps and browsers and search results with no easy way to turn them off or opt out or just make it go away, and how this has contributed to how fucking tired I am, and how I really do not want to be on The Internet for one more day, if I can help it.

But this is not a wrap up post. So I won’t talk about any of it.

I remember my first stream like it was yesterday. After I pressed the go live button, I remember going back and forth between my makeshift pandemic office upstairs and the lounge downstairs to make sure I was, indeed, broadcasting to the world. (I hadn't yet discovered the Twitch dashboard that lets you monitor your stream in real time.) That first stream had just an average of three viewers, and mainly consisted of counselling a Lithuanian 17-year old who was having trouble with his parents whilst I was building my first open source app: fretonator.com. I often wonder if he's doing OK now.

Despite the strange start to this streaming journey, I was hooked instantly. During the height of the early Covid pandemic panic, before the vaccine was invented, whilst millions of people were dying, as we were all adjusting to remote working in our homes, and whilst my child was just two and a half years old, somehow I found the time and inclination to go live on Twitch four evenings a week consistently. Honestly, I don't know how I did it. But at the time, everyone was on Twitch; it was addictive. Being on The Internet felt like a necessity in the early days of the pandemic, and being part of a live stream hosted by a real person on Twitch was uplifting in an otherwise dire set of circumstances. It was how we stayed connected when we figured we all could just die at any time. And, through streaming and watching others on Twitch I had discovered an incredible community with shared interests who all just simply enjoyed hanging out with each other. It was a truly, truly wonderful time in my life in an otherwise dark, dark time for the planet.

Before Twitch, I was living in a tiny world, working at a local tech agency in Manchester, UK. I had not yet heard of niche sub-categories of the technology industry such as Developer Relations, Developer Advocacy, Developer Experience, or Developer Education. At the time, given that people in these job roles were no longer travelling to events, they had moved their activities to Twitch. By immersing myself in what was then the Science and Technology category on Twitch, and the wonderful mechanics of Twitch raids (where you send all your viewers to another stream when you're ready to go offline), I came to know many people who were working in DevRel, and was entirely enamoured with the whole thing.

I got my first Developer Advocacy job after I got to know a streamer I raided who was a Developer Advocate at the time, LaylaCodesIt. I remember choosing to raid her because she was the only other British woman I witnessed streaming in the Science and Technology category since I discovered Twitch. We became fast friends, we streamed together in a little series we called CodeCake, and she referred me to an ex-colleague of hers who was hiring a front-end specialist Developer Advocate at Contentful. I remember thinking that this type of job was too good to be true. How could it be possible that I could use my expertise in teaching and skills in technology in the same job? (For those of you that don't know my history, I was a music teacher before I started working in tech.) And so in January 2021, the next chapter of my journey began.

Streaming was a big part of my DevRel job at Contentful; I would go live three times a week during work hours consistently. In fact, I got invited to the Twitch Partner program during my time at Contentful, which I attribute to being able to have so much freedom to stream and talk about Contentful in public as part of my job responsibilities, thus being fortunate to build a thriving community. Being a talented and prolific streamer was seen as a valuable asset to any DevRel team at a time when we couldn't really travel safely, and I was proud of the viewership I achieved and sustained.

My next move was to the Netlify Developer Experience team in January 2022. One of the specific reasons they hired me was for the success of my Twitch streams. Netlify was, and still is, a fully remote company. However, as more and more companies started to force people to return to the office in 2023, viewership across the entirety of Twitch started to decline: no longer were people able to tune in to a Software and Game Dev Twitch stream in the background whilst they powered through their JIRA tickets. This, coupled with with the post-pandemic economic decline of the technology industry in general, caused the business value of DevRel teams to be questioned constantly. DevRel teams were now at the top of the elimination list, and this resulted in an alarming shift in how companies valued live streaming in DevRel.

We pay your salary to work for this company. We don't pay you to have fun on Twitch.

I remember very vividly when words to that effect were said to me in a team meeting. It was crushing. The endeavour that had catapulted me into this career, the thing I loved to do so much, the brand of fun and entertainment I had poured my whole heart and soul into, the activity that had got me these first two jobs in the Developer Relations industry: was being condemned as valueless, trivial, worthless. Shortly after that conversation, I was made redundant in a company restructure.

My next move was to Sentry as a Senior Developer Relations Advocate. My manager was very supportive of my Twitch streaming activities and encouraged it, but I couldn't help shake the feeling that I was providing zero business value in return for my efforts. And it is a huge effort: being on camera for four hours at a time, writing code, problem-solving, building something real whilst maintaining an entertaining persona and conversing with viewers really takes it out of you. Plus, viewership across Twitch was declining further, given more and more people were returning to office, save for a few outliers. It also became quite obvious that I was in a sub-optimal time zone for sustained viewership. Twitch remains a very US-centric platform, especially in the Software and Game Dev category. There just weren't that many people browsing Twitch when I went live. Often, I would be at the top of the category when I was live, yet still with only around 100-130 concurrent viewers.

Now, I have written about how your live coding stream does not need a bigger audience, and I stand by that. But, as someone who has a job where the value of your activities are constantly being questioned, that big audience is a real indicator of potential value. If you're showcasing great software to 500 people, the probability that you generate a good amount of interest which results in sign ups and eventual paying customers is much higher than if you're streaming to ~60 viewers. I'd been laid off once before in this industry. And so, naturally, I started to prioritise other activities at work that would be seen as being more valuable in order to keep my job, such as delivering more formal workshops and engaging in other more prominent marketing activities.

And then in the autumn of 2024, my husband got really sick, and I didn't think he'd recover, and all of my priorities in life shifted. I stopped streaming entirely for around three months. And when I returned to Twitch, something didn't feel quite right. With all of the above considered around the conversation of business value, I didn't look forward to going live like I used to; whilst live streaming I felt like I was failing at my job — failing at delivering value. And then, the mental and physical exhaustion of the events that unfolded surrounding my husband's illness hit me hard. My body gave up. I could no longer use my hands without debilitating pain. I thought this would be a great opportunity for "content", however (like a fool). I live streamed learning to code with my voice, and it was, without exaggeration, a living hell. Talking simultaneously to a captive audience whilst learning how to talk to a machine whilst being in excruciating pain was so incredibly abhorrently vile I wouldn't recommend it to my worst enemy. (Not that I have enemies, mind you.) And so I took another break: mainly because I handed in my notice at Sentry to take some time to recover from all of this pain and exhaustion, to try and practise self-care, and to try and get my life together and my health back.

A month later, I started a new role as Head of Developer Education at Nordcraft. Whilst I went live a few times at the start of my job to share this new and exciting developer tool with the world, something still didn't feel right. I couldn't stop hearing those words in my head: "We pay your salary to work for this company. We don't pay you to have fun on Twitch." Now, obviously these words have not been uttered at Nordcraft and the people I work with are truly very wonderful, but I have more responsibility in this role than I have had in previous roles, and this company is a small start-up of just nine people, and therefore time in the workday is precious. Additionally, I am now a one-person department with many other responsibilities and priorities that just haven't afforded me the time to put everything aside and hang out on Twitch for four hours at a time to maintain that elusive viewership.

I am so incredibly grateful for everything that streaming on Twitch has given me. I have built a network of talented friends in technology; I have become an international speaker; I built a whole ridiculous game played via my Twitch chat; I built some truly silly and fun projects; I pivoted my entire career; and I made friends for life. But, alas, it is time to move on to the next chapter.

On Thursday 18th December 2025, I will be going live on Twitch for the last time. I will also be ceremoniously turning off my Twitch bot (which will save me £84 a year) and will be making the code open source.

Thank you, everyone, for coming on this journey with me.

Let's play p4nth3rworld one last time.

I guess this time the game really does stop, when the stream ends.

At the time of writing, I’ve been using the BenQ RD280UA for around three months as my primary monitor connected to my MacBook Pro M4, and I thought it would be useful to document my experience with using it for anyone considering investing in this almost novelty piece of kit. For me, the BenQ monitor does come with one major downside, but the pros heavily outweighed the one con, meaning this monitor surprisingly became my primary monitor on day one.

Pro: it’s really comfortable to look at

I wasn’t expecting to replace my LG DualUp as my primary monitor so quickly, but as soon as I turned on the BenQ, it was very clear how much more pleasant the monitor was to look at. BenQ describe this monitor as using “Eye-Care Technology”; I don’t know the precise underlying technicalities of this, but instantly my eyes felt much more relaxed looking at this monitor compared to the LG DualUp.

The display has near-zero glare, everything looks really smooth on the screen, and the eye care options such as Night Hours Protection, Low Blue Light Plus, and Brightness Intelligence Technology can be fine-tuned to your personal preferences. This isn’t an eye care feature per se, but I also really like the MoonHalo, which is a ring light at the back of the monitor that I use at a brightness level of 3 and a colour temperature of 1. Unfortunately I don’t have my monitor against a wall to take full advantage of the reflection of ambient light that the MoonHalo creates, but when it’s darker in my office, it’s a welcoming addition to using the BenQ Screenbar Halo that sits at the top of the monitor (which BenQ also sent me a couple of years ago!).

Pro: switching between the colour modes makes different tasks feel easier

I like to work in both light and dark modes depending on the task I’m doing. For coding in an IDE I prefer using dark mode; for reading and writing I prefer using light mode. The middle button at the bottom of the monitor allows you to switch between optimised colour profiles quickly when switching between tasks.

I’ve found the dark theme colour profile works great for working in a dark theme in VS Code, but when working in Nordcraft and editing videos using DaVinci Resolve (which both have a dark UI) I’ve found the M-book profile to be better for me, as it increases the overall brightness of the screen and, more importantly, the contrast between colours. This is really helpful for someone like me who has quite a severe astigmatism, which often causes my eyes to feel strained when looking at screens for long stretches of time, especially when working in dark UIs. I also really like the ePaper mode which puts the monitor in a kind of dimmed monochrome mode. It’s like looking at an e-reader, and it’s really kind on the eyes.

One other thing I will mention on the colour profiles is that if you enable High Dynamic Range via the MacOS display settings, you won’t be able to use the different colour profiles, as the OS settings seemingly override any other monitor-specific colour profile capabilities.

Pro: the monitor is a really comfortable size

The unconventional 3:2 aspect ratio is really comfortable to work in. The larger screen real-estate provides more vertical space than the standard 16:9 aspect ratio, which I had become accustomed to with the LG DualUp, and also makes viewing two applications or browser tabs side by side very comfortable. Plus, the flexible arm makes it easy to adjust the horizontal and vertical positioning should your preferences change throughout the day when you switch between tasks, or whether you’re sitting or standing up at your desk.

Whilst the aspect ratio of this monitor is really comfortable to work in, it’s entirely inconvenient for one of my regular activities.

Con: the 3:2 aspect ratio is awkward for making screen-recorded video content

I make a lot of video content as part of my work at Nordcraft. A 16:9 resolution is the standard people have come to expect when watching videos on YouTube, and so using a 3:2 screen to record these videos is not ideal. Some internet searches propose that you can choose to use a 16:9 resolution via operating system settings and adjust the output in the BenQ Display Mode Aspect settings, but on a MacBook Pro M4 there isn’t the option to make this work. It is for this reason that I have continued to record my screen for videos using the split dual display on the LG DualUp, which provides me with the required 16:9 aspect ratio.

I have also experimented with trying to capture only a 16:9 portion of a browser in my recording software (OBS), but it’s not that reliable and I probably gave up too early. What’s more, due to the monitor’s high resolution and the less-than-ideal capabilities of my MacBook Pro, when capturing the BenQ screen via OBS I often run into overloaded encoding errors (when I forget to downscale the recording resolution), meaning I’ve frequently attempted to make recordings three or four times before I give up and resort back to using the LG DualUp screen. It’s a real shame, because looking at the LG DualUp is really not as comfortable as looking at the BenQ, and I want the best for my eyes!

With that being said, the newer BenQ RD320UA coding monitor is in 16:9, and so I would go for this one in a heartbeat if I could afford to splash out on another monitor because it would give me everything I could possibly ever need. And in which case, I’d probably ditch the second monitor entirely for my daily work. I’d still need another monitor for live streaming, though.

Overall: it’s a solid monitor

The technology behind the BenQ series of programming monitors cannot be disputed. Working on this monitor for long periods of time is a very comfortable experience, so much so that it almost makes working a joyful experience (I said almost). If you struggle with eye strain or you’ve never managed to tweak your existing monitor settings to your preferences, this could be a worthy investment. But I would urge you to skip the 3:2 version and get the 16:9 version if you’re in the business of making screen-recorded video content.

Over the last decade, technology companies that started out as honest and independent hubs for innovation have gradually and very slowly been swallowed whole by something that, for those of us who have built our lives around being ethical, being nice, being good, and Doing The Right Thing, we just cannot comprehend. It has been a slow but sure bait and switch.

The media and public discourse would have us believe that This Is The Way Things Are; we're locked in now and there is no other way. But that is what these companies rely on: you're too burned out to take action right now. And so as a collective we continue to pay for services that these companies provide and, by proxy, support these organisations in moving further and further away from what is right and good.

I often speak about how your tools don't matter and how telling your story about what you're creating is the most important part of building for the web. But in 2025, the tools we choose to use, support, build community around and pay for send an important message to our peers about what we believe in, what we're willing to tolerate, and ultimately, who we choose to be.

Yesterday the CEO of Vercel posted a proud selfie to The Internet, posing with the Prime Minister of Israel, Benjamin Netanyahu. Regardless of how utterly absurd this actually is, this whole circus act sent a very clear and frankly, harrowing memo to the entirety of the technology industry.

Those of you are are ethical and nice and good but also invested in the Vercel ecosystem are probably a little shaken up right now. And maybe you hope this is a one-off because you really don't have time to migrate all of your projects to another deployment platform right now, let alone migrate away from Next.js to a new web framework.

But we all have a choice.

Taking action and Doing The Right Thing is often difficult, always exhausting, but it is what we must do, together. We all deserve better. The world deserves better. It'll take a little work to get there, but there is hope.

There is hope if we do it together. The Internet is ours.

We all have a choice.

To complement my birthday celebrations, I requested that people on The Internet send me a letter via email that I would open on my birthday. The Internet did not disappoint: I received 20 letters, some from strangers, some from newsletter subscribers, some from friends, and each one was delightful to read. I replied to every single one.

Some letters were written in the style of my newsletter, Weird Wide Web Hole. This was incredible to experience:

Copy

I don't know you
You're a total stranger
You are a face and some words
A logo and sometimes a voice

You enlighten my Thursdays
Your name is a breath of air in my mails
I'm not sure if I like IT anymore (don't tell my bosses)
But I like your sharings for sure

It has a feeling
melancholic, hopeful, magical, weird (in a good way)
It inspires me
This feeling is way more important than the topic

The letters also said some wonderful things:

Your presence on the web, your posts, your videos, your live streaming, your you-ness is so very refreshing and enjoyable. You inspire so many of us to be our best at whatever it is we're doing.

I don't know you that well, but I see you on Bluesky and it looks like you create fun things. The world needs more fun people creating fun things.

An Internet Friend who became an IRL friend this year (despite living very far away) gifted me with these beautiful words:

I'm so absurdly grateful that you've come into my life in a genuine way this past year. I still don't know that I can express to you how crazy it is that I have looked up to someone on the internet for years, admired your work, the incredible things you find for your newsletter, the way you teach and present yourself in public regard with such genuine-ness - never trying to hide or dampen your personality, and then one day I was just able to text you about life and hear about what yoga class you're going to this week.

It's a fucking delight and the world is a magical place AND what an honor it is to have a friend that I look up to and admire and want to become more like as I develop in my own career and as a human.

They also shared one of their favourite poems with me:

As usual, we're drunk with Love today. Evict your thoughts and find a song to play. Prayers and devotions come in countless shapes and sizes. Pick the ones the beauty in your soul recognizes.

I want to share an excerpt of my reply to this one:

Thank you for your kind, sweet words. I have a secret for you, though. Well perhaps it's not a secret. But I'm not special, really. Not on my own. It's the people around us that make us special, the connections we form, the communities we create, and the relationships we nurture and cultivate. Without you in my life I would be less good. So read all of that stuff you wrote and direct it inward towards your heart and your light. Your soul will recognise the beauty and love in those words; they are yours, so they are yours.

Life is a journey towards discovering one's true strength; not being "better" or "more this" or "more that". We are all the universe. We all have infinite love and wisdom inside of ourselves. We just need to work a little to find it, to experience it, and to share it with others. And that "work" is just living another day, seeing other things, connecting with other souls, breathing and basking in gratitude for what we have been blessed with by the particles in the sky.

I also received a letter from an old school friend who, coincidentally, also ended up working as a developer and has been secretly watching me on The Internet for some time:

I just wanted to let you know I'm really glad to see you kicking ass in the tech world. I always knew you'd go on to do big things.

Internet Friends who have lived through their 40s were gracious to gift me their wisdom:

A warm congrats on reaching this epic milestone! I'm speaking to you from 10 years in the future, where I recently turned 50. For some, turning 40 can fill one with existential dread. But for most of my 40s I felt it was the best time of my life, despite everything going on in the world. I felt like I finally knew what I was doing professionally. I felt the joy of being a parent.

If I had one regret it would be that I didn't take better care of my health. When you're young it's easy to think you're going to live forever. But by the time you're my age, it all starts slowly (or sometimes quickly) falling apart. The aches and pains start to compound, parts of your body are just like "fuck this". At least, that's been my experience. My birthday wish for you is that you are happy and healthy and can avoid being on a first name basis with multiple medical specialists for as long as possible.

Your 40s are awesome. And you are awesome. So I have no doubt that you will thrive. I can't speak for your 50s though. I'll let you know in 10 years.

And another:

We only met recently and briefly but as someone who is nearing 50, I wanted to take a minute to tell you how rad your 40s are. I dreaded being 40 but it's been the BEST decade. Here are 3 reasons:

• You are kinder to yourself and start to like yourself a bit more. 40s me is far superior to 30s me in every aspect. This might just be down to perception but even if it is, it's working.

• You become a bit invisible but this is not always a bad thing. I've done a lot of solo travelling in every decade, and in my 40s, it stopped being an issue that I was a woman on my own walking through souks or being out at night on my own. Take a book with you to dinner and own your space.

• You genuinely stop giving a fuck about whether anyone likes you or if you're wearing the right clothes or living the right life. I know you've been saying you don't give a fuck for years now but you secretly have up until this point.

Wishing you a lovely day and a glorious decade ahead.

I replied:

This part really stuck with me: I know you've been saying you don't give a fuck for years now but you secretly have up until this point.

Honestly, I can feel the secret fucks that were so embedded within me starting to fall away. You're right, they were there during my 30s. I was looking towards this date for a whole year, thinking that perhaps it was the end of something. Perhaps I thought it was the end of me as I knew me. But through changing ingrained thought patterns around so many things over the last year in preparation for this milestone, it is feeling more and more like a beginning every second. I think I know what they mean when they say life begins at 40 now.

And I'm looking forward to becoming a bit invisible. I can't wait for the day I can "leave The Internet" and just live. I took a day off work on Friday for my birthday, as I always like to spend some time alone. And I felt so human not sitting at a desk and just being out in the world. I want more of that. I want all of that all of the time.

I have definitely started to like myself more over this last year. I am giving myself more grace, being less hard on myself, living more in the present and I've stopped chasing things that are not worth chasing.

I can't wait to see what the next 10 years brings; and I can't wait to pass down your advice coloured with my own experience.

And finally, a short and simple reminder from an Internet Friend:

At 40 it all begins to continue.

Thank you, Internet. I love you.

Now, this was a total rabbit hole I went down, so bear with me.

The difference between "merge" and "squash and merge"

The default option when merging pull requests on GitHub is merge. When you merge a pull request on GitHub, all commits from a feature branch are added to the base branch in a merge commit. A merge commit preserves the full history of the changes being merged, allowing you to see an intertwining history of events that happened on both branches after a feature branch is merged into the base branch.

On GitHub, a default merge uses the --no-ff option in git, which means no fast-forward. This option is what creates the merge commit and allows you to inspect the complete history of both the feature and base branches.

When you squash and merge a pull request, all commits on the feature branch are "squashed" into a single commit, using the fast-forward option. A fast-forward commit merges all file changes after the most recent change on the base branch. This loses the distinct feature branch timeline of changes. This can be useful when:

1. You want to keep your commit history tidy on the base branch

2. You're merging small changes on short-lived branches

3. You don't need to preserve the feature branch history

Why the original bash script doesn't work for squashed branches

Here's the original bash script I wrote to delete all merged branches. The first line, git checkout main && git branch --merged, checks out the main branch, and lists all branches that can be detected as being merged into the main branch.

Copy

# delete all branches merged into main
dam() {
  echo "=== Deleting all merged branches ==="
  git checkout main && git branch --merged | grep -vE "(^\*|main)" | xargs git branch -d
  echo "☑️ Done!"
}

When you do a squash merge, Git takes all the changes from the feature branch, compresses them into a new commit, and applies it to main as the latest change. The original branch’s commits are not in the history, so Git still sees that branch as “not merged". The git branch --merged command won't match any branches, and so won't find any branches to delete.

The script that finds and deletes squashed branches

To delete all squashed branches that merged using the fast-forward option we need to take a different approach. This script is named dams(), which stands for "delete all merged squashed". To use the script:

• add the following code to your .bashrc or .zshrc file (switch out main for what you usually call your main branches if necessary)

• save the file

• source the new changes (or reload your terminal)

• run dams in a git project directory (without the brackets)

• enjoy the cleanup!

• (This may need to be adjusted according to your shell, please don't come for me.)

Copy

dams() {
  echo "=== Deleting merged and squash-merged branches ==="

  # Ensure main is checked out and up to date
  git checkout main &&
  git pull &&

  # Loop over all local branches except main
  for branch in $(git for-each-ref --format='%(refname:short)' --exclude=refs/heads/main refs/heads/); do
    # Skip if branch does not exist on remote
    if ! git ls-remote --exit-code --heads origin "$branch" >/dev/null 2>&1; then
      echo "Skipping $branch (not on remote)"
      continue
    fi

    # Delete only if content is fully in main
    if git diff --quiet "$branch" main; then
      git branch -D "$branch"
      echo "Deleted $branch"
    else
      echo "Keeping $branch (has unmerged changes)"
    fi
  done

  echo "☑️ Done!"
}

Let's break down what the script does, and learn some things about Git!

Check out the main branch and update it

First we want to make sure we checkout main and pull in the latest changes to compare the other branches against.

Copy

git checkout main && git pull &&

Loop over local branches and check for changes

Here, the script loops over the branch names returned from the command git for-each-ref, which iterates over all branches (or refs) that match a pattern and shows them according to the given format. The pattern excludes the main branch (--exclude), and the --format requests the short branch name. refs/heads/ at the end of the line instructs the script to look only at local branches.

Copy

for branch in $(git for-each-ref --format='%(refname:short)' --exclude=refs/heads/main refs/heads/); do

Check if a local branch has been pushed to the remote

This following code runs git ls-remote to check if the branch in the loop has been pushed to the remote to avoid deleting branches that haven't been pushed. The --exit-code flag instructs the command to exit with status "2" when no matching refs are found in the remote repository. In Bash, if considers exit code 0 as true and non-zero as false. Exit code 2 will evaluate to false, so with the ! at the start of the if, we're checking if git ls-remote returns false. If it does, we skip deleting that branch.

The >/dev/null 2>&1 part instructs the script to throw away both stdout and stderr output so that it produces no output at all, to keep the terminal free of noise. The script still produces a success or failure via the exit code, but suppresses all output.

Copy

# Skip if branch does not exist on remote
if ! git ls-remote --exit-code --heads origin "$branch" >/dev/null 2>&1; then
  echo "Skipping $branch (not on remote)"
  continue
fi

Check for diffs and delete the local branch

This part of the script checks for diffs between the branch in the loop and the main branch. Again, in Bash, if considers exit code 0 as true and non-zero as false, so whilst this may look backwards compared traditional programming languages, if there is no diff found between the branches, then the branch will be deleted using git branch -D.

I decided to use the -D flag to force the delete in this script, seeing as I'm operating on my local machine and it's safe to force delete local branches in my case, especially if we have checked at the start of the script if the local branch has been pushed to the remote.

Copy

# Delete only if content is fully in main
if git diff --quiet "$branch" main; then
  git branch -D "$branch"
  echo "Deleted $branch"
else
  echo "Keeping $branch (has unmerged changes)"
fi

It uses the --quiet flag to suppress all output, as we don't need to view that whilst the script runs. Without the --quiet flag, here's what the command outputs in isolation when there is a diff:

And here's how the output looks when the full script runs and finds some branches to delete that have been squashed and merged on GitHub:

Probably don't use this script

You probably shouldn't trust random bash scripts written by random people found on the internet, especially where your precious version-controlled work is concerned, so you probably shouldn't use this. This is my disclaimer. Use this script with caution!

Copy

.parentElement {
  text-transform: lowercase;
}

.parentElement::first-letter {
  text-transform: uppercase;
}

In my case, however, the first letter was not being uppercased, and I was confused about why. Here is a modified version of the HTML I was attempting to style:

Copy

<div class="parentElement">
  <div class="child1">
    <svg width="16" height="16" xmlns="http://www.w3.org/2000/svg">
      <path>...</path>
    </svg>
  </div>
  <span class="child2">
    inconsistently FormattED string
  </span>
</div>

Naïvely, I thought I would be able to apply the styles on the div with the class parentElement, and the styles would cascade down to the span with the class child2. However, it turns out that the ::first-letter pseudo element selector can only target text under a certain set of conditions.

The ::first-letter spec

The ::first-letter CSS pseudo-element applies styles to the first letter of the first line of a block container, but only when not preceded by other content (such as images or inline tables).

When drilling down into what exactly defines a “block container”, there is definitely some ambiguity across the CSS spec: “In specifications, block boxes, block-level boxes, and block containers are all referred to as block boxes in certain places. These things are somewhat different and the term block box should only be used if there is no ambiguity.” I won’t go deep into the specifics of block boxes and block containers in this post, but I will attempt to provide a summary:

An element is a block container only if it contains block-level or inline-level boxes. The following values for the CSS display property produce block containers:

• block

• inline-block

• list-item

• table-cell

• table-caption

• flow-root

The following values for the CSS display property produce block-level boxes, but not block containers, given how their child elements are formatted:

• flex

• grid

The key issue in my case was that I was attempting to target a non-block container; the parentElement class specified a display property of flex and attempting to cascade the styles for ::first-letter down to a child element.

The rules of ::first-letter

To summarise, using CSS ::first-letter will not work in the following conditions:

• The element you are targeting is set to display: flex or display: grid

• The element you are targeting is preceded by other content, such as a ::before pseudo element, images or inline tables

• You are attempting to cascade ::first-letter styles from a parent element, even if the elements are block containers

To make sure CSS ::first-letter works for you:

• Apply the ::first-letter styles directly to a block container (and those block containers are specified above)

• Ensure the content you are attempting to target is not preceded by other content, such as a ::before pseudo element, images or inline tables

A note on browser support

CSS ::first-letter may have limited browser support: caniuse.com reports this pseudo element selector is not supported in Firefox, but Baseline reports that "This feature is well established and works across many devices and browser versions. It’s been available across browsers since ⁨July 2015⁩."

Using ::first-letter in action

To better understand how ::first-letter works, I threw together some examples of when this pseudo element can be correctly targeted, and when it fails to work. You can view the examples at CSS first-letter demo, and you can view the code here.

However, good-looking graphics and a more polished approach to production in a sea of similar-looking stream thumbnails can certainly entice people to click on your stream to see what you’re all about. And then it’s down to you to get those curious viewers to stick around, press that follow button, and return to your next stream.

I have received many compliments on my stream setup over the years, but it took years to get it to where it is today. I started out with nothing but a view of the chat and some follower stats powered by Streamlab’s fork of OBS. I had no branding, no graphics, and zero flair. If you’re curious about my stream’s evolution and how I’ve approached it, you can watch a talk I gave at Web Unleashed in 2024.

Since first pressing the go live button in 2020, I gradually developed more of a “personal brand”. This evolved over time, mirroring the evolution of my website design. On the latest branding iteration I was fortunate to work with a designer, aaoa (who is also a streamer), but I am very conscious that not every streamer has access to, or the budget to employ a designer, especially when starting out. I’ve used this branding for over two years now, and already feel like I need a bit of a refresh.

What kind of stream graphics do I need to get started?

You can create a professional-looking stream brand with just a few key graphics, considering how your Twitch channel will look when you are both online and offline.

Panel graphics

Potential stream viewers often browse the Twitch directories looking for streamers to follow regardless of whether they are currently online. When your stream is offline and someone views your page, they will land on the “Home” tab, which shows your featured clips and suggested streamers, which you can configure in your featured content settings in your Twitch dashboard.

Curious viewers will often click on the “About” tab, which is where you have the chance to shine. On the “About” tab you can add a number of different panels: you can tell people a little about yourself, lay down your stream rules, detail your stream tech specs, and more. Adding graphics to each of these panels can give a great first impression to potential followers and viewers, and helps to communicate your personality and what your stream is about. You can use graphics on panels as header images, or use taller images to fill a full panel.

Offline banner

If someone is exploring your Twitch page and they click on the “Chat” tab, they’ll see the live layout, with a space for the live video stream on the left, and the chat feed on the right. Here, Twitch gives you another opportunity to hint at your personality and the look and feel of your stream with an offline banner, which you can upload via the channel brand settings in your Twitch dashboard. I got a bit lazy with my latest offline banner, and it’s just a photo of me reaching to turn my camera off.

Starting soon screen

Most streamers like to show a “Starting soon” screen when they go live, which gives viewers a chance to join the chat before the real fun begins. This screen can contain some moving parts for some visual interest, which you’ll need to set up in your live streaming software (such as OBS), but the easiest way to get a “Starting soon” screen up and running is by creating a static image that matches the branding of your offline banner and Twitch panel graphics. Here’s an example.

On a break screen

Sensible streamers take regular breaks throughout their streams, and for this you’ll probably want to switch to another scene to let viewers know you’re taking a break. Similar to the “Starting soon” screen, this can contain some moving parts, such as a feed of the chat or some recent stream clips, or for simplicity it can be a static image. Here’s an example.

How to create Twitch channel banners (for free!)

There are a number of free tools available to help you create graphics for your Twitch streams quickly and easily. I recently explored the capabilities of Adobe Express which claims you can “Make Twitch banners for free in minutes”. So how does it measure up?

After signing up or logging in to Adobe Express from the Twitch banner landing page, you’re taken to a canvas where you can start creating your Twitch graphics. When you land, the templates search box comes with a pre-populated search term in the templates area — “twitch live stream banner” — so you can start browsing templates for inspiration straight away. You can also scroll the search box area horizontally for a list of other pre-configured search terms, such as “twitch panel banner” or “twitch starting soon banner”.

These search terms largely return similar results, so you’ll probably want to use the results filter to narrow down your search, such as filtering by size. The recommended image sizes for panel banners varies depending on whether you want to show a header image or a full panel image, but you’ll probably want to use a 16:9 image for an offline banner. The size filters are extensive given the wide array of use cases for Adobe Express, so to filter accurately you’ll need to scroll through a lot of options.

To browse free options only, make sure to check the “Show only: free” checkbox at the top of the left panel.

To save templates you like for later, you can hover the image and click the heart button. You can view your favourites in the “Your stuff” tab on the left of the UI.

Stream branding is a very personal thing, and I often think that using a free tool to create personalised graphics means that I will end up with the same branding and graphics as other streamers, which isn’t ideal if you want to stand out in a saturated market. But, at the time of writing, there are over 1000 free templates to browse in Adobe Express, reducing the chance that the graphics you choose will be identical to other streamers using the same tool.

Once you’ve scrolled the list of templates and you’ve found a design you like, click it to open it on the canvas and start editing.

To replace the default images with your own, click the image and choose “Replace”, and you’ll have the opportunity to upload your own image. What’s great about this part is that the image you upload will then match the style of the template image.

You can then click each text element and edit it to suit your needs, so you end up with something like this:

You can further customise the fonts, font sizes and colours, and the different layers that make up the design. Once you’re happy with your design, click “Download” in the top right. If you’ve used a free template, you can download the image straight away and use it on your Twitch channel.

All in all, editing this template took me less than one minute. That’s not bad.

What’s missing from Adobe Express Twitch banner maker?

Overall, this is a useful tool to help you create graphics in a few minutes for your Twitch channel for free. That being said, there are a couple of things that could be improved, so keep this in mind when you’re creating.

Template collections

While you can create single images from templates really quickly, what’s missing are collections of templates in the same style, so that you can easily create matching Twitch panel graphics, offline banners and stream graphics. At the time of writing, if you want to create a coherent look across your different key graphics, you’ll have to choose one template you like, and adjust the size of the canvas and move things around to account for the different image dimensions required for the different areas of your Twitch channel.

A good search experience

The search terms don’t always return good matches. The template I chose to edit above was named “Green Pink Live Mobile Gaming Video YouTube Banner”. Searching for this term didn’t return that exact template in the results, and using the size filter to attempt to find it in the list of 800+ results didn’t return any matches at all, despite filtering by the exact size of the template. If you like the look of any templates, save them to your favourites so you can find them again.

Try it for yourself

Minor issues aside, the Twitch Banner Maker from Adobe Express does what it claims: you really can “Make Twitch banners for free in minutes”. If you need a quick fix for your stream graphics whilst you’re getting started on Twitch, head over to Adobe Express, explore the templates, and personalise them to your heart’s content. And good luck on the live streaming, you got this.

I chose the wireless silver version with an extra set of English UK key caps, Kailh silent pink switches, tenting, and the RGBW Underglow.

It looks beautiful on my desk. But does a beautiful keyboard like this deliver what it looks like it promises? And is it really worth the investment? And by investment I don’t just mean the money. Moving from a more traditional keyboard layout to a customised columnar layout is certainly a challenge if you’ve been typing “the normal way” for most of your life, and requires quite a bit of time investment to relearn how to type and to develop muscle memory for key customisations and layers. What’s more, I use multiple devices on a daily basis, and I only use a columnar keyboard for work. Switching back and forth between a columnar layout and staggered layout took quite a bit of getting used to at first, but now it’s second nature, like switching between playing a flute and a piccolo, if you’re familiar with that type of thing.

Honestly though, I am really enjoying using my Dygma Defy and I can’t see myself switching to a different keyboard any time soon. With that being said, I probably don’t use this keyboard to its full potential, and so I thought I’d take the time to talk through my five customised layers for anyone who’s curious, and also to remind myself what customisations I don’t use enough.

The Dygma Defy is customisable using Bazecor (software built by Dygma), and it’s pretty intuitive. It allows for some incredible customisations, including macros (combinations of keys), Superkeys, and full LED customisation. Plus, I periodically save a backup of my configuration to GitHub, which has been useful when switching machines.

Base layer

The base layer is the default layer, and is used for general typing activities with a few modifications.

The thumb clusters

• The yellow keys numbered 2, 3, 4 switch to the relevant layers by holding the key. You can choose whether the layers are accessed via a key press or a key hold. I prefer to use the key hold so that I can be sure that when I am not touching the keyboard, the base layer is active.

• I configured two Enter keys; I usually use the right Enter key when typing, but the left Enter key is useful when I am using my trackpad with my right hand to move the cursor around text.

• The same is true for the extra backspace key on the left thumb cluster, coloured red to match the other backspace key at the top right, which is where it usually lives on more traditional keyboards.

• I also configured two command keys (⌘) on the left and right, but I only really use the left.

• Two space keys on either side are also useful, but I only really use the right.

• On the left there is a Superkey, coloured purple. Superkeys are a really neat concept by Dygma, which allow you to use different actions on one key to do different things. On this Superkey, a single press copies, a long press pastes, and a double tap cuts.

• On the right there is a macro key labelled “Emoji”, which is configured to pop up the emoji picker on Mac, which is the equivalent of pressing CTRL + Left ⌘ + Space.

• There are also some keys to check the battery level or pair with bluetooth, which I set up to remind me those things existed. I don’t really use these keys, given I keep my keyboard plugged in to give me quicker access to configuring things in Bazecor on the fly (customisation is more stable when the keyboard is plugged in). I am a little annoyed with the wires on my desk all the time, so maybe I’ll switch to wireless at some point.

The main keyboard

This is pretty much a standard setup, with a few personalisations:

• I don’t use caps lock, so I switched that key for a backtick (above left shift).

• Backspace and delete are useful next to each other at the top right.

• I added an LED configuration cycle button for my left hand (next to B), which I press by mistake far too often. I should probably remove this given I prefer to use the keyboard with my own LED colour-codings, but I always feel like sometimes I might want to change the LEDs to one of the other settings, like rainbow, or pure white. But colour is such as important part of how I configured my keyboard, so I just don’t.

• I configured some commonly used symbols in the two centre columns: -, =, [, ], \.

• The SUPER H key when held switches to layer 5, which I’ll describe below. It functions as a standard H key when tapped.

Layer 2

This layer is a pretty powerful layer, with a number of macros that power window management. It is accessed by holding the layer 2 button on the right thumb cluster, which appears as TRANS for transparent on this layer, meaning it always defaults to the base layer function.

Window management

I’m using Raycast for window management. Setting up the window management keys involved configuring the commands in Raycast first, and mapping those commands to macros in Bazecor. I’ve found this to be a really efficient way of using window management without having to memorise a bunch of key commands, which are often convoluted. That being said, I have no idea what key commands I set up in Raycast now, so I am lost without the Dygma with regards to window management.

• The pink keys around the middle power a number of window management macros, such as left half/right half/top half/bottom half and centre to screen.

• The two MACRO Move keys on the left side move windows between screens.

• The MACRO Maxim key in purple on the left side maximises a window.

• The arrow keys are self explanatory.

• I don’t use HOME, END, PAGE UP or PAGE DOWN, but I didn’t really use them on a traditional keyboard either. I probably should.

• I also put caps lock on this layer, but I forgot about this, so don’t use it.

• I set up the number pad on the right side, but I hardly use this because I seldom press the correct keys. I coloured the 5 key on the number pad differently to try and position my hand correctly, but I just haven’t used it enough for the muscle memory to kick in yet.

• Upon inspecting this layer whilst writing this post, I had forgotten that I had set up a Macro to open the clipboard in Raycast on the right thumb clubster. To this day I have been using the long traditional shortcut on the base layer. I think I don’t use it because it’s awkward to press the key combination of thumb and fourth finger on that right cluster unless I move my hand a lot.

Layer 3

This layer serves to recreate most of the F row keys and their functionality on a Mac, with some bonus macros.

• The F key row is at the top. I seldom have a use for this.

• Media keys and volume control are on the left.

• The pink macro on the left is a Mac screen capture macro, which I use a lot. It’s the equivalent of pressing CTRL + Shift + Left ⌘ + 4.

• On the right, I set up two macros to zoom in and out, as it was cumbersome on the base layer to use ⌘ + +/- to zoom in and out, given that I placed the + and - on opposite sides of the keyboard.

• On the right I also configured keys for increasing/decreasing my laptop screen brightness, and sleeping or shutting down my machine. I always use the sleep button. These functions are built into Bazecore, which I think is a really nice touch. There’s even the option to bring up a calculator! But I tend to use Raycast for quick calculations.

Layer 4

I set up a mouse layer in the hope that I would train myself to use my trackpad less, and stop moving my hands back and forth from the keyboard. This has, so far, been unsuccessful.

To hold the layer 4 access button and use the mouse wheel up/down keys is quite comfortable but I think I could find a better configuration. Maybe I should just unplug my trackpad and force myself down this path.

Layer 5

Whilst I have become very comfortable typing text on this keyboard, I still make quite a few mistakes when coding. It’s still ingrained in me to use the traditional keyboard configurations on the base layer for symbols like [] and {} with the shift key.

I set up a symbols layer to try and improve my efficiency with these symbols, which is accessed by holding H on the right. I just haven’t developed the muscle memory to access this layer enough, yet.

I colour-coded similar opening and closing brackets to try and train me on which was which. I even set up a macro for ⇒ for all you JavaScript fans out there.

Notes on ergonomics

I realised whilst writing this post that I have not been making use of the keyboard tenting, which I have heard is good for reducing strain on your wrists. I stopped using tenting when I found it difficult to type earlier this year when I was having trouble with my hands (read How I learned to code with my voice if you’re curious), and I forgot to go back.

With regards to ergonomics, I have found that using a columnar keyboard is definitely better for my hands. It feels odd at first, switching from a traditional staggered layout to a columnar layout, but when you get used to it, you really are moving your hands a lot less, which is better, apparently.

Additionally, the way you set up your keyboard layers is the key to your own personal ergonomics, which this is something that traditional non-customisable keyboards just can’t provide. When setting up your layers, try out the configurations and key combinations to make sure that you’re not putting strain on your hands. If you find them difficult to access, or if they cause pain, switch them up.

Customisable keyboards geared towards ergonomics can also get you out of bad habits. One of the things I noticed is that on a traditional keyboard, I used to press Right Shift plus {}, which gave me a kind of claw hand many times a day. The way I have set this keyboard up forces me to press Left Shift + } and Right Shift +{, which means I don’t code with claw hands. With that being said, this is still very awkward when coding, so I should really use my symbol layer.

This is a great keyboard. Check it out on the official Dygma website: Dygma Defy keyboard.

What started off as a few selfies next to the opulent spa decor quickly descended into these eager content creators filming almost every single moment they were experiencing, editing the images and videos as they were taken, right from in the pool, comparing shots and angles. My husband and I spent most of our time in the spa either moving to different spaces to put ourselves out of the way, or having to dodge the line of sight of the tens of active phone cameras, lest we be thrust onto the internet in our swimsuits. When the other guests weren't filming, they were scrolling their phones from the pool as if they were on their couches at home, most probably watching for the likes to roll in on the TikToks and Instagram reels they posted just minutes earlier.

In the past, I've been to spas that operate a strict no-phone policy to protect the privacy and experience of its paying guests. So why was it different at this spa? My only guess is that they're profiting from free internet promotion by its patrons at the expense of the overall experience. We did the British thing and sent a strongly worded email when we got home.

Looking around at the sea of phones in what was supposed to be an escape away from the hustle and bustle of real life, work, bills, and responsibilities, I felt sad. Not just because the risk of appearing in someone's internet "content" in my swimsuit without consent is an invasion of privacy, but that these people weren't truly experiencing what was intended to be experienced. They weren't truly present; they were somewhere on the internet, doing labour for likes.

Is this how we're living our lives now?

Put your phone down.

Disclaimer

The technology industry (and beyond) is performative, often offering shallow solutions to deeper problems, shifting the responsibility of change onto those that bear the brunt of the dire consequences the world has created for itself. Want to prevent climate change? Use paper straws instead of holding corporations accountable for their increasing carbon emissions. Want to protect your mental health online? Limit your screen time using app-blocking tools instead of questioning why social media platforms have been deliberately engineered to be addictive. Want to create equal opportunities in the technology industry? Segregate all the women, non-binary, intersex, LGBTQIA+ identifying and trans folk under the banner “Women in Tech” and hope they figure it all out.

At most of the tech companies I have worked, there have been dedicated spaces for “non-men” to get together, including Slack channels, informal meet-ups, and formal discussion panels. “Non-men” in this context has been used to discount “non-heterosexual-cis-men”, and to include women, non-binary, intersex, trans women, trans men and those identifying as LGBTQIA+ all at once. The people spanning the very wide spectrum of this group have probably, and unfortunately, all experienced some kind of discrimination in the workplace, and so it seems sensible for a company to put us all together to share our experiences in a safe and enclosed space, right? It helps, but I'm not so sure it offers a full solution.

The problem with “non-men” spaces

Reports on gender statistics in the technology industry have consistently published figures of around 17-25% of women and non-binary people working in this industry since the early 2000s (this varies by geographical location), and not much has changed over the last 25 years. A recent statistics dump by Spacelift reports that “half of all women who work in tech have left the industry by age 35”, and “none of the biggest US tech companies report women occupying more than a quarter of all technical roles”. Furthermore, “the proportion of undergraduate computer science degrees awarded to women has fallen from 37% in 1985 to about 20% today.”

Why are the statistics not showing much improvement despite countless initiatives surrounding diversity being created, and in particular events, awards, and “safe” spaces for “Women in Tech”? I have a hypothesis: all of these initiatives are operating in closed and exclusive spaces, which is sending a strong signal to the male majority with the power to affect real change that they are not welcome here, and it is not their problem to solve.

A few years ago I was nominated for a “Women in Tech” award by an anonymous party. Not only did I have to confirm my nomination by writing a number of time-consuming essays about my achievements and eligibility for the award, I also couldn’t shake the weird feeling that I was nominated only on the basis that I am a woman. I understand the need to celebrate and lift up “non-men” in tech, and to provide a platform for representation to young and less experienced people entering the industry, but I wasn’t comfortable with demonstrating that if you want to succeed in the tech industry you need special awards and events under the banner of your gender. I did not accept the nomination; I want to win awards that the men are eligible for, too. Because I can, and I have.

These enclosed “non-men” spaces are also not without their specific problems. At one company I worked for, I was asked to participate in a “Senior Women in Tech Panel”, where I was invited to share my experiences and career progression in tech to an audience of women, non-binary, and trans men and women. This event was not moderated well, and descended into a chaotic discussion about how many children each of the panel members had, and negative remarks about the ethnicity and representation of the panel speakers. This may have been a one-off, but at that point I decided to leave the closed Slack channel for “non-men”, and chose not to participate in events of this type for the rest of my career.

What's more, the hard work of ensuring that workplaces are equitable often falls upon the shoulders of underrepresented groups, who are already carrying the burden of discrimination, being overlooked for promotions, and other related issues. A friend reports:

They've started a women's network at work and I am not a member because I think these initiatives are basically just making female members of staff do extra work to fix organisational problems.

The problem with women-coded labels

Imagine if men described themselves as a “male founder” or “HeTO” (a male CTO), or slapped the #MenInTech label on their social media posts when sharing their achievements? The industry’s obsession with women-coded job titles such as “female founder” (which has descended painfully into “girl boss”) that were conjured up to challenge the male default and demonstrate representation in the industry, does not sit comfortably with me.

Feminising job titles, in my opinion, belittles success and achievement in the context of a patriarchal default. Just as “Women in Tech” awards and closed spaces for “non-men” segregate underrepresented groups of people from the spaces where people with power make decisions, women-coded labels inherently classify people on a separate, non-default scale of success and achievement.

It may work for early career folks, but what's next?

After speaking with many women during writing this article, it looks like "Women in Tech" initiatives work well in the context of those entering the industry, but may not be enough to support getting enough underrepresented groups into leadership positions.

A friend of mine shared this with me about her experiences:

I joined tech through Rails Girls. It was a really nice space, it made me feel very safe. It also played into this thing that I knew was happening a lot, which is women thinking that they are not capable of doing something because the world is telling them that they cannot. I really loved getting into tech through these female-focused initiatives. It made me feel like there was a group of people who cared about me joining tech, which is such an important thing if you are looking at an industry that is overloaded with a specific default type of guy.

Another friend had a similar experience, but once she had established her career, things changed:

My perspective also changed with age and expertise gathered. I found a lot of “Women in Tech” programs and initiatives incredibly useful as a newbie. I wouldn’t be where I am without codebar and some early speaking opportunities. But as I gained my voice and my knowledge I found it increasingly patronising.

Another Women in Tech statistics report from AIPRM reports that in 2025, "around 14% of global tech leaders were female in 2023 – up from 8% in 2015", which is promising. Yet, the Spacelift report also finds that “The so-called Big Five tech companies (Alphabet/Google, Apple, Meta/Facebook, Amazon, Microsoft) have never had a female CEO.” And to couple that with another finding from the Spacelift report mentioned above, that “half of all women who work in tech have left the industry by age 35”, it seems that once we get to a certain level of seniority, age, or experience, something isn't working.

Rachel-Lee Nabors wrote about this in 2018 in an article titled A Counterintuitive Way to Increase Diversity in Tech:

I’m mid-career in the web development and design industry. And right now, I’m hearing a lot of the same stories from my fellow mid-career friends from underrepresented groups (women, minorities, LGBTQ, and more): you reach a certain point in your career and you can’t win.

Responses to how you may be feeling right now

I have benefitted from "Women in Tech" initiatives or other "non-men" initiatives in tech. Are you saying these programmes shouldn't exist?

I'm a man and I think DEI is terrible. I'm glad to see a woman agreeing with me at last!

As stated in the disclaimer, this is absolutely not the point of this article. Diversity, equity and inclusion initiatives are absolutely needed in this industry. However, the current landscape has seemingly affected little change in statistics on the whole, especially at leadership levels. I don't think we can continue to segregate ourselves if we want to make progress. Personally, I have worked with some excellent men. And men who have worked with me have said I am also excellent; we have all benefitted from working with each other. To that end, we absolutely need these initiatives: but the men must be invested as well. They must not be excluded from the conversation about how they can help affect change, especially in the context of leadership, given it's mostly the men who hold those positions today.

I am a man and consider myself an ally. Do I need to do something?

I remember speaking on a panel of all women, which was organised by a man. I requested that he not promote the event as an "all-women" event to avoid focussing on gender. He did it anyway. Celebrate underrepresented groups in tech, but do not focus on their gender identity. Celebrate their achievements, use your privilege to lift them up, share their work, make their voice heard: not because they are not men, but because their work is worth celebrating. If you are a man in a leadership position, you can absolutely do more to bring more underrepresented groups into leadership with you. To take another quote from Rachel-Lee's article:

You should be a mouthpiece when someone isn’t heard, an advocate when people are unable to be represented, a shield bearer when folks are under attack, an elevator for the stuck, a signal booster for the unnoticed. Wherever possible, let them do the work, and be heard and understood, and represent themselves. You’re the back up, the path carver, the taker of the brunt of the negative impact, always asking, “How can I help?” Always pushing others up, even over yourself.

We’re focussing on the wrong thing

I think that purely gender-based initiatives are shallow solutions to the deeper problems of male-dominated industries and society as a whole, that focus solely on surface-level optics of inclusion rather than addressing the root cause of inequality and imbalance on a larger scale. So, how do we address the root cause of inequality and imbalance?

We invite those with power to have a seat at the women’s table (and the underrepresented table as a whole): men must be part of the conversation to help affect change, especially at higher seniority levels.

Women, non-binary, intersex and trans folk are in tech, have always been in tech, and will (hopefully) always be in tech. There is a problem, in that these underrepresented groups are often discriminated against and overlooked. The solution? Men in tech can lead the change in how men represent themselves and their gender as a whole in the industry. A bandaid? Groups where "non-men" can feel safe. Both are important, but only one will affect real change.

This week I posted a silly and whimsical post on Bluesky, which seemed to resonate with a lot of you out there, and it reminded me of a section in the DORA report about valuable work.

AI has always promised to “help people spend more time doing valuable work” by “automating the manual, repetitive, toilsome tasks” so that software developers can be “free to use their time on ‘something better.’” Despite this, the report states that “individuals are reporting a decrease in the amount of time they spend doing valuable work as AI adoption increases”. The maths isn’t mathsing.

What is valuable work, actually?

I have observed a growing trend of developers focussing solely on the tools used to make software, rather than what the software actually does. Many people are sharing their new apps on social media, attempting to provide context for their creations by listing the databases, runtimes, frameworks, UI libraries and AI code generation tools they used. But what does your app actually do? What problems does it solve? Tell me about the value you just created!

Valuable work and meaning is not derived from what AI makes us (apparently) faster at: generating code. Meaning and value in software development is actually created through the impact of building things that makes human lives better, or easier, or slightly less bad. Now, it can be argued that much of the work in the technology industry in 2025 is not centred on making things better for humans whatsoever, but that’s a discussion for another day.

What’s becoming clear is that the mass adoption of AI is shifting the focus away from human-centred software solutions that provide meaningful value, and is reducing the entire industry to just the tools at its disposal. Just generate the code, bro. Just ship one more app, bro.

The new kitchen metaphor

If I employ someone to build a new kitchen for me, I really don’t care what drills, hammers, nails, or sandpaper they use to get the job done. I just want a valuable end result: a fancy-looking and functional kitchen that makes good use of the available space, enabling me to cook delicious food in a delightful and comfortable environment. Ultimately, a great kitchen is created with vision, creativity, and by solving existing problems the old kitchen presented. The same is true for software.

Value in software development cannot be determined by how many lines of code you can bash out in any working day, and especially whether or not you are using AI to do so. Real value is delivered through vision, creativity, experimentation, and using human brains to solve human-centred problems. The report backs this up:

[T]here is also an art and empathy underlying a great product. This might be difficult to believe for people who think everything is a problem to be resolved through computation, but certain elements of product development, such as creativity or user experience design, may still (or forever) heavily rely on human intuition and expertise.

And what’s even more interesting, is that while seemingly “high-performing teams and organizations use AI”, the report finds that “products don’t seem to benefit”. We’re all just churning out AI generated code, moving those tickets, making meaningless graphs go up, but to what end? Real software is actually not moving forward. We're all just cranking out the same broken software with the same stupid bugs. In fact, as I was editing this post whilst sitting with a fresh batch of black hair dye on my head at the hairdressers, one wrong tap of a button on my phone deleted half of the article. I attempted to use the three-finger gesture to bring up the undo button on my iPhone, which, not surprisingly, did not restore what was deleted. I ended up having to find a deploy preview of this post (that I fortunately deployed before I left the house), copy and paste half of the article back into the CMS, and reformat the headings, being very careful to not make a single wrong move.

All the new kitchens and silly add-ons are shit. There’s no value in that.

Tools do not determine value created

The tools someone uses to build a kitchen are only as good as the skills of the person using them. A skilled craftsperson can probably use any old tool and produce a great result that holds up for years to come. A less experienced craftsperson who doesn’t understand the fundamental concepts of space, structure and value-based utility might be able to make a single kitchen cabinet look good to the untrained eye, only for the shelves to be at the wrong height so I can't store my stuff. The same can be said for software.

There’s nothing wrong with being inexperienced; we all have to start from somewhere. But we can’t rely on tools as a shortcut to gain valuable experience. Experience takes time to develop, and your tools are only as good as your fundamental knowledge and skills. If you skip the knowledge and skills part, and if you fail to learn about what you’re doing and the implications of how you’re doing it and the human value you have the potential to deliver, then you have little hope of building human value into your software. Because for the most part, humans use software. Andreas Møller said it better in They lied to you. Building software is really hard:

The true value of a software engineer is in our ability to analyze problems as well as design and implement creative solutions. To get good at these skills you need to understand not just the tools at your disposal but also the technologies you are building on top of. If you don’t understand how an application works then you have no chance of fixing its bugs and issues.

In the report, “respondents also reported expectations that AI will have net-negative impacts on their careers, the environment, and society, as a whole”. Whilst AI has empowered anyone to build and ship web and mobile apps, the tangible negative impact of the soulless, valueless software released on a daily basis across the industry cannot be underestimated.

And no, I do not want to use your new AI tool to summarise an email (?) or summarise a document (?) or summarise a meeting (?) or anything else. I want to use my brain so I can comprehend and learn and connect with what is in front of me.

Productivity ≠ value

Returning to the topic of the previous article, I want to touch again on the topic of productivity. Productivity as a measure of value is extremely misleading. The very notion of productivity has been conjured up by Big Capitalism™️ to keep us busy, and to misdirect our attention so that we forget to question the broken system in which we have no choice but to participate. All of this prevents us from real growth, and moves us further and further away from the pursuit of real value.

You could argue there is space for both approaches in software development. Build the hard, compelling stuff using your human brain, and use AI to generate the code for some of the more boring parts of your apps. Take form validation, for example, scaffolding out a new project, or setting up all the boilerplate to make some API calls. But those boring parts are only boring because you wrote the code to do the same thing before! You already learned how to do it without AI.

But unfortunately, too many of us are getting sucked into the productivity hype cycle and engaging in daily conversations with energy-sapping computer machines that vomit out thousands of lines of code based on probability and existing mistakes that the Large Language Models themselves are trained on. It's absurd. We have a whole new cohort of inexperienced kitchen builders who have invested in the latest must-have drills, hammers, nails and sandpaper, but have no idea how to build real value into what they are using those tools to create. And so we're seeing an influx of infinite inferior kitchens that offer no human value. They may look good when you walk into the room, but will inevitably fall to pieces as soon as you put the kettle on to make a cup of tea.

The data speaks for itself. Vibe coders are reporting outages and critical security vulnerabilities in their apps, losing months of work that didn’t use version control, and the inability to truly learn new things.

The world is already cooked, and yet, we’re cooking it more

What’s more, there’s the environmental impacts of AI, which are only just beginning to emerge. An MIT article titled Explained: Generative AI’s environmental impact outlines how the rapid expansion of generative AI presents significant sustainability challenges, including electricity and water overuse, hardware-related emissions, and increasing pressure on power grids.

The world is already cooked. And yet, we’re cooking it more — literally, and figuratively — by shipping insecure software into the void that we have no idea how to debug, scale, or extend. In the not-so-distant future, LLMs will be trained purely on LLM-generated software, and the world will eat itself.

I challenge you to find the value in that.

I have attended many conferences over the last few years, but usually I am attending because I am a speaker. All Day Hey is the only conference I can remember deliberately attending as a non-speaker back in 2023, and now 2025. It can be difficult to justify attending a conference purely for the sake of attending, on both personal and professional grounds. We all know there isn't enough time in the day to do what we need to do: exercise, eat well, get enough sleep, do the food shopping, spend quality time with your loved ones; and work deadlines are always looming. But taking time away from your desk and your Internet Machine can make a profound impact on your professional and personal spirits.

In this doom-riddled capitalist world, we are too preoccupied with metrics. This is through no fault of our own. If we are constantly tasked with making the needle go up in our professional endeavours, it seems only natural that we would apply this default thinking to other areas of life. In considering whether to attend a conference, you might ask yourself:

• What if I don't make any new professional connections?

• What if I don't learn anything new from the talks to take back to work?

• What if my boss thinks it's a waste of time?

Truthfully, you might not make any new professional connections, although you may meet people with whom you have existing relationships, and you might not learn anything new from any of the talks. But attending a conference is certainly not a waste of time, especially considering the wider impact it may have on you as a full and complete human being.

We should be treating attending a conference as an experience first and foremost. Experiences shape us; they shape our attitudes, our opinions, and our approaches to all things, whether personal or professional. The experience of being in a room of like-minded people for a day can be energising. Hallway conversations centred on shared interests can be refreshing. The raw buzz of being in the same place as lots of people you know from On The Internet™️ can be very exciting. You just cannot replicate this from behind your Internet Machine in your office, especially if it's at your home. Meeting people In Real Life is an experience that should be cherished for the experience itself, regardless of the circumstances or outcomes.

I must admit that for a few years I was reluctant to attend conferences purely for the sake of the experience, and I was guilty of using all of the excuses laid out in the bullet points above. I would whisper naïvely to myself: "Surely, I can do all this networking and learning from the comfort of my own home. I don't need to waste time travelling to a venue." But something about this experience I shared on a beautifully sunny day in Leeds with my Internet Friends has changed something within me.

Surround yourself with people who add value to your life. Who challenges you to be greater than you were yesterday? Who sprinkles magic into your existence, just like you do to theirs? Life isn’t meant to be done alone. Find your tribe, and journey freely and loyally together. – Alexandra Elle, author

I have always been a bit of a self-categorised "outsider". I feel that I don't often fit in at social events in the real world that aren't centred on technology or music (or anywhere else, really). But what I realise now is that I spent so long hiding myself away from the Real World in my home office that I forgot that there is a community of people in the world where I do fit in; one that has welcomed me with open arms, laughs at my jokes, appreciates and shares my work, and wants me to succeed. And all of this has occurred in the Real World, not behind a screen.

I've always felt I belonged to a tribe on The Internet, which has been facilitated somewhat by the strange phenomenon of the Social Media Networks™️ that I have used to share knowledge and education as part of my job. But sharing a day in the Real World with the tribe, speaking and hearing real words with each other, and sharing food together, has promoted this blessed group to a collection of real friends and professional allies.

Did I make any new professional connections at All Day Hey? Yes. Meeting smart people who I knew of but didn't know, really, has strengthened my professional network and capacity to reach more people in my work as a developer educator. Did I learn anything new from the talks at All Day Hey? Not quite, but I was inspired to think more creatively about alt text by Lola Odelola, and the tribe bonded deeply over her ideas. Did my boss think it was a waste of time? I haven't asked him.

And did I enjoy the experience? Yes, absolutely. The experience was enough: and more.

View all official 2025 photos by All Day Hey | last photo by Robb Owen

While the end-user experience was evolving, new tools to support web developers who were building websites were also being invented. The World Wide Web Consortium (W3C) was formed in 1995. And, whilst the first version of CSS was not released until 1996, the 1994 proposal for Cascading HTML Style Sheets was being developed by the W3C. This would give web developers full control over the design of their websites, instead of allowing end-users to enhance the visuals of their internet-surfing experience using proprietary browser configurations. And, whilst the web was becoming more visual, so were the tools used to build websites.

It all started with Visual Basic

In 1991, Visual Basic was launched for Windows software application development. Visual Basic was a graphical user interface (GUI) that provided a visual abstraction layer on top of C/C++ and the Win32 API. Ryan Lucas describes this historical release in detail in The history and legacy of Visual Basic, and pays particular attention to how it saved the careers of “millions of mainframe COBOL programmers who were looking with terror at the microcomputer invasion,” as recalled by the creator of Visual Basic, Alan Cooper.

To design their UI, developers could drag and drop out components onto a WYSIWYG canvas. To add behavior to a UI element, they could simply select it and choose a click event handler from a dropdown. Mainframe programmers were suddenly empowered to quickly get up to speed writing Windows apps.

Whilst application developers were embracing a more visual way of working in the early 90s, developers on the web were still confined to the command line, Notepad, and MS-DOS Editor on Windows. That is, until FrontPage 1.0 was released in November 1995.

FrontPage was developed by Vermeer Technologies, and was categorised as a “World Wide Web publishing and site management tool”. Like Visual Basic, FrontPage was a WYSIWYG (what you see is what you get) visual interface, and this tool built HTML. It also provided a personal web server, which allowed you to preview your website on your local machine as you built it. It also included templates, automated scripts, and more. FrontPage was acquired by Microsoft just two months later in January 1996, and was rebranded to Microsoft FrontPage in June 1996 to coincide with the release of version 1.1.

Around the same time, a company called iBand worked on a similar visual tool to FrontPage called Backstage Designer. And, as is seemingly standard practice in this industry, iBand was acquired by Macromedia in 1996, and soon rebranded the Backstage Designer product as Macromedia Backstage Desktop Studio, which in 1998 became a web development GUI you may be more familiar with: DreamWeaver.

Development tools for building games were also evolving in the same way at the same time. Unreal Engine 1, a GUI built in Visual Basic, was also released in 1995.

And what’s very interesting to note at this point, is that while game development has largely adopted visual development tools across the industry, web development seemingly abandoned the visual tools of the mid-late 90s. Thirty years later, most of us are still building websites and web applications using text editors. Why is that?

Why didn’t we adopt visual website tools in the 90s?

The bottom line is that visual website tools in the 90s (and beyond) produced terrible HTML markup, and therefore, pretty terrible websites. I remember fondly using the Apple website builder iWeb in the early 2000s. In fact, it wasn’t very long ago that a website I built for a client in 2008 using iWeb was still up and running. The text-based CMS I built for them, which displayed a text file in an iframe that they uploaded via FTP, really stood the test of time. But now I have professional knowledge and experience of building things for the web, I know that the HTML markup that iWeb produced was absolute filthy garbage. And if the HTML markup is garbage, then your site is not accessible to those who use assistive technology, such as screen readers.

In 1986, IBM announced the first screen reader, but it wasn’t until the mid 90s that screen readers started to become a little more accessible themselves, when JAWS was released for Windows 1.0 in 1995. The first web accessibility guidelines, later branded as the Web Content Accessibility Guidelines or WCAG, were published in January 1995. Yet, despite this, tools that were created to build websites were not ever seemingly built with these official standards in mind. This goes for tools built in 1995, and astonishingly, 2025.

This week on May 7th 2025, Figma announced Figma Sites, a tool to publish your designs built in Figma directly to the web. But this new product has not been well received. Adrian Roselli warns us: Do not publish your designs on the web with Figma Sites.

“…Unless you want to fail all the WCAGs, create litigation risk, close off opportunities in Europe, engage in reputational harm, and oh yeah, throw up barriers to your customers and users.”

It’s no surprise we weren’t getting it right in 1995, if we still can’t get it right 30 years later with all of this knowledge, experience, and empathy under our belts. And I’m not even going to mention at this point how AI can’t get this right, either. Of course it can’t; it doesn’t possess the capacity for empathy.

Developers want control

Developers want complete control over their HTML, CSS and JavaScript: and rightly so. If visual web development tools can’t generate clean and semantic HTML, organized and debuggable CSS, or performant JavaScript, it really is a no-brainer to continue to build websites and web applications using text-based web frameworks, or rolling your own.

It is no secret that I am writing all of these things on the Nordcraft blog, and that Nordcraft is an open-source Web Development Engine which combines a web framework with a suite of advanced visual tools that let designers and developers collaborate to build high performance web applications, and that I work at Nordcraft. And you might think that Nordcraft is just another visual website builder that produces the same old garbage that all the other visual tools do. But speaking as someone who has been building websites and writing code for over 20 years, and as someone who likes complete control over said websites and code, I can say for a fact that Nordcraft is very, very, different.

Nordcraft actually gives you control

In Nordcraft, your HTML markup is yours to control. Using the Nordcraft editor, you build your HTML structure in the same way you build HTML with text, using semantic element tags of your choosing, with full access to adding attributes and other web platform-based functionality. Nordcraft does not prescribe how to build your HTML markup: you do. The only difference (and advantage) is that you are building your HTML on a WYSIWYG canvas, where designers can collaborate with you and add design flair as part of the process, not as some preliminary task that sees designs in Figma thrown over the fence in a developer’s general direction (which is, all too often, the case). CSS and JavaScript work in the same way: you have complete control over what you ship to the browser, without any unexpected nonsense.

It’s 2025, and we can do better than what has come before us, and what is, unfortunately, currently unfolding in this visual web development landscape. By giving you, as developers and designers, full control over the end result you envision, I am confident that Nordcraft won’t suffer the same fate of the early visual tools of the 90s, or Figma Sites in 2025.

Your fate is in your own hands, as well as the fate of your websites.

My physical pain is real, but given the personal events I have endured over the last two years, I also believe that this manifestation of pain has been exacerbated by a combination of a series of emotionally traumatic events.

My hands recovered towards the end of February after leaving a very stressful work environment, but I still felt like something was deeply wrong with the rest of my body. I have been engaging in talking therapy on and off for 20 years and at this point I decided to go back. It is helping mentally, but I still felt like there was still something wrong physically.

In March 2025 I decided to see a nutritionist. And this is where it all became clear. The root cause of all of this (the pain, my messed up menstrual cycle, the constant tiredness, the constant fear of something being wrong with me) is that amidst the whirlwind of events that took place over the last two years, I neglected to take care of myself physically. And I don't mean through exercise. I wasn't eating enough, and I wasn't eating right.

My nutritionist recommended I read The Stress Solution by Dr Rangan Chatterjee and the concept of how we (unintentionally) put our bodies into a stress state really resonated with me. Our bodies are designed as such that when we are in a stress state, we are primed to survive dangerous or difficult situations, such as running from a predator or completing a difficult exam.

In times of stress, our bodies change physically in order for us to become a peak version of ourselves to maximise our chance at survival. Our pupils become dilated, sugars are released into our blood so that we can endure prolonged physical exertion. Our organs become resistant to insulin so that more sugar can remain in our bloodstream, rather than being available for our organs to store, so our brain can stay more alert. Our heart beats faster and our blood pressure rises to make sure the sugary blood can move around our body effectively. Also, our brains and immune systems become hyper-vigilant to threat, sending stress signals throughout the body. At the time same our libido plummets and our digestion system switches off, in order to maximise the energy reserves needed to survive running away from those dangerous predators.

I wasn't eating enough, and I wasn't eating right. I "didn't have the time to think about eating" given everything else going on, and I was inadvertently putting my body into a stress state 24 hours a day, seven days a week.

For the last four weeks, I have been eating bountifully. I have been eating three incredibly varied and nutritious meals every day to send the right signals to my body that I am safe, and this has moved my body into a thrive state. Apparently I'm also dairy intolerant, so I don't eat that anymore. But the results of these efforts are already so obvious. I am less tired, I can move easier, my brain is less foggy, my bloody is less fizzy (seriously, I felt like my blood was fizzy), my periods aren't messed up anymore, and I finally have the energy for proper exercise (I have taken up yoga). And more importantly, I don't feel like anything is wrong with me anymore.

The world is difficult in 2025; stressors are everywhere, especially when you spend time on the Internet. But by being intentional in how we nourish our bodies, we can send the right signals to our body that we are thriving, so that we can not only survive, but live.

p.s. coffee is not breakfast

Most developers are relying on AI

The report found that almost 76% of participants are “relying on” some form of AI tooling in their daily responsibilities as a software developer. This can include writing, optimising, documenting and debugging code, explaining unfamiliar code, writing tests, data analysis, and summarising information. “[D]evelopers who trust gen AI use it more”, but almost 40% of participants “reported having little or no trust in AI”.

I do not trust AI. I have over 11 years of professional industry experience, and have been making websites in some form or another for almost 30 years. With all this considered, AI code generation has only ever made me feel less productive. I prefer to understand every single line of code I ship in my applications: it makes everything easier to debug, fix, and extend. I have found that AI-generated code is often sloppy, unnecessarily complex, and a lot of the time, just plain wrong. For me, AI code generation is akin to mindlessly copy-pasting code snippets from Stack Overflow, and we all know how that goes. It usually takes me longer to understand AI generated code than write my own.

You may be sacrificing software delivery metrics by relying on AI

DORA’s software delivery metrics provide an effective way of measuring outcomes of software delivery processes. They are split into two categories: throughput and stability. The report found that “AI adoption is negatively impacting software delivery performance”, and the “negative impact on delivery stability is larger”.

Sacrificing throughput with AI

Throughput measures the velocity of changes in software that are being made, that is, how quickly and how frequently software teams can ship changes to production. Throughput is all about how efficient and responsive a team can be.

The report hypothesises that “the fundamental paradigm shift that AI has produced in terms of respondent productivity and code generation speed may have caused the field to forget one of DORA’s most basic principles — the importance of small batch sizes.” Since AI code generation will often spit out huge batches of code in one fell swoop, pull requests are getting larger. Larger pull requests and changes are much more difficult and time-consuming to review thoroughly for edge-cases and potential issues.

Speaking from experience, code reviewers are more likely to skim over large changes and miss important details; walls of impenetrable code are much more difficult to process and interpret by a real human brain than smaller changes, amidst an already busy work-day. Whilst combing through that +11456 -7892 code review, you’re probably thinking about all those lines of code you need to write yourself in order to stay “productive”.

Of course, there are tools that provide AI-assisted code reviews. But if we, as developers, do not trust AI to produce maintainable and reviewable code, why should we trust AI to review it? If you find yourself constantly reviewing large pull requests with a lot of AI generated code, you’re probably sacrificing throughput. You might not be shipping as fast.

Sacrificing stability with AI

Stability measures the quality of software changes delivered, and the team’s ability to fix bugs. Stability is measured using a combination of change fail percentage, which is the percentage of deployments to production that require hot-fixes or rollbacks, and failed deployment recovery time. A lower change fail percentage means the team has a reliable delivery process, and a lower recovery time indicates more resilient and responsive systems.

The report suggests that it’s “possible that we’re gaining speed through an over-reliance on AI for assisting in the process or trusting code generated by AI a bit too much.” I would argue that speed here is the illusion of speed, and the concept of “over-reliance” is key here, especially in the context of the new vibe coding meta. Vibe coding is about being dependent on AI code generation. Describe the app or code you want, and let an LLM take care of it for you. Ask it for a few edits. Ship it.

The report states that a developer’s productivity “is likely to increase by approximately 2.1% when an individual’s AI adoption is increased by 25%”. Vibe coding and any sort of AI adoption is attractive because it feels fast; it feels more productive. Now, I’m not proposing that professional software developers are going all-in on vibe coding, but increased adoption of AI and reported productivity increases poses a risk to software stability. We think we’re going faster, but we may be shipping poorer quality software and more broken changes, because we’re putting our trust in AI generated code too much.

Data from the industry is proving that vibe coders are shipping unstable applications, reporting outages and critical security vulnerabilities in their apps, losing months of work that didn’t use version control, and the anecdotal struggle to finish vibe-coded apps. If professional software development teams do not stay vigilant with their use of AI, they run the risk of sacrificing stability.

Plus, if you’re moving fast, but always having to pick up the pieces caused by over-zealous AI code generation, are you really being more productive?

• Set up a new development environment (install e.g. correct version of node, npm, yarn, pnpm, bun)

• Set up a new project (create directory, choose framework, choose starter project or boilerplate, install dependencies, ensure they are compatible with each other)

• Define a file structure and component library approach

• Define a base style guide and CSS resets

• Write boilerplate code to connect to APIs and databases

• Configure a build and deploy pipeline

• Configure Webpack???

And, if you’re working with a designer, you’ve also got the back and forth handover and sign-off processes to go through, which in a busy team or multi-project agency, can really hold things up. You just want to get building!

There are some alternatives to the time-consuming, decision-heavy setup process. You could use virtual machines or environments that enable faster time-to-setup through scripts and automated processes. But still, even this requires some effort and “onboarding". I remember at one job, I went through a “tried and tested” vagrant virtual machine setup process that didn’t actually work correctly with my version of MacOS at the time. Now, granted this wasn’t a brand new project, but it took me a full working week to configure my development environment so that I could be productive. So what are the alternative approaches? Recently, I’ve become curious about visual development frameworks.

What is a visual development framework?

When you use a visual development framework, you're working in an environment where you don't need to think about — or do — any of the relentless admin and project configuration tasks described above. Everything is taken care of from the beginning, and you're ready to start making components, fetching data from APIs, adding custom code, and watching your ideas come to life straight away. Visual development also removes the need to translate designs from design software to code: the design of the user interface is baked in to how you build it. No more handovers between teams!

In summary, visual development solves two key problems in front end development: it abstracts away the repetitive administrative setup work, and removes the inconvenience of separate design and dev environments.

Here's how working with HTML, CSS and data from an API looks inside visual development framework, Nordcraft. You’ve got a document tree of HTML elements on the left, CSS styling and API connections on the right, and the visual result in the middle. In traditional text-based development, this weather widget might be powered by a collection of files dotted around a codebase. In visual development, it’s all right there.

Is this the next big step for front end development?

A common sentiment among the terminally-online community is that if you’re not writing actual lines of code, then you’re not a real developer; often the industry treats the process of development as the outcome, rather than the actual website or app produced. But when you think about how every evolutionary step of computer science has centred on abstracting away things that no longer make sense for a human to do, then visual development frameworks are the logical next step in the evolution of front end development.

For example, hardly anyone is coding in Assembly in 2025, and we don’t shun people for not being real programmers just because they don’t write instructions to add memory data to a register in a x86-family processor in original Intel syntax, or know the equivalent in AT&T syntax used by the GNU Assembler. Most of us don’t need to worry about this anymore.

Whilst everything is a set of binary instructions at its core, we also don’t need to worry about writing code in binary, thanks to Grace Hopper who released the A-O compiler in 1949, which used symbolic mathematical code to represent binary code. And we don’t even need to worry about writing code in mathematical symbols, because soon after A-O, Hopper released B-O, or “Flow-Matic”, which is considered the first English language data-processing compiler. Each advancement removes another layer of machine-to-human obscurity.

What’s important to note, however, is that the evolution of programming languages was based on computation itself, not human-computer interaction (HCI). In the mid-latter part of the 20th century, there weren’t that many people using computers, and so HCI wasn’t a priority to be optimised for. But in 2025, we live our whole lives through HCI (for better or worse), and what has constantly been overlooked and under-prioritised is the actual experience of this human-computer interaction, both from the point of view as an end-user experiencing something on a device, and as someone who is crafting that end-user experience on a device.

I speak from experience that as a web developer, it can be challenging to create really great experiences and human-computer interactions when you’re constantly moving between different layers of abstraction and relative obscurity (e.g. design → code as text → user interfaces). Visual development frameworks are a tool to help us get the same outcomes as writing traditional text-based code, without the slow up-front time-costs.

My next step

Nordcraft is a Web Development Engine. Using Nordcraft, you can create fully-interactive front end websites and apps with any APIs, all via an in-browser visual interface. Nordcraft puts human-computer interaction at the front and centre of what you’re building, for both you as a web developer and your end users. And I'd like to go so far as to say that programming in a different way might actually help you understand some programming concepts in a deeper way. Plus, you’ll never have to configure Webpack again.

The team at Nordcraft is also working hard to make Nordcraft fully open source in 2025 and you can check out the progress towards this on GitHub.

It’s early days, but I’m incredibly excited to help shape the future of Nordcraft, and to help you build the best human-computer interactions on the web you possibly can. If you want to keep up with what we’re working on at Nordcraft, subscribe to the Nordcraft Engine channel on YouTube and join the Discord (it’s very active!), and I can't wait to build more silly websites using Nordcraft, for your entertainment.

Hi, my name is Salma! I’m currently building an app with Express, Nuxt, and the Twitch API. Let’s connect! 🚀👩🏻‍💻🌐

I understand the need to find shared interests with the online community to make genuine connections, I really do, but statements like this don’t tell people anything about what you actually do. Last year I did exactly what I described above. But what does it even mean? Take the following non-tech examples:

Hi, my name is Salma! I’m currently making music with a piano, guitar, and synthesisers. Let’s connect! 🎹🎸🎵

Hi, my name is Salma! I’m currently making food with pasta, onions, and seasonings. Let’s connect! 🍝🧅🌶️

Hi, my name is Salma! I’m currently making clothes with fabric, thread, and needles. Let’s connect! 👗🧵🪡

You get the idea. The above statements tell people about what you’re using, but not about what you are doing. Let’s reframe the above non-tech examples.

Hi, my name is Salma! I’m currently working on an experimental EP that pushes the boundaries of the human perception of sound through the blending of acoustic instruments and digital noise to produce ethereal and meditative soundscapes. 🎹🎸🎵

Hi, my name is Salma! I really love making unique pasta sauces that combine culinary influences from around the world. This week I’m trying to perfect a Japanese-inspired pasta sauce that takes inspiration from ramen and blends it with the traditional Italian concept of bolognese. 🍝🧅🍜

Hi, my name is Salma! I’m currently making all my clothes from old furniture fabric and thrifted offcuts to prove that fashion doesn’t have to be fast to be exciting and innovative. I recently made a dress from my grandma’s old bedspread and I can’t wait to wear it to a party this week! 👗🧵🪡

The above examples may be a little contrived, to say the least, but they tell a story; they reveal a little more about your personality; and they communicate more about who you are. Now, what about that technical example?

Hi, my name is Salma, and I write code for your entertainment. Last year I built a text-based game for my Twitch stream that blurred the lines between me being online and offline, allowing viewers to interact with my stream 24/7. I love to find ways to help people truly connect through unexpected and fun applications of technology. 💖🔥📺

You are more than the tools you use: tell your story. And your people will find you.

Each talk is the same, but different

The first performance of Entertainment as Code was very different to the last. This was mainly because this talk centred on a new and evolving project I was working on throughout 2024, but also because the very notion of this conference talk inspired the project itself. Entertainment as Code became kind of an ouroboros; the more I gave the talk and spoke to attendees about how they enjoyed it, the more inspiration I received to evolve the project and the talk into its final form.

By giving a conference talk multiple times, you also learn what works and what doesn’t work about your talk. As a (former) comedian, I learned a lot of hard lessons about what works and what doesn’t work for particular audiences in particular venues. I will never forget the time I referred to a fictional seven year old as the c-word to rapturous applause from an audience of twenty-somethings in Camden (trust me, it was funny), whilst repeating the same to a room full of middle-aged people in Blackburn almost ended up with me getting booed off the stage.

I like to weave in jokes to my conference talks, and telling these jokes multiple times gives me the opportunity to iterate and land them as well as possible. The same goes for the content of the talk. In my opinion, no talk should be given in the same way any two times. On the one hand, as the speaker you will get bored. And on the other hand, conference attendees may attend multiple events and end up seeing you give the talk more than once (this definitely happened to me) and so you owe it to them to give them just a little bit more fun, insight, and technical depth than before. They’ll remember you for that.

You get better at giving the talk

Speaking from experience, musicians, and comedians especially, never give the same performance twice. They also never give a performance just once. Each performance is a practice to make the next one better. As a performer, you have a duty to adapt your material to the room in which you’re in and the audience that is before you. A conference talk is also a performance, and it should be no different. And in intentionally adapting and iterating on your conference talk as you tour it, you learn more about public speaking, how to tell a really compelling story, and the content of the talk itself.

My conference talks usually start with a strict script. As time goes on and I give the talk more times, I know the material more, my confidence grows, and as a result I’m able to improvise and go off-script, adapting the material to the audience and the room with little effort. It is incredibly satisfying for both the speaker and the audience to deliver the material in a way that resonates particularly with that room of people on a particular day.

Your talk reaches more people

According to a quick internet search for “average tech conference attendee numbers”, the average number of attendees at a UK conference is 100. Giving your talk to just 100 people and calling it a day is not a good return on investment for potentially weeks of work. After putting in that work, you owe it to yourself to submit those CFPs, and get yourself an audience. The more people you reach, the more opportunities you may get in the future. And the cycle continues. You become the ouroboros. And the cycle is complete. And if you enjoyed the process, write a new talk, and do it all again.

In December 2024, when remembering how I used to scold my mother for living in leggings and baggy t shirts from her mid-30s onward, and how I am consciously striving to be everything she is not and never was, I decided it was probably time for a change. But where to start? It was time to find a new pair of jeans.

Jeans are a tricky business; I have never felt comfortable in jeans, especially when sat working at my desk (I prefer to sit cross-legged). I just figured I didn’t have the right body type for jeans. However, what I discovered is that the variety of jeans available on the market has expanded considerably since I departed with my skinny jeans in 2020, and so I embarked upon this journey with an open mind. But, I had no idea what style was right for me given my long slim legs are often at odds with my slightly chonkier waistline where standard sizing is concerned (thanks, genes) . Or so I thought.

Shopping online for jeans would have resulted in an endless cycle of buying and returning, so I made a personal shopping appointment to be able to sit in a changing room and have someone bring me an endless supply of jeans to try on in desperate hope of perfect pair. Serendipitously, the first pair of mid-blue acid wash mid-rise relaxed 90s style straight jeans I picked from the pile were absolutely perfect. What’s interesting to note is that I always figured I needed high-rise jeans to hide my chonkiness, and that mid-rise jeans would cut me in two, given this was always the case with skinny jeans. I never would have event considered clicking a pair of mid-rise jeans when online shopping. Boy, was I wrong. These jeans made me feel amazing. So much so that I also picked up a second pair in a similar style in black from the same brand. And the icing on the cake was that these jeans fit me wonderfully in my regular size. I did not expect that.

I don’t think I can really get away with wearing baggy t shirts and relaxed jeans like the kids, so I stocked up on a few slim-fitting t-shirts to pair with them, and my new daily uniform was born. I’ve talked about Indyx on Bluesky before, which is an app I’ve been using to track items in my wardrobe, and at the beginning of 2025 I decided to start using Indyx to track my daily outfits to make sure I was making the most of the new items in my wardrobe. Instead of just throwing on the same old pairs of leggings and baggy t shirts, I really enjoyed getting dressed intentionally again. I felt put-together, and more ready for the day ahead. So much so, in fact, that whenever I wore leggings for a chiropractor appointment, for example, I felt extremely underdressed and sloppy.

Last night I must have slept weirdly, because I woke up with neck pain and as a result, I really didn’t feel like “getting dressed” today. So I’m sitting here writing this wearing leggings and a baggy t shirt and a zip-up hoody and I feel wrong. I don’t feel ready for the day. I don’t feel ready to work. I feel like an old version of myself that has lost progress in some sort of journey of self-discovery. But I think what this really means is that I have actually made good progress.

And all this is to say that it’s worth getting dressed every day, whatever that means for you.

It turns out I was over-engineering the concept of sending a newsletter in my head. And it really can be as simple as you want to make it. Since January 2024, I’ve sent 56 weekly issues of my newsletter, and I’ve enjoyed writing and sending every single one. Here’s how I approached creating and sending my newsletter, weird wide web hole, to make each issue easy to write, and delightful to send.

Send what you would like to receive

I am a huge fan of weird things and obscure things, intriguing experiences, and things that don’t always appear to be what they seem. Since the early days of the internet, I have always been fascinated with strange websites, curious applications of technology, the vastness of the universe, and unexpected collaborative online experiences. I am always thrilled to discover a non-standard, and perhaps unknown website written by a stranger, because I get to peek inside their head and explore the inner qualities of their soul and expression, and the human condition itself.

I created weird wide web hole to satisfy my own desires to explore the weird side of the web. I send what I would be excited to receive: obscure descriptions of strange and intriguing websites and incantations of wonder and curiosity. Every word I send and every link I collect is intended to make you pause, appreciate, and explore things differently to how we’ve become accustomed on this vast world wide web.

Make it easy for yourself

Lots of newsletters contain lots of words. As a consumer of newsletters, I often find I can’t make the time to read so many words. Newsletters often sit unread in my inbox for days, until I have the time and space to enjoy them. The attention span of the world is disintegrating before our very eyes, and so I purposefully choose to write just a few words. Yet every word I write is written intentionally, and for you to consume deeply and deliberately. I write few words because I mindful of your time and of my own time. And writing fewer words makes approaching each newsletter cognitively easy. Each issue takes around five minutes to put together.

Additionally, each newsletter contains just four links, which I collect throughout the week. Four is a very achievable number, and often I have a collection of links that are lined up for one or two future issues. I write the foreword to each issue on the day I send it, purely inspired by how the links in the newsletter made me feel, or what’s going on in my head that day. I don’t think too hard about what I write, I just let it happen.

Do it for the love, not the numbers

At the time of writing, I have 346 active subscribers to my newsletter. That may seem like a small number compared to the number of people who know me on Bluesky or Twitch or even Youtube, but if you visualise that number of people in a room, it’s actually quite wonderful. I have the attention of almost 350 people, every Thursday.

I know weird wide web hole may not appeal to a vast audience, and I actually kind of like that. I’m not going to sign off this blog post with a call to action to subscribe, because if you wanted to enter the weird wide web hole, you’d already be in there.

goodbye

After ruling out potentially genetically inherited rheumatoid arthritis with x-rays and blood tests, I deduced that probably I had carpal tunnel syndrome (which, coincidentally, my mother also suffered with). The most recent development, after seeing a physiotherapist, is that my symptoms don’t actually align with carpal tunnel syndrome, but instead, abnormal pressure on the radial nerve, primarily in my right arm. I’m doing some prescribed daily exercises that are alleviating symptoms somewhat, but the bottom line is that rest is the best medicine in this case: physical rest and mental rest. My physical pain is real, but given the personal events I have endured over the last two years, I also believe that this manifestation of pain has been exacerbated by a combination of a series of emotionally traumatic events. I may write about this at a later date, but in this post I want to talk about how I learned to work and code using my voice, and offer some advice if you, too, find yourself in this extremely difficult situation.

Getting started is challenging

I knew I had to do something to ease the pain to enable me to work, but I had no idea where to start. And so I turned to Bluesky to ask if anyone had any advice. The advice was overwhelming, actually. Ergonomics, exercises, meditation, alternative keyboard layouts, and voice control. And when I asked for advice on how to approach voice control and coding by voice, the advice was even more overwhelming. Everyone was very generous with their advice, but whilst dealing with debilitating pain, I was surrounded by a seemingly endless list of tools, plugins, apps, custom setups, and confusing options that left me feeling incredibly afraid for my short term future. How was I supposed to learn all of this to work effectively right now?

Initially I made the mistake of trying to use all the tools at once. The result? Complete and utter confusion. I felt like I had reached the limits of what my brain was capable of, and this felt devastating. But, I did what every good software engineer does when dealing with a difficult bug: I stripped everything down and pieced the tools and functionality back together, one by one. Next, I’ll detail the tools that worked for me, and I’ll follow with some important advice that I wish I’d found or that someone had given me when I was at the start of my journey.

My voice coding tools

I found success in just two weeks with just four tools.

Talon

Talon enables you to write code, play games, and control your computer with voice, eye tracking, or noises. It is certainly a powerful piece of software — but it is a heavy lift to set up. I was fortunate that I was able to afford some light use of my hands whilst installing and configuring my Talon setup, but it probably would have been impossible if I had zero hands to work with.

Talon is entirely geared towards software engineers. So much so, that setting up Talon requires being able to navigate your terminal, and write or install script files before you can even use any type of voice control effectively. Fortunately, the Talon community gives you a much-needed head start by providing a selection of useful scripts in the community repository on GitHub, which you can clone directly inside your .talon directory created on installation. This repository of Talon scripts allows you to get started relatively quickly in using VSCode and other IDEs, web browsers, email programs, work-based chat programs such as Slack, and even kubectl. Without this community repository, I would have been completely lost.

You can also fork the community repository, make some changes according to your needs, and clone that to your .talon directory. The current recommendation is not to modify too many files in the community repository, and to add your own files to make modifications where possible, to avoid any merge conflicts when pulling in new changes to the community maintained repository.

I also wrote a few of my own Talon scripts to make running commands in my terminal a lot easier, such as npm run dev (rather than having to spell them out), and you can view these in my talon-custom repository on GitHub. I also modified many of the default spellings from American to British English versions. Talon also has a very helpful Slack community, which is a bonus.

Cursorless

Cursorless is a tool to use in conjunction with Talon, to help speed up the way you navigate and interact with code in VSCode. The main superpower I have so far unlocked with Cursorless is instead of having to ask Talon to move the cursor down a few lines, or left a couple words, and then select some text and/or delete it, you can do all of that in one Cursorless command. Now, it is clearly far more powerful than that, but with Cursorless you need to start slowly, and you need to have learned the Talon alphabet before any of this is possible. More on that later.

Apple Voice Control

Whilst trying to get to grips with Talon, I found that Apple Voice Control was a good option for being able to use my mobile devices effectively, and for being able to complete basic tasks on my MacBook such as window switching, natural voice dictation and web browsing. I was particularly impressed with the ease of targeting clickable elements using the “show numbers” command, which assigns each clickable element on a screen a number that you can select with your voice. The way that the functionality of Apple Voice Control is mirrored across different MacOS and iOS devices is really well thought out, and I can see it working well for the most part for people who don’t need to code with their voice.

I will mention, however, that a number of web apps do not yet respond well to the text editing commands provided by Apple Voice Control, in particular Notion, which I use on a daily basis. Bear this in mind if you need to rely on Apple Voice Control for longer periods of time; it might just ruin your day. I had much better success using Talon with Notion when I had learned more of the Talon-specific commands.

Rango

With Talon on its own, navigating the web is still a challenge at first. Often I found myself switching between using Talon and Apple Voice Control so that I didn’t have to use the mouse functions in Talon to click on buttons and other clickable elements, because saying tab over and over again to reach my desired click target was time consuming and frustrating (not to mention that tab orders often suck on web pages, and click targets do not always have clear focus indicators) and I found it difficult to learn the Talon mouse commands. The Rango browser extension in conjunction with the rango-talon user file set gave me the same functionality of the “show numbers” command from Apple Voice Control, but without having to use the command itself, allowing me to click on any clickable target effectively using letters from the Talon alphabet, without having to say “tab” 100 times.

Other tools I tried with less success

Given that learning how to use my voice to work was frustrating, I fell into the trap of trying to find a tool that would give me back the power of typing code as quickly as possible. I tried two more approaches that I currently do not recommend.

Serenade

Serenade claims to offer you the ability to write code using natural speech, which sounds incredibly enticing, but I had limited to no success with this product. The tutorials gave promising results, but I have a feeling that Serenade is geared entirely towards React and Python apps, as when trying to write code inside a Vue/Nuxt app, Serenade didn’t understand at all how to do what it claimed.

Voice dictation to direct AI code generation

An interesting suggestion I received was to use voice dictation as a way to prompt AI code generation tools to write the code for me. I tried this using Claude inside Cursor and hated it. My end goal was to be able to use my voice to work in the way I was accustomed to, rather than switching to an entirely unfamiliar AI-codegen-based workflow.

Important advice for learning to code with your voice

Here are some of the things I wish I had known before learning to work with my voice.

Take it slowly

The one thing I wish that had been communicated to me from the beginning of my journey is that you have to start slowly. Really slowly. Using a computer and coding with voice is an entirely new, and let’s face it, alien skill. And with any new skill, you can’t be expected to go from zero to 100 in a day. The dissonance I felt with this though, is that I could already code, and I was frustrated that I couldn’t reach my typing levels of productivity faster. I had ideas I wanted to get into my IDE, I had a vision for an app that I wanted to build, and I hated the fact that my body wasn’t letting me do it.

Initially I installed Talon and Cursorless, watched two tutorial videos, and wanted to get to work. But I couldn’t; the landscape was entirely unfamiliar. I felt stuck. And then I had to force myself to do what any teacher would tell you when you got stuck: take it slowly. And start from the start.

Start from the start

When learning anything, it can be tempting to try and dive right into the deep end to get a head start. But if you can’t swim, you’ll drown. When learning to use Talon, you have to start from the start: the Talon alphabet.

Talon uses its own proprietary alphabet which allows you to dictate single letters. A common concern is why Talon doesn’t use the NATO phonetic alphabet to avoid needing to learn a whole different map of words to single letters. The answer is that the NATO phonetic alphabet uses a collection of words that are two or three syllables in length, whereas each Talon letter name uses just one syllable. This means that in using the Talon alphabet, you’ll be uttering less than half of the syllables needed compared to the NATO phonetic alphabet in order to be productive.

I learned the Talon alphabet fluently with around one hour of dedicated practise time on a Sunday evening, and this website in particular, which uses a flashcard system, was incredibly helpful: LearnTalon.

Ramp up gradually before trying to code

Before attempting to code, I would recommend learning a few more skills in using Talon to navigate and edit text (rather than jumping straight to Cursorless). This will also help you with general prose writing and navigating the web and your machine. Talon Practise was incredibly useful for this, giving you the opportunity to practise particular skills in small, focussed exercises. My favourite exercise which I was very excited to master was the copying, pasting and selection exercise.

Before using Cursorless, try using just Talon to edit some code. This will make the usefulness of Cursorless much more obvious if and when you decide to use it.

Try small coding tasks before big ones

We’ve all got jobs to do, and you’ve probably got quite a few big tickets looming over you on that project board. But you have to start small. Completing a small coding task with your voice, and committing and pushing the code in the terminal using your new-found Talon alphabet skills (gust sit trap space say commit space dash made space quote say completed small task quote slap), will give you a feeling of accomplishment like no other.

My first all-voice code change and commit was commenting out a function in my Twitch bot which I no longer needed, and committing and pushing that change in the terminal. Watch the clip on Twitch.

You will get better

After two weeks of using my voice to work and code for around 80% of the time, I was able to successfully (yet slowly) use Talon and Cursorless to add a whole new feature to my website, and I wrote about it here: How to build a copy code snippet button and why it matters. You will get better at this, but it will take time and practice. Make sure to take regular breaks, because using your voice so much will be exhausting, not to mention the new cognitive overheads of trying to do your job in such a different way.

Fortunately for me, my pain is also getting better and so I’ve been able to use my keyboard and trackpad more than I was able to over the last few weeks. That being said, given I have become comfortable with using my voice to code, write, and navigate the internet, I find myself switching between using my hands and voice throughout the day. Maybe it’s because I feel like I don’t want to lose this new skill that I had the necessity to learn, or maybe it serves as a cool party trick to demonstrate when live streaming. But more importantly, it hammers home the fact that one day we all might succumb to a temporary or permanent disability, and as web developers we have an important responsibility to build empathy and accessibility into our professional practice at all times.

It is extremely difficult to highlight blocks of code and copy them with voice commands. At this point, for me at least, it is impossible. (Either it is actually impossible, or I haven’t had the brainpower to work out how to do it yet. Learning to navigate the web and code without your hands takes a huge mental toll.) For this reason, when you’re writing about code, especially when you’re creating tutorials that involve the reader copying and pasting code, it is absolutely imperative that you include a way for people with limited use of their hands to copy that code in a single action.

Prior to my experience with carpal tunnel syndrome, I was of the opinion that a copy code button was superfluous. But I was wrong. And so, one of my first voice-based coding tasks was to add a copy code button on all code snippets featured on my blog posts. I am working on another blog post where I talk about my voice coding journey, but in case you’re interested, the tools I have been using are Talon and Cursorless inside VSCode. Relearning how to do everything on a computer with your voice involves a steep learning curve, but this whole endeavour is giving me some pain relief already. And yes, I am writing this blog post with my voice as much as my tools allow.

My copy code snippet button solution is written in plain HTML, CSS and JavaScript inside an Eleventy project using the JavaScript templating engine (hence the use of string interpolation with curly braces).

The HTML (and some preliminary JavaScript to build the HTML)

In a blog post about code, you’ll probably have more than one code block snippet on the page. For this reason, you need to assign each code block with a unique ID in order to target the correct content to copy. You can generate a unique ID in any way you like, such as by using an external library to do so, but here’s how I did it for each code snippet at build time.

Copy

function makeId(length) {
  let result = "";
  const characters = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
  const charactersLength = characters.length;
  let counter = 0;
  while (counter < length) {
    result += characters.charAt(Math.floor(Math.random() * charactersLength));
    counter += 1;
  }
  return result;
}

const thisCodeID = makeId(10);

Given that formatted and syntax-highlighted code blocks will contain extra HTML and CSS classes to power the formatting and highlighting, we need to ensure that the copy button only copies the raw code content to the clipboard. My solution to this was to store the raw code string in a meta tag for easy retrieval in JavaScript (in contrast to stripping out extraneous HTML tags; and even then, we wouldn’t want to strip HTML tags from an HTML code snippet!).

Given we are using meta tags to store information, and we like to write valid HTML in 2025, we need to add some extra markup to satisfy Schema.org vocabulary, and describe the the type of data we are using inside the meta tag. When storing the raw code string in a meta tag, you’ll also want to use encodeURIComponent so that the code doesn’t actually execute on the page if it is able to (such as in the case of JavaScript). This meta tag lives inside to each code block on my blog posts, with the following Schema.org properties:

Copy

<div data-code-block itemscope itemtype="https://schema.org/SoftwareSourceCode">
  <meta itemprop="codeSampleType" content="snippet">
  <meta itemprop="programmingLanguage" content="${lang}">
  <meta data-code-id="${thisCodeId}" itemprop="text" content="${encodeURIComponent(code)}">
    ${HighlightPairedShortcode(code, `${prefix}${lang}`)}
</div>

It's also worth noting that I am using the syntax highlighting plugin from Eleventy, hence the use of highlightPairedShortcode and why I cannot easily access the code sample with innerText as easily as you might expect.

Here's how Schema.org interprets the structured data described in the markup:

Next, add a button next to or inside the code block, referencing the unique identifier you created earlier. I also chose to add a little clipboard SVG icon next to the button text. If you choose to omit the button text and use an icon only, make sure to use an aria-label to ensure the button has an accessible name (e.g. "Copy code snippet") that can be understood by assistive technologies such as screen readers.

Copy

<button type="button" data-copy="${thisCodeId}">
  Copy
</button>

The CSS

I’m not going to prescribe how to style this copy button on your own blog posts, but I chose to position mine absolutely at the top right of each code block. Ensure you include styles on the button for focus, active and focus-visible to ensure that people who are reading your blog posts without a mouse and navigating through the clickable elements using a keyboard or their voice have a clear indication of which element is currently focussed and has been clicked.

The JavaScript

Finally, use JavaScript to find each copy button on the page, and add the following event listener to each button. This code grabs the unique identifier for the raw code snippet from the button, finds the relevant meta tag, and copies the raw code stored in that meta tag to the clipboard. Ensure to use decodeURIComponent to copy the raw code snippet to its original form.

Copy

const copyButtons = document.querySelectorAll(`[data-copy]`);

copyButtons.forEach((button) => {
  button.addEventListener("click", (e) => {
    const codeId = e.target.dataset.copy;
    const codeAsText = document.querySelector(`[data-code-id=${codeId}]`).getAttribute("content");
    navigator.clipboard.writeText(decodeURIComponent(codeAsText));
  });
});

This solution will transfer pretty well to your favourite front end framework of choice. And remember, temporary disabilities can happen to anyone; none of us are immortal.

I’m also hesitant to publish a 2024 roundup because it has, once again, been a shit year for me. But I have already written about much of that. So in the spirit of self-love and positivity and a renewed sense of hope ignited within me by the days getting longer in the northern hemisphere, I will now force myself to list all of the things I did on the internet (and beyond) in 2024.

Writing

In 2024 I published 24 blog posts; 11 were written as part of my job for Sentry, and 13 were my own. I published more personal, life-based posts than usual in 2024. Whilst being vulnerable on the internet is scary, these personal posts resonated with a lot of people. I received countless emails and DMs from friends and strangers on the internet who had experienced or were experiencing similar things in life, and who found comfort in my vulnerability. One person, in particular, has become what I consider a good friend who I turn to in moments of internal crisis. (You know who you are.)

Speaking

In 2024 I delivered my talk Entertainment as Code a total of five times. I travelled to Norway, Toronto, London, Middlesbrough and gave the talk online. It was a really interesting process to give an evolving conference talk throughout the year, whilst the underlying project I was speaking about simultaneously evolved. I would strongly recommend delivering a talk multiple times. After all, musicians and comedians and theatre performers don’t just do a thing once and move on to the next thing.

Streaming

I continued to live stream on Twitch regularly, until I took a forced break in Q3. Streams this year focussed mainly on building my silly text-based community game p4nth3rworld, which is what powered this year’s conference talk. The project culminated in a hack week in August 2024, where I streamed for 25 hours across five days working on the game. I’m not sure if I will continue working on this much more into 2025, despite there still being a sizeable backlog of feature requests. In fact, I am ruminating on a blog post about when and why to archive a project. Stay tuned.

Newsletter

In 2024 I launched a newsletter: weird wide web hole. Each issue contains four links and some words from my brain at the time. I sent 50 issues and gained 350 subscribers. The open rate averaged at 50%, and retention at 90%. I came up with a formula that made building and sending each issue quick and not stressful, and something I would like to receive. The most important thing I wanted to focus on is to enjoy sending this newsletter, and after a full year I still do. The weird wide web hole will continue to open up every Thursday in 2025; subscribe here.

Career

Towards the end of 2024 I started thinking more intentionally about how my career might evolve over the next few years. I’ve had some good conversations with some very clever people, and have started exploring Developer Relations through a more learned and strategic business lens. Two blog posts I published in 2024 were on this topic (Defining paths to business value in Developer Relations and Stop writing SEO-first! These are the 4 types of DevRel content (plus their Leading Themes) and have been very well received.

Hobbies

I’m still working through another huge cross-stitch and I’ve been reading more. I had to forego my drum lessons for the last part of 2024, but I’m starting up again this month. And in 2025 I’m determined to actually produce that new piece of music that I’ve been promising myself since March 2020.

2025

As I approach 40 this year, I am beginning to understand why people say “life begins” at 40. As time goes on, I learn more about myself, and the world, and how to interact with it more intentionally and more calmly; I have fewer and fewer opinions about things I cannot change. Whilst my priorities are centred on health, wellbeing, family, friends, and peace, I am starting to feel pretty well-equipped to navigate this weird industry landscape without burning out, and perhaps, you could even say, thrive.

As my friend Daniel Roe said on Bluesky:

you're thoughtful and very funny and don't hide what you really think

I think you don't think as highly of yourself as you deserve though

In 2025 I’ll try, Daniel. I’ll try.

Sometimes, our bodies speak louder than our minds. Some days, we are more tired; we ache, we find it more difficult to get out of bed. This is true for me, especially in the dark winter months. And so we are forced to take it slow on those days. We know we need the rest, and yet we feel guilt. We feel shame. We berate ourselves for not being able to fully submit ourselves to our labour. We apologise for not getting that thing done, even though there was no arbitrary deadline. And those feelings of guilt and shame send is spiralling into exhaustion. It is a literal vicious cycle.

It’s OK to have a slow day. We all need slow days. We need days where we can think and reflect. We need days where we can create space to make important decisions without the inevitable pressure of time and artificial emergencies. Slow days allow us to recharge our bodies and our minds, so that we have the mental and physical energy to think more creatively and more innovatively. Think about those times when you step away from the code and finally solve that bug you’ve been working on for hours. You need to step away more often.

Productivity and progress is not only measured by deliverables, such as lines of code, features, or blog posts. You are more than what you produce. You are your ideas, your thoughts, and your actions. Ideas come to healthy, energised humans. Ideas come to those who make space and make time. And actions can only be performed by those who have the energy, when they made space and time to rest.

It’s OK to have a slow day. I wrote this on a slow day.

Live coding streams are (usually) centred on building something in public and collaborating with viewers as part of the process. Imagine a live coding stream in the real world: a group of software engineers, all sat around a whiteboard in a conference room or around a laptop in an office, trying to solve a problem. You probably imagined a group of fewer than ten engineers, right? Now imagine if you tried to cram hundreds of people into that space and wanted to solve the same problem. It would be chaos, right? Collaborating is very, very difficult to do well when hundreds of people are attempting to “collaborate” at anyone time.

What I have experienced, is that live coding streams actually benefit from fewer viewers. Fewer viewers are usually more engaged because they have more space to engage when chat isn’t scrolling at 100mph. As a streamer, when I have fewer than 100 concurrent viewers, I am able to read and fully engage with each member of chat and what they have to offer. I don’t miss any ideas; everyone in the virtual room gets input. I am also able to physically reply to each viewer, making them feel seen, and as a result, they will hopefully become more engaged in what I have to offer, and return to the stream in the future. And the cycle continues. Yes, there are chat slow mode options you can use to avoid chat-overwhelm, but as a live stream viewer myself, I tend to view this as a barrier to entry to a stream (”Oh no, it’s busy in here, I won’t be seen”).

Being able to respond to and engage with all of your viewers as fully as possible helps build a sense of community around what you're building and why you're building it. That’s why I believe your live coding stream does not need a bigger audience. You just need an audience.

• labelling each content piece with a “type” (Academic, Guide, Tutorial), and

• identifying the “Leading Theme” of the piece (Product/SEO, Contrived Example, Real Experience).

Here’s a small snapshot of the data using some of my own content as examples:

I discussed this data with Sarah Guthals, and compared it with her own independent analysis of the same content. We also collected some quantitative data on some of the highest and lowest performing content pieces based on “views” and “visits to the sign up form”. This led us to formally define four types of DevRel content, where each should communicate a particular Leading Theme as standard.

The 4 types of DevRel content

Whereas we initially defined three types of content and used these to categorise existing pieces, we agreed to expand the types to four, which were more representative of what we wanted to aim for: Academic, Guide, Dev Tips, and Tutorial. The Leading Themes are described as follows (in the context of DevRel at Sentry):

• Product: How Sentry helps

• Contrived Example: How Sentry can help in a particular (potentially abstract) challenge

• Real Experience: How Sentry helped in a real product with real users

The table below aims to concisely communicate the preferred Leading Theme and Goal of each of the four types of DevRel content. Where I have used the word “TOOL”, this would usually be substituted for the name of the product or company you are writing/recording/speaking about or for (i.e. Sentry). I have included representative examples of my own content to practically demonstrate each type.

Which type of content “converts” better (and therefore provides more business value)?

The type of content that performed best in our content database was Guides. Now, the content that we produce as DevRel, isn't necessarily aimed at converting readers to sign-ups as a standalone effort; each piece of content is part of a larger campaign to educate developers on topics, challenges, and solutions for which the TOOL is useful. So while our conversion rate from view > visit to the sign up page was around 3% for Guides, we leverage that as an early indicator of success, not as our singular success metric.

As a result of this, and given our discussions internally, a company with a TOOL like Sentry should focus larger chunks of DevRel time on Guides and Dev Tips. From experience, Guides and Dev Tips are:

• less time-consuming to create, and

• easier to centre on real examples and experience than Tutorials or Academic pieces.

In focussing your efforts on Guides and Dev Tips, you should end up being able to deliver more value (e.g. conversion however you define it) more efficiently, whilst at the same time providing developers with clear real-world examples of challenges and successes. For example, in response to my latest Guide How I reduced an API call from >5 seconds to under 100ms, Blueskyer Oliver Turner said “what a fab example of good Dev Rel this was: a highly relatable real-world example, neatly solved with the help of the product.”

Stop creating SEO-first content

Notice how SEO (Search Engine Optimisation) is not a leading theme in this framework, despite being used in the original classification exercise. In DevRel, we know content is often created because companies want to show up in search engines for certain keywords, but, interestingly (or perhaps, not-so-interestingly), SEO-first content tended to be the worst performing in terms of conversion from views > visits to a sign up form in our limited dataset, with the exception of a few timely pieces such as What is INP and why you should care. It could also be argued that, despite the main motivation for writing this piece being heavily weighted toward SEO, it ended up being a Guide anyway — which is the better approach.

As someone working in DevRel, you may receive requests related to using keywords so that a company can show up in search results (coincidentally my INP post was the top featured post on Google when INP was launched), but you will be doing your company a disservice by leading a piece of content with SEO. In DevRel, your job is to create something useful for developers, and depending on your usual audience, a Guide or a Dev Tip is probably preferable. In the INP post, I intentionally did not lead with SEO, but addressed a real topic facing developers today (INP), was aware of the company's desire to show up in search results for INP, and yet focused on providing actionable insights for developers.

There is a particular piece of content I wrote (not at Sentry) that haunts me because I wrote it entirely for SEO purposes on the suggestion of a colleague in marketing, and did so begrudgingly. It is probably the only piece I did not archive on my own domain. Let me know if you ever track it down and we can laugh/cry together.

Do this exercise for yourself

I would highly recommend doing the content classification exercise for content that your DevRel team has created to help you identify:

• whether the right things for your team and company product are determining your Leading Themes,

• whether your content pieces have clearly defined goals, and

• whether you have any gaps in your content types.

To get you started, I’ve put together a template in Google Sheets, where you can list your content pieces and start categorising by type and Leading Theme. I’ve included the Product/SEO Leading Theme despite it not being the most desirable one in DevRel, given this is a useful insight into how content is often created. Open the DevRel Content Classification spreadsheet, make a copy, and give it a go. If you have data available relating to your success metrics, see if you can find any correlation between the different types of content approaches and success. I’d love to know what you discovered — let me know on Bluesky!

Since the age of 16, when I started earning my own money, I enjoyed buying clothes. Online shopping wasn’t really a thing in the early 2000s, and so at this point it wasn’t really a “problem”. However, when I gained more independence and started driving at age 17, I would take every opportunity to travel to the local shops to buy something. It didn’t matter what it was; I just needed something.

I moved out of my childhood home at age 18 and never looked back. After some talking therapy in my early twenties, I realised that I had been buying clothes to cope with the pervasive emotions that stemmed from an abusive childhood. But this type of realisation goes only some of the way to fixing the problem. I spent most of my twenties reinventing myself through a constant cycle of buying, selling and donating clothes. I went through a goth phase, a boho hippy phase, an all-black phase, and more. Each new reinvention would require a considerable initial investment to ensure my outward appearance was cohesive and put-together, which I justified through the hassle of selling everything on eBay from the previous phase. This continued throughout my thirties.

In December 2023, I found myself in a Youtube hole on the theme of “not buying things”. I was inspired to follow suit, and not buy any new and unnecessary clothes in 2024. I put together an elaborate Notion page; I made rules about what I was allowed to buy and what I wasn’t allowed buy, and what I could buy if I truly needed to replace something. This prompted me, again, to sell or donate a lot of clothes that I didn’t wear regularly. My “no buy” lasted until March 2024, when I broke the seal by purchasing a new sweatshirt, because I convinced myself I needed something to pep me up for a conference trip to London. And so began another cycle of reinvention: clearing out and selling more clothes, and replacing them with sustainable, timeless, and classic pieces. These were clothes that were going to take me into my fifties. This was my “investment piece” cycle. This was the last cycle, just one more reinvention bro, I promised myself.

This year was going well, actually. Whilst I joyfully abandoned the concept of not buying anything at all, each clothes-based purchase for the most part was carefully considered. I convinced myself that because I was using a clothing inventory app, (which I even talked about on Bluesky) and because I made sure that each item I was adding to my wardrobe could make X number of outfits, I was shopping the right way. However, as autumn set in, and the days got darker, I found myself drawn towards the lure of buying things to make me feel something. Just one more item bro, then I’ll be the perfect person; I’ll be complete. And then, something stupid happened.

I can’t even remember how this happened, but two days ago, I became obsessed with a coat. I don’t even know how I came to know about this coat, where I found this coat, or what part of the internet showed me this coat. But for 24 hours, this coat was everything to me. It was my next step to achieving the perfect version of myself. I researched everything about this coat. I watched videos, read blog posts, looked for good reviews, bad reviews, researched the sizing, the materials: everything. I found every single shopping website that stocked this coat. But I didn’t buy this coat. Because I couldn’t justify the cost. And plus, I already have two winter coats, and I like wearing them.

After giving myself 24 hours to consider this purchase, (and convincing myself that this was enough time to really consider this purchase), I bought the coat. I didn’t need the coat. But there it was: the dopamine-fuelled high of a new purchased followed very quickly by a sinking feeling of guilt, shame, and disgust. I was fully aware of what I was doing and why I was doing it; but I did it anyway.

Last week I spoke to my doctor about symptoms I had been attributing to a somewhat early menopause that I had been monitoring for around 18 months (to cut a long story short, most of my cycle involves feeling very depressed and nauseous). Given my age (39 at the time of writing), the doctor dismissed my concerns of peri-menopause given that my periods are still regular and normal, and suggested that maybe I try some anti-depressants or the combined pill to ease my symptoms of extreme PMS. I rejected this idea; I haven’t had a good experience in the past with SSRIs or SNRIs (which I used in combination with therapy to try and deal with my childhood) or any type of contraceptive pill.

But when I clicked “confirm purchase” on the coat, it hit me. “Around 18 months ago” is when a string of crappy life events came at me, one after the other.

• In March 2023, my dad died;

• In July 2023, I got laid off;

• In August 2023, in the midst of many interview cycles, my husband had his first seizure, which set off a string of health-related issues culminating in a long hospital stay in September 2024;

• The world has been pretty fucked this past year;

• And throughout all of this, my mother has continued to reject me, despite the promises of a renewed relationship after the passing of my dad.

Since March 2023, I haven’t been OK, but I figured it was my age and my hormones. But I know now that I am still trapped. Trapped in an endless cycle of trying to be OK, thinking I’m OK, acting like I’m OK, but being consumed by my desire to be loved and accepted, which manifests in buying clothes to reinvent myself.

And yet, I am determined to be OK.

The coat hasn’t arrived yet. Maybe I’ll send it back. Or maybe I’ll keep it. Maybe I’ll wear the shit out of it to remind me that I do have insight about my emotions. I know that I still have unmet needs from my childhood, and I'll probably have to live with this forever. And deep down, I know that a stupid impulsive purchase will not fix me.

Yet, I am determined to be OK.

Update: I returned the coat. It made me feel nothing whatsoever.

Four years later in 2024, this tiny side project became much larger than I ever expected, and evolved into a text-based game: Pantherworld. If you’re curious about how this evolved and would like to learn more about how this project grew from a tiny Twitch bot to a game, watch the latest edition of my 2024 conference talk, Entertainment as Code, on Youtube.

Pantherworld has been played by hundreds of people, 24 hours a day, 7 days a week via my Twitch chat interface since April 2024. Game events in Pantherworld are powered by events that happen on my stream. When something happens, such as when I get a new follower, a random world item spawns in a random world zone. The objective is for my stream audience to use text commands in the Twitch chat to move around the world and claim items to fill up their inventory. Some items are rarer than others, so will spawn less frequently.

To enable players to keep track of gameplay activity, I built a front end companion app, which fetches game data from the NoSQL database via a collection of APIs. As the game attracted more and more players, there was one API call that very obviously didn’t scale: the endpoint that fetched the leaderboard data. It was painfully slow, but I had no idea why it was slow. I added a skeleton loader on the front end (instead of showing just a blank screen) to try and hide how slow it was, but it was painful to watch.

It’s important to reiterate that my data-based mental model has always defaulted to a relational one, and so I figured I was just doing NoSQL wrong but I didn’t know how I was doing it wrong. Additionally, this app had evolved so much over four years of development that the data model requirements changed to actually require a relational model, and so my initial gut reaction was to refactor the whole thing to use an SQL database. But I couldn’t face refactoring a four-year old legacy app and migrating hundreds of thousands of NoSQL documents to SQL. It was time to turn to tracing to help me understand how I could optimize this terrible code.

What is tracing?

Tracing is a technology that captures each function call, database query, network request, browser event — everything that happens in your app — allowing you to understand how your apps actually work and expose where you may be able to make performance improvements or squash bugs. In Sentry, singular events are named spans, and they are connected in the Trace View via an HTTP header sent with each span. You can also capture all of these events across your entire stack of apps and services, which is known as Distributed Tracing.

How to add tracing support for MongoDB database queries

Tracing for MongoDB database queries is supported out of the box for the latest version of the Sentry JavaScript and Python SDKs; no further setup required. My backend API is an Express app, so I’m using the latest version of the Sentry Node SDK. It’s recommended to keep all Sentry SDK initialization code in a separate file; mine is named instrument.ts. Here’s a stripped down SDK configuration in showing the most relevant options:

Copy

// instrument.ts

import * as Sentry from "@sentry/node";

Sentry.init({
  // unique Sentry project DSN (Data Source Name)
  dsn: process.env.SENTRY_DSN,   
  // add environment to context in Sentry
  environment: process.env.NODE_ENV,
  // send 75% of traces to Sentry   
  tracesSampleRate: 0.75, 
});

The tracesSampleRate option tells the Sentry SDK to enable tracing. It takes a value between 0 and 1, and configures the percentage of traces your app will send to Sentry. It’s recommended to adjust this number based on your Sentry account plan and how many users your apps have.

To enable Distributed Tracing (i.e. trace from a front end app to a back end app), make sure to add the browserTracingIntegration to your front end Sentry SDK configuration in addition to setting the tracesSampleRate. Exceptions to this rule are full-stack front end frameworks such as Next.js and Nuxt, which add the browserTracingIntegration by default.

In the back end, to ensure that Sentry can automatically instrument all modules in your application, including MongoDB, make sure to require or import the instrument.js file before requiring any other modules in your application. Here are some of the imports at top of my app entry-point file, app.ts as an example:

Copy

// app.ts

import "./env";
import * as Sentry from "@sentry/node"; // <---- first imported module
import { webServer } from "./webserver";
import Database from "./data/database";
import WebSocketServer from "./WebSocketServer";

//... all other code

Now we’ve got tracing set up to capture MongoDB queries in my Express app, let’s investigate why my code for the leaderboard was so slow.

Why a single API call was taking >5 seconds

Here’s a snapshot of traces before I made the code optimizations, with the durations of the API calls highlighted. HTTP GET requests to the /world/leaderboard API were taking anywhere from 4 to almost 8 seconds.

The (zoomed out) Trace View for a single API call exposes a series of request waterfalls and duplicate database queries. Something had to be done.

Before we explore how I reduced this API call from >5 seconds to under 100ms, let’s look at what happens when a call to /world/leaderboard is made by the front end app.

The leaderboard API call returns an array of players. Each Player object contains a username, an items count, and a wealth_index number (where the wealth index is a sum of all inventory items multiplied by their rarity).

Copy

// leaderboard.ts

type Player = {
  username: string;
  items: number;
  wealth_index: number;
};

export async function getFullLeaderboard(): Promise<{players: Player[]}> {
	// ...
}

Here’s the original code, slightly simplified. It does the following:

1. Queries the Items collection to fetch all items that are assigned to a user, groups the items by userId, and returns a count of those items

2. For each player, calls getAllItemsForPlayer() (which queries the Items collection again)

3. For each player, queries the Player collection (and the only purpose of this was to retrieve the userDisplayName which I didn’t want to store alongside the item data; a SQL join would have been nice here)

4. Constructs and calculates each Player object, pushes it into an array, sorts the array, and returns it.

Copy

// leaderboard.ts

// imports...

function sortByWealthIndexDesc(a: Player, b: Player) {
  // ... standard sort function
}

export async function getFullLeaderboard(): Promise<{players: Player[]}> {
  const players = await PantherworldItemModel.aggregate([
    {
      $match: {
        userId: { $ne: null },
      },
    },

    // Group documents by userId, count the number of items in each group
    { $group: { _id: "$userId", itemCount: { $sum: 1 } } },
  ]);

  const leaderboardPlayers: Player[] = [];

  const promises = players.map(async (player) => {
    const allItems: ItemForWealthIndex[] = await getAllItemsForPlayer(
      player._id,
    );

    const dbPlayer = (await PantherworldPlayerModel.findOne({
      userId: player._id,
    })) as PantherworldPlayerData;

    leaderboardPlayers.push({
      username: dbPlayer.userDisplayName,
      items: player.itemCount,
      wealth_index: getWealthIndex(allItems),
    } as Player);
  });

  await Promise.all(promises)
    .then()
    .catch((err) => {
      Sentry.captureException(err);
    });

  return {
    players: leaderboardPlayers.sort(sortByWealthIndexDesc),
  };
}

You can probably already make some guesses about the improvements that can be made. Let’s talk through the mistakes.

Mistake #1: I didn’t test with production-like data

When I wrote the leaderboard API code and tested it in development, it didn’t feel slow. It was only when I pushed the feature to production that I noticed how slow it really was. My development database contained less than 20% of the game data compared to production — and it wasn’t growing — whereas my production database was growing hour by hour, adding around 30 items and 10 players to the world per hour.

Mistake #2: “helper” functions aren’t always helpful

In trying to be a diligent and DRY (Don’t Repeat Yourself) developer, I reused an existing “helper function” — getAllItemsForPlayer() — which calculates a player’s wealth index. The problem is getAllItemsForPlayer() made a call to the Items collection to get inventory items for every... single ...player. If this code were written inline (and not abstracted out to another function), it would have been self-documenting that it wasn’t the right call to make n calls to a database (where n is the number of active players) because I’d already queried the Items table at the top of the function. I already had access to that data in the first database query.

Mistake #3: I copied and pasted code not fit-for-purpose

Before the full leaderboard API, I had written a small function to find the top three players in the game by item count, which was originally displayed on the home page. It made the following query on the Items collection:

Copy

const top3 = await PantherworldItemModel.aggregate([
  { $match: { userId: { $ne: null } } },

  // Group documents by userId, count the number of items in each group
  { $group: { _id: "$userId", itemCount: { $sum: 1 } } },

  // Sort the groups by itemCount in descending order
  { $sort: { itemCount: -1 } },

  // Select top 3
  { $limit: 3 },
]);

When you compare this code to the first query in the original getFullLeaderboard() function above, it’s the same code, just with the $sort and the $limit. Big mistake. In querying the Items collection in the full leaderboard API, I already had access to all item data, meaning I didn’t need to loop through the grouped array and use the “helper” function to getAllItemsForPlayer(). Instead, by using the $push operator in the Items collection query, I could create an array of objects mapping user IDs to an array of items owned by that user, like so:

Copy

const itemsGroupedByPlayer = await PantherworldItemModel.aggregate([
    {
      $match: {
        userId: { $ne: null },
      },
    },

    // Group documents by userId and push all items into an array
    { $group: { _id: "$userId", items: { $push: "$$ROOT" } } },
  ]);

  // Returns an array of objects shaped like this:
  // { _id: '12345', items: [...] },

How I reduced the API call from >5 seconds to under 100ms

The main culprit in this slow API call was the “helper” function that called the database n times, where n is the number of players. I removed these extra n database queries by fetching all data from the Items collection once and using $push to group the data I needed (rather than discarding it).

There was, however, some more work I had to do to build up an array of items in a particular format to be able to reuse another helper function which calculates a player’s wealth index. But it was worth it. The leaderboard function now only makes two calls to the database: one to the Items collection, and one to the Players collection. Here’s the refactored code, simplified for brevity:

Copy

// leaderboard.ts

// imports...

function constructItemsForWealthIndexCalculation(
  items,
): ItemForWealthIndex[] {
	// ... 
	// this function sorts the raw items data into something usable
	// for the helper function getWealthIndex()

  return itemsForWealthIndex;
}

function sortByWealthIndexDesc(a: Player, b: Player) {
  // ... standard sort function
}

export async function getFullLeaderboard(): Promise<{players: Player[]}> {
  const itemsGroupedByPlayer = await PantherworldItemModel.aggregate([
    {
      $match: {
        userId: { $ne: null },
      },
    },

    // Group documents by userId and 
    // push all items with that userId into an array
    { $group: { _id: "$userId", items: { $push: "$$ROOT" } } },
  ]);

  const leaderboardPlayers: Player[] = [];
  // get all player data in one query using the $in operator
  const allPlayerRecords = await PantherworldPlayerModel.find({
    userId: { $in: itemsGroupedByPlayer.map((player) => player._id) },
  });

  for (const player of itemsGroupedByPlayer) {
    const itemsForWealthIndex = constructItemsForWealthIndexCalculation(
      player.items,
    );

    leaderboardPlayers.push({
      username: allPlayerRecords.find(
        (playerRecord) => playerRecord.userId === player._id,
      ).userDisplayName,
      items: player.items.length,
      wealth_index: getWealthIndex(itemsForWealthIndex),
    } as Player);
  }

  return {
    players: leaderboardPlayers.sort(sortByWealthIndexDesc),
  };
}

And here’s how the trace view looks after the optimizations: now under 100ms! I call that a success.

The bottom line: tracing takes out the guesswork when debugging performance issues

Without tracing, I probably could have messed around in my code for a while to find the root cause of the performance bottleneck. However, with tracing, what was causing the slowdown was obvious; Sentry showed me a clear visual representation of what was going wrong. As developers, we’ve all got jobs to do, and we’ve all (probably) got deadlines as well. Tracing is one of those things that helps us get our jobs done. And by taking out the guesswork, we can get our jobs done well and efficiently, giving us more time to go and touch grass.

What is DevRel, exactly?

DevRel is often a tricky sub-industry to define within the technology industry itself because its function looks different (and should be different) depending on the business in which it operates. To further complicate the definition, DevRel is the umbrella under which three further distinct functions can be defined: Developer Marketing, Developer Education, and Developer Experience. Due to my own experience, this article leans more heavily to discussing Developer Education and Developer Experience.

The activities and output of a member of a DevRel team (in any of the three categories) can include, but is not limited to:

• technical writing (e.g. documentation)

• one-off technical tutorials (written or recorded videos)

• multi-part technical courses (written or recorded videos)

• technical workshops

• example code and projects

• contributing to Open Source projects

• QA/testing for (new) product features

• hosting, speaking at, or attending tech conferences and meet-ups

• hosting hackathons

• social, advertising, event copy, and other forms of short-form content geared toward marketing a product

• community support and troubleshooting

• supporting paying customers with technical solutions

• supporting a sales team

A DevRel audience consumes only the output of what a DevRel team creates, often without the context of the how or the why. As a result, DevRel activities are often reduced to “content creation” within a marketing context, which positions DevRel as a task-based function — both internally and externally to a business — without holistically considering the impact and value of said tasks.

DevRel is not content creation

Throughout my DevRel career, the focus of a DevRel team has rarely centred on “content creation” for the sake of itself. In my lived experience, core DevRel activities have always emerged from a desire to help developers solve problems and build better software — regardless of whether or not they are actually using a particular product or piece of tech. The output of these core activities are often content (written, recorded, code samples, live video), but that content is nearly always a side-effect of building real apps with real users. To summarise, at the core of DevRel is:

• helping developers solve problems and build better software

• building real apps with real users

However, it is incredibly difficult to quantitatively measure how much you have helped a developer solve problems and build better software. Sure, you could collect qualitative testimonials and excited replies on social media; trust in you will grow over time and people will choose to actively seek out your resources, opinions and expertise. Your earned reputation as a technical representative of a company will contribute to how much developers trust said company, and its products. This is great for the ✨vibes✨, but this doesn’t translate clearly and effectively to quantitative value.

And what is quantitative value to a business? Money. Sign ups. Paying customers. Line graphs go up. Return on investment for shareholders. Stonks. 📈

How can DevRel provide business value?

Providing business value in a DevRel team does not mean you must dedicate your activities and output to gaining sign ups and paying customers only. But what it does mean, is that:

Most DevRel activities must define a path by which they contribute towards generating monetary value for a business.

We cannot reduce this to simply adding a “sign up” link to every piece of content or activity and hoping for the best. And it also doesn’t mean that you can’t be creative and have fun; because what we can group all activities under is building real apps with real users.

Defining paths to monetary value by building real apps with real users

Given DevRel teams are often small in size, building real projects is an activity often sacrificed for churning out content that provides an immediate quantitative measure of “success”, i.e. we shipped 5 blog posts this month. But building real projects that have real users is really the only way you can experience a product just as the customer does, so you can find the same pain-points they do. And because you work for a software company, you have a direct line to the teams and engineers who build the product, and you can advocate for making it better for users, so they don’t stop paying for the product (churn). When I worked with Phil Hawksworth at Netlify, he referred to a DevRel team as “the bridge between the customers and the engineers”; and I agree.

We can split a DevRel audience into three broad categories of developers or customers: paying users, non-paying users, and non-users. These three categories define three broad business outcomes:

1. Reduce customer churn (lost customers and revenue),

2. Increase customer conversion to paid features, and

3. Increase new customer sign ups.

DevRel activities and deliverables should target multiple categories and serve multiple purposes to demonstrate maximum impact. Let’s take a look at a few examples at how activities can create paths to the broad outcomes defined above. I will use examples that I have experienced personally through being intentional about making an impact in those areas, through helping developers solve problems and build better software by building real apps with real users.

1. Reduce customer churn

To reduce the risk of losing customer accounts, and therefore revenue, DevRel has a role in helping make a product as good as it can possibly be to use. This might often be referred to as the practice of Developer Experience. And in order to understand how the product can be better, you have to experience using it.

For a company like Sentry (an application error and performance monitoring SaaS tool), it is particularly important to build real apps that have real users. Unless you want to spend time automating fake user visits and fake user journeys to your app, you need real users to generate real data in a Sentry account. If you don’t collect a broad range of data from how users use your apps on different devices, in different browsers, and in different locations for example, you might not find an edge-case bug that, when fixed, saves a large customer account from churning.

This is one of the reasons I’ve been building Pantherworld at work. Pantherworld is a text-based game, and has been played by hundreds of people, 24 hours a day, 7 days a week via my Twitch chat interface since April 2024. It’s a distributed app (separate back end and front end) built with Express, MongoDB and Nuxt. At first, this project may appear out of scope of the working hours of a Senior Developer Relations Advocate, but the key thing here is that Pantherworld uses Sentry. I am constantly dogfooding the product whilst building a real app with real users.

2. Increase customer conversion to paid features

This path is definitely more about marketing to existing customers, but it can still be done through building real apps with real users. In building Pantherworld, I have given many live demonstrations of Sentry in a real-world debugging context, which can encourage viewers who are existing customers to upgrade to more paying features. The same can be said for workshops, which are usually delivered by one or more DevRel team members as part of a more formal existing customer outreach programme. When creating and delivering the workshops, you will likely also be building a real app with real users to demonstrate the product effectively, and undertaking another variety of activities detailed below. It's all about giving a relevant, polished, yet authentic product demo.

3. Increase new customer sign ups

Increasing new customer sign ups is about widening the net of your influence; and this is where you can get really creative in helping developers solve problems and build better software through making the apps you want to make with the tech you want to use. Granted, this path will usually involve a series of broad approaches and experiments, but here are some generic tips that help you widen your net:

• Learn how to optimise for SEO: if developers can’t find your content, they can’t read it;

• Learn how to tailor your content for different platforms (e.g. social platforms and their purpose);

• Experiment with different media formats and approaches, gather data, iterate, repeat;

• Aim to inspire developers with innovative solutions and attention-grabbing concepts (make it fun); and

• Build trust with developers through building real apps with real users, just like they are.

Activities, paths, and overlap

Here is a non-exhaustive list of some of the DevRel activities I regularly undertake as part of building real apps with real users, the goals each activity have contributed toward, and the defined path to those goals.

Each activity is intentionally designed to help developers solve problems and build better software through building real apps with real users. In doing this you are able to:

• Engage with developers (potential paying customers) authentically and effectively by speaking their language and sharing experiences,

• Use your technical expertise and experience gained through building real apps to help developers solve problems and build better software with innovative solutions in new contexts, and

• Build trust in the community as a credible technologist who builds real apps with real users.

Closing thoughts

DevRel is not content creation. DevRel is not about views, engagement, or followers; although if those metrics are higher, you may increase your probability of reaching more developers. But that has little to no business value if your offering doesn’t define a path to reducing customer churn, increasing conversion to paid features, or increasing new customer sign ups, at the same time as building trust with the developer community. When all is said and done, developers want to use and pay for good tech that helps them solve problems and build better software. DevRel has an important part to play in ensuring that what a company is selling is good, and that product features are communicated effectively and authentically, borne of real-world technical experiences.

I believe that if you maintain a primary focus on helping developers solve problems and build better software through building real apps for real users, you will create paths to monetary value. And crucially, if you can attribute those paths to monetary value to something you did or made or said, you’ll be able to demonstrate quantitatively how DevRel is adding value to a business. However, attribution is company-specific: specific to how the company measures success, and specific to how the DevRel team at the company measures success. Attribution is also specific to the tools available to the team or company in being able to measure success. This post isn’t about measuring success, it’s about making an impact in a way only DevRel can do, and should be doing.

The approach to “doing DevRel” in this article works to create paths to business value; I know it does — it has worked for me and my excellent colleagues, past and present. And in 2025, I’ll be working on a framework with Sarah Guthals in which DevRel can define specific attributable paths to real quantitative business value.

Stay tuned.

I’m familiar with the Webmentions standard and how it can be used to facilitate cross-site conversations by showing data such as likes and comments/replies to links on the internet. I worked with Webmentions a few years ago to display Webmention data from other social media platforms on my site. However, it often felt like a lot of hoops to jump through, when you can just get some data from an API.

In this post, we’re going to use the Bluesky API to fetch a collection of avatars of users who have liked a Bluesky post that you have associated with a public blog post, so you can display something that looks like this on your website.

The workflow

Given this website is a static site built with Eleventy, it requires a few steps to associate a published blog post with a Bluesky post.

1. Publish a blog post, which triggers a static site build

2. Publish a Bluesky post which links to the published blog post

3. Associate the ID of the Bluesky post with that published blog post (in a CMS, for example)

4. Re-build the site

5. Profit

Technical choices

When building this component, I made some very deliberate technical choices based on the desired user-experience, and some important performance considerations.

I used client-side JavaScript

This website is a static site that uses client-side JavaScript sparingly. The JavaScript code for this functionality runs on my blog page templates conditionally if a blog post has a Bluesky Post ID associated with it.

Alternatives to this approach would be to (in my case) use an Edge Function to modify the static HTML response at request time, but in the past I have had performance issues with calling third-party APIs in this way, such as a slower Time to First Byte (TTFB) than desired. Read How I Fixed my Brutal TTFB for more context.

Additionally, this feature on my website is a progressive enhancement, and the function of the page is not dependent on showing Bluesky likes. Therefore, if calls to the Bluesky API fail on the client, it doesn’t matter, and we can clean up the DOM appropriately. If we were running this same code on a server, it could block the rendering of the page (without proper error handling, at least), and the post wouldn’t get read. Big shame.

With my site being a static site, technically I could fetch the Bluesky data at build time and render the data statically on each blog post. However, I wanted this feature to bring joy by being a near real-time interactive experience. And plus, it wouldn’t be ideal to re-build my website every minute or so, to keep the data in sync.

Optimising for performance

Given we are loading n third-party images (user avatars), the size of the images is important. Fortunately, the Bluesky API provides at least two image sizes for each user, and we want to use the smallest one.

Additionally, given we are loading n images and we don’t know how long they will take to load or how much of an effect they will have on the page layout, some considerations have been made to avoid Cumulative Layout Shift (CLS) as much as possible. These will be outlined alongside the code examples below.

Prerequisites to show Bluesky likes on your blog posts

1. A Bluesky account

2. A website

3. Some blog posts

4. A way to store a Bluesky post ID with your blog post data (e.g. if you write your blogs in markdown, store the post ID in your front matter; if you’re using a CMS, add a field to your blog post content model, etc)

The code

Let’s take a look at the HTML, CSS and JavaScript that makes the magic happen.

The HTML

The HTML is contained within a section element. This component contains:

• an h3 element, which will be populated with the total number of likes (your heading level element may vary),

• a link to the Bluesky post to encourage people to like it, and

• an empty ul element, ready to be filled with Bluesky avatars.

For the CSS classes I’m using BEM syntax, but you can use whatever CSS system you prefer. To target the DOM elements in JavaScript I’m using data-attributes prefixed with data-bsky; you can target DOM elements using CSS classes in JavaScript, but I prefer to use data-attributes to separate concerns. You could even use IDs on the elements and target those with JavaScript if you wish.

The bskyPostId associated with a blog post is added into a data-attribute on a meta tag next to this component. This is purely unique to my set-up, given that I’m building a static site, and need access to a build-time variable on the client-side in a separate JavaScript file. You may have access to your bskyPostId in your app state, for example, if you’re using a different framework. Edit as you see fit.

Copy

<meta data-bsky-post-id="${post.bskyPostId}" />

<section class="post__likes" data-bsky-container>
  <h3 class="post__likesTitle">
    🦋 <span data-bsky-likes-count></span> likes on Bluesky
  </h3>
  <a class="post__likesCta" href="https://bsky.app/profile/{handle}/post/${postId}" target="_blank">
	  Like this post on Bluesky to see your face on this page
  </a>
  <ul data-bsky-likes class="post__likesList"></ul>
</section>

The CSS

The CSS you see here has been slightly modified from my implementation to avoid you having to use my custom properties and personal spacing preferences. Please add what you need to make your implementation right for you.

I’d like to call out the magic number min-height: 400px on the parent container class, .post__likes; this is to maintain a fixed height of at least 400px for the element on page load, so that the avatars don't shift the page content around as they gradually load in (the container will expand vertically on mobile). This is to prevent a bad CLS score. In the JavaScript code below, you’ll notice that I’ve specified a limit on the number of avatars fetched, based on how many avatars will fit comfortably inside this fixed-height container.

Copy

.post__likes {
  /* to avoid CLS as much as possible! */
  min-height: 400px; 
  /* to prevent negative margin from allowing avatars to spill out of container */
  padding-right: 1rem;
}

.post__likesTitle {
  font-size: 2rem;
  color: #000;
}

.post__likesCta {
  color:  #000;
  font-size: 1.25rem;
  font-style: italic;
  display: block;
}

.post__likesList {
  list-style: none;
  padding: 0;
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
}

.post__like {
  width: 4rem;
  aspect-ratio: 1/1;
  margin-right: -1rem;
  border-radius: 100%;
  filter: drop-shadow(0px 0.125rem 0.125rem rgba(0, 0, 0, 0.25));
}

.post__like__avatar {
  border-radius: 100%;
}

.post__like--placeholder,
.post__like--howManyMore {
  width: 4rem;
  aspect-ratio: 1/1;
  display: flex;
  justify-content: center;
  align-items: center;
  font-size: 1rem;
  font-weight: bold;
  font-style: italic;
  background-color: #208bfe; /* Bluesky blue */
  color: #fff;
}

The JavaScript

Disclaimer: this code is provided in plain JavaScript; you may adapt this code to your own website framework should you wish, but the beauty of writing this in plain JavaScript is that you can use it on any front end as it is.

First, you’ll need to define a few variables. The LIMIT specifies the maximum number of avatars you want to display on your page depending on how you want to display them. My limit is set to 55 because that’s how many avatars fit nicely on four rows (with extra space to display how many more likes there are). The maximum number of avatars you can fetch with this API endpoint is 100.

The bskyPostId is grabbed from the meta tag as described in the HTML section above (you may need to do this differently depending on your framework and existing code).

In order to modify the DOM after fetching data, we need to access the container, likesContainer and likesCount elements using document.querySelector().

Replace the value of myDid with your own Bluesky DID. And everything else is good to go.

Copy

const LIMIT = 55;

const bskyPostId = document.querySelector("[data-bsky-post-id]").dataset.bskyPostId;

const container = document.querySelector("[data-bsky-container]");
const likesContainer = document.querySelector("[data-bsky-likes]");
const likesCount = document.querySelector("[data-bsky-likes-count]");

const myDid = "add_your_did";
const bskyAPI = "https://public.api.bsky.app/xrpc/";
const getLikesURL = `${bskyAPI}app.bsky.feed.getLikes?limit=${LIMIT}&uri=`;
const getPostURL = `${bskyAPI}app.bsky.feed.getPosts?uris=`;

Next, we’re going to define two functions that modify the DOM using the data from the Bluesky APIs.

The drawHowManyMore function only runs if there are more likes on the post than what has been fetched by the getLikes API. Again, I’m using BEM syntax for my CSS; if you’re using something different you will need to update which classes are added to the likesMore element.

The drawLikes function loops through the likes data from the getLikes API and creates an img element for each actor, adding a placeholder fallback if there is no avatar provided. Note that we replace avatar with avatar_thumbnail in the like.actor.avatar string. This is to display an image that is 128x128px, instead of the default 1000x1000px. Don’t forget the alt text attribute on the img element or the aria-label on the placeholder span element.

Copy

function drawHowManyMore(postLikesCount, likesActorLength) {
  if (postLikesCount > LIMIT) {
    const likesMore = document.createElement("li");
    likesMore.classList.add("post__like");
    likesMore.classList.add("post__like--howManyMore");
    likesMore.innerText = `+${postLikesCount - likesActorLength}`;
    likesContainer.appendChild(likesMore);
  }
}

function drawLikes(likesActors, postLikesCount) {
  for (const like of likesActors) {
    const likeEl = document.createElement("li");
    likeEl.classList.add("post__like");

    if (like.actor.avatar !== undefined) {
      likeEl.innerHTML = `
      <img class="post__like__avatar" 
        src="${like.actor.avatar.replace("avatar", "avatar_thumbnail")}" 
        alt="${like.actor.displayName}"
      />`;
    } else {
      likeEl.classList.add("post__like--placeholder");
      likeEl.innerHTML = `
        <span aria-label="${like.actor.displayName}">@</span>
      `;
    }
    likesContainer.appendChild(likeEl);
  }

  drawHowManyMore(postLikesCount, likesActors.length);
}

And here’s where we get the data from the Bluesky APIs, which is fetched from two API endpoints: app.bsky.feed.getPosts and app.bsky.feed.getLikes. After checking if a bskyPostId is available and not null, construct a postUri (at-uri) using the myDid and bskyPostId variables.

Next, fetch the bskyPost data to get the total number of likes on that post: postData.posts[0].likeCount. Then, fetch the bskyPostLikes data, which will return a likes array of user objects (or actors) that contain the avatar URLs we want to display.

If the bskyPostLikes response contains any likes, we update the likesCount text content in the HTML, and run the drawLikes function. If there are any errors in these API calls, we simply remove the whole container from the page. And that’s it!

Copy

if (bskyPostId !== "null") {
  const postUri = `at://${myDid}/app.bsky.feed.post/${bskyPostId}`;

  try {
    const bskyPost = await fetch(getPostURL + postUri);
    const bskyPostLikes = await fetch(getLikesURL + postUri);
    const postData = await bskyPost.json();
    const likesData = await bskyPostLikes.json();

    const totalLikesCount = postData.posts[0].likeCount;

    if (likesData.likes.length > 0) {
      likesCount.textContent = totalLikesCount;
      drawLikes(likesData.likes, totalLikesCount);
    }
  } catch (error) {
    container.remove();
  }
}

View the full JavaScript file on GitHub.

Some cool observations

1. It only takes a few seconds from a Bluesky user liking a post to their avatar showing up on a blog post.

2. The likes actors are sorted by timestamp-of-like-descending, so when someone likes your post on Bluesky, they appear at the top left of the avatar list. This, I hope, creates even more joy than intended (for left-to-right reading geographies, at least).

3. The Bluesky getPosts API updates quicker than the getLikes API. This means that on a page refresh, the likes number is generally up-to-date, and the avatars may take another second or two to appear on another refresh.

Share your results with me on Bluesky

I hope it goes without saying that I’d love to see your implementations and how you made this code work for your on your website. When you’re ready to post about it on Bluesky, tag the handle @whitep4nth3r.com in the replies, and I’ll like it to put my face on your blog post.

If you’re building server-rendered pages with Next.js or any React-based meta-framework, you know hydration errors suck and are usually difficult to debug. Hydration in React is the process that happens when a React application that was rendered as HTML on the server is made interactive in the browser. Hydration errors happen when the markup rendered by React on the client doesn’t match the initial server-rendered HTML, or when invalid HTML was sent by the server, and React couldn’t fix it. Sometimes this is unavoidable, for example, with dates and localization. You can suppress errors for these unavoidable differences in your React code, but most hydration errors would indicate that you’ve got some bugs in your app.

This article is not about how to fix hydration errors but how to debug them using Sentry. When hydration errors happen in development, your JavaScript framework of choice will usually show you a large error message with some details about the code that triggered the error. However, hydration errors aren’t usually visible or obvious in production, and your average real-world users probably won’t be able to provide useful screenshots with error reports (and probably won’t think to look in the browser console for errors). What’s more, the automatic error issue created by Sentry won’t be very useful, either.

But wait, Session Replay has a superpower

If you’re using Sentry’s Session Replay to get reproductions of user sessions when a user triggers a hydration error:

1. Sentry will automatically create a specific Hydration Error Issue for you (for free!),

2. group all the same errors together,

3. capture both the server-rendered and client-rendered markup that existed when the error happened,

4. and show you the diffs in both visual and raw HTML modes.

Just make sure you’re using Sentry’s JavaScript SDK, version 7.87.0 or above, and you’ve got Session Replay enabled to get the good stuff.

Here’s what a grouped Hydration Error looks like in Sentry:

• It is named “Hydration Error,” so you can find it easily in the issue list view.

• Choose which event to view (recommended, latest, oldest) and navigate between events to compare contextual information.

• View a sliding diff between the server and the client (open the diff viewer to also view a side by side visual diff and HTML diff).

• Click the “Resolving Hydration Errors” link to get more help on solving hydration errors.

Debugging hydration errors

Given that the standard hydration error message states that the server-rendered HTML did not match the client-rendered HTML, the diff viewer is really helpful in finding those differences. The “Before” view is the server-rendered version, and the “After” view is what React rendered on the client.

What you might notice in this example, however, is that the “Before” and “After” versions look the same visually. When inspecting the HTML diff, we see a blank page rendered on the server and HTML rendered on the client. This isn’t correct. HTML is definitely being rendered on the server; I checked in my browser’s network tab.

The real issue in the code causing the hydration error is not that the server-rendered and client-rendered HTML don’t match, it’s that my HTML is invalid (a <p> is contained within a <p>) and React threw an error. This is why hydration errors suck: they don’t always make sense.

So why does there appear to be no HTML rendered on the server according to the diff? Given that React threw a nonsensical hydration error for invalid HTML, Sentry can only make a best-effort guess as to what the problem is. Usually, if one event has a diff that doesn’t make sense, another event may be more helpful. The bottom line is that when React throws a hydration error, there’s a problem that needs fixing. And because React doesn’t tell us the details needed to fix the problem in production, Sentry fills in the blanks on the hydration error diff tools as much as possible so you can better debug the problem.

Does creating hydration error issues and diffs increase my Sentry bill?

No. If you’re already using Session Replay, you get automatic grouped hydration error issues for free. Hydration error issues in Sentry are generated from Replays and their associated data, so have no impact on your error quota, either. Additionally, you’ll also get alerted on hydration errors by default.

Bonus tip: level-up your debugging by unmasking non-sensitive data in replays

If you’re using Session Replay, you might have noticed that it masks all text content with * and blocks all media elements on the client by default, before it is sent to Sentry. In this article, the examples shown in the hydration errors images show text rather than asterisks, due to how the Session Replay SDK was configured.

If you’re working on a content-based website that’s free of personally identifiable information (PII), you can disable the default text masking and image blocking by configuring the maskAllText and blockAllMedia configuration options in the Session Replay initialization.

Copy

Sentry.replayIntegration({
  maskAllText: false,
  blockAllMedia: false,
});

This can be really helpful in debugging fake hydration errors (that are actually invalid HTML errors) like the one demonstrated in this article. Note: Only use this if your site has no sensitive data or if you’ve already set up other options for masking or blocking actual sensitive data. Read more about Session Replay privacy configuration on the Sentry docs.

Debuggability is key

Hydration errors in production have always been a bit of a mystery, without any practical way to deal with and debug them. With the Sentry Replay SDK, you now get the HTML diffs and as much context as possible with each hydration error, helping you to debug and fix things faster. And whilst this ultimately helps you as a developer, it benefits everyone else as well: stakeholders, clients, and most importantly — your users. Now, go fix those bugs.

20th August 2024

On 20th August 2024, I found Richard asleep in front of his work laptop on the sofa at 4:30pm. It was slightly concerning, but I knew he’d been working a lot lately. He was just tired. That evening, we went out for pizza with some friends. I noticed something “off” about Richard. The walk home felt like talking with a stranger after a mediocre date. That week, he started to fall asleep more and more often: at his desk, whilst dinner was cooking, or whilst playing video games.

24th August 2024

The following weekend, Richard had developed a “bit of a cold”. But it felt like more than a cold. He was slurring his speech; he was moving slower. I noticed it was becoming more difficult for him to play with our six year old son. The things he was trying to do and say didn’t make sense. Normal conversation would be interspersed with moments of strange nonsense. It got worse in the evenings when he was more tired. His movements became slower and weirder. At times he would fall asleep mid-sentence.

“There’s a problem with your brain,” I said. “You should go to the doctor.” I cancelled a speaking gig in Denmark to look after him and our son, who was still enjoying the summer holidays. Time is a blur at this point. Richard blamed all of the above on his “cold” and shrugged it off. He didn't contact the doctor.

27th August 2024

On Tuesday 27th August, Richard was in a state of near-constant delirium. I called the NHS non-emergency service, 111, and explained his symptoms. They sent an ambulance straight away, and he was taken to hospital. I spent the evening with my son, we had Japanese take out and watched a film. I felt much less anxious knowing Richard was in the hospital and could get the treatment he needed. I went to bed.

At around 11pm that night, Richard returned home. He told me that everything was fine, and that he just had some sort of virus that would clear up on its own. After being admitted to hospital twice in the last year for having seizures as a result of iron deficiency anaemia (even after numerous tests throughout the year, they still hadn’t found the cause), he vowed he would never go back again.

Given that he turns 40 this year, Richard decided it was time for a lifestyle change. It was time for him to start exercising regularly, eating better, and taking care of his health. He started wearing his Apple Watch again. That week he purchased new running shoes, and whilst he was still showing symptoms of this “weird virus”, he went out for several runs in the local park. His watch reported an average walking heart rate of over 140bpm; jogging was close to 180bpm. Richard is a 39 year old male. Those numbers weren’t good. I asked him once again to go to the doctor; he wouldn’t.

3rd September 2024

On September 3rd, our son returned to school, and Richard and I spent the day together. We went for a walk, we ate home made soup for lunch, but Richard was struggling to do some basic tasks. That night, he coughed up blood in his sleep. He didn’t wake up when it happened.

4th September 2024

That morning, I found Richard at 4am and cleaned him up. I decided it was time to force him to see a doctor. I asked him to make an appointment via the online GP service whilst I was getting ready to leave for the school run. By this point, Richard couldn’t use his phone. He couldn’t type on a keyboard. Every time he tried to do it, he typed random strings of nonsense. I typed out a detailed message for him myself, submitted the form, and left to take our son to school.

When I returned home, Richard told me that he got a call from the doctor to arrange an appointment, and he had no idea why. He was so confused as to why the doctor was ringing him, that he became convinced it was our son that was unwell, and made an appointment under his name instead. An hour later, I took Richard to the GP surgery.

After a short assessment and a telephone call to the hospital, the GP informed us that during his hospital admission the week prior, it was discovered that Richard was critically anaemic again (as in, he will die pretty soon without new red blood cells and iron). But Richard had returned home that night and told me he was fine.

It became clear that Richard had discharged himself from the hospital that night whilst waiting for his blood test results. I blamed myself for this for a short while; I should have gone with him to the hospital. But I know it’s not my fault. Richard didn’t think anything was wrong with him. He didn’t want to believe anything was wrong with him. He wanted to get back to work. Employee of the Year 2023 didn’t want to let anyone down.

I took Richard to A&E (the ER) that day, with an urgent letter from the GP. I organised my mother in law to help with childcare so I could stay with him for as long as possible so he wouldn’t escape again. At the hospital, they took him into triage straight away, admitted him, and hooked him up to all the machines.

I thought I was watching my husband die.

14 days

Richard was in the hospital for 14 days. He was treated for a very bad chest infection, anaemia, and encephalitis: an uncommon but serious condition in which the brain becomes inflamed. According to the NHS article on encephalitis, “Some people eventually make a full recovery from encephalitis, although this can be a long and frustrating process. Many people never make a full recovery and are left with long-term problems caused by damage to their brain.”

Whilst being treated for the anaemia and chest infection, Richard was subject to a lot of tests on his brain. All of the easily discoverable bad things were ruled out; he hadn’t had a stroke, there was no bleeding, there was no sign of cancer: his brain was physically normal. Yet my Richard still wasn’t “normal”.

I visited Richard for eight hours every day. I took him his favourite foods, clean clothes, helped him shower, and listened to him talk a lot of nonsense. Throughout all this, I fully prepared myself to be his full-time carer and a single parent when he was “well enough” to return home. He started to experience a complete and utter devastating depression. He felt like he’d let everyone down. I stayed with him, reassured him, and promised to love him, no matter what happened.

13th September 2024

On Richard’s 10th day in hospital, it was my 39th birthday. I prepared myself to be in a similar situation on my 40th birthday.

16th September 2024

On day 13, I went to visit Richard at 11am as usual. I said hello, asked how he was feeling, and placed a bag of clean clothes on the floor. And when he spoke to me, his voice was his own. His words were no longer slurred, his movements were his own: sharper and more refined. He was my Richard. He was back. His brain was better.

We’re still waiting for the results of some tests; but the doctors still don’t know what happened to Richard’s brain, or why he made such a sudden overnight recovery. We don’t know if the anaemia and brain swelling are linked, or whether it was just a huge coincidence. We’re not entirely sure whether the antibiotics used to treat the chest infection helped treat whatever was happening in his brain. We still don’t know the cause of the anaemia but I’m sure in time we will — and he is undergoing more tests.

Our jobs are meaningless

We may not know the cause of Richard’s anaemia, or what happened with his brain, but what we do know after all of this, is that our jobs in tech are largely meaningless, and they’re definitely not worth almost dying for.

You see, it’s not the work itself that put Richard in hospital, it’s that he dedicated so much of his waking time and brain space toward work that he neglected to consider his own declining health. He knew he was feeling more tired than usual, but he pushed through. He knew he found it difficult to climb stairs, but he thought he was just getting old. He knew his heart rate was too high, but he shrugged it off as high metabolism (it’s actually a symptom of anaemia). He was extremely pale. But that’s how he always looked, right? He knew his voice and his behaviour and his coordination had changed, but he ignored it and hoped it would get better on its own.

Richard didn’t want to be off work sick. He didn’t want to “let anyone down”. He wanted to be Employee of the Year and better.

Over the past couple of years, Richard has worked too much. He stayed up all night on numerous occasions to make non-emergency internal infrastructure changes on flaky legacy systems. No users would notice the changes, but it earned him employee points. He would agree to outlandish time-intensive requests from senior members of the business that had nothing to do with his scope of work. He would check for Teams messages at the dinner table in case something broken needed fixing out of hours. He decided to take on double the work rather than scale back operations when his team of three was a team of two for a few months. He missed school events for arbitrary useless meetings.

Richard’s self-imposed approach to work — trying to be “as good as possible at all costs” — isolated him from his family and his own sense of self, and it took him almost dying in front of me in A&E to realise that none of this is worth dying for, actually. And plus, “as good as possible” does not actually mean “do as much as you actually possibly can and maybe, like, four times more, despite not getting the support you need from your employer and never sleeping properly for weeks at a time because you take on random non-essential assignments and eventually accidentally distance yourself from your family because you are only a single human being and there are only so many hours in the day and oh wait I completely forgot to check on this life-threatening mineral deficiency that might kill me because I didn’t want to let anyone down”. I could go on.

He still needs a lot of rest. And I'm making sure he's getting it.

Work is an exchange of time for money

I won’t speak any more for Richard, but I will offer you my thoughts on this.

Work is an exchange of time for money. Most work is meaningless, and is centred on finding solutions to manufactured problems that exist only in capitalism. And whilst that sounds extremely depressing, the upside is that it leaves you free to find your own meaning in life.

And I do hope you will find meaning — and much love — in those humans who you choose to call your family. And most importantly, please look after your own health.

No work is worth dying for.

• First Contentful Paint (FCP), which measures the time from when the user first navigated to the page to when any part of the page’s content is rendered,

• Largest Contentful Paint (LCP), which is the point in in the page load timeline when the main content of the page has likely loaded, and

• Interaction to Next Paint (INP), which measures how quickly a web page responds to user input.

This makes sense given that without anything to consume and/or interact with we don’t really have an experience to measure at all, but what about the events that happen before the first byte of a web page is received by the browser? Can we measure those events, and subsequently optimize them to make our web pages and applications load even faster?

How pre-TTFB events are visualized in the Sentry Trace View

The above questions came to mind when looking at the Trace View in Sentry, where the events that happen before anything is rendered in a browser window are captured and labeled as browser spans. Six spans are registered in chronological order: cache, DNS, connect, TLS/SSL, request, and response. All events before response precede the Time to First Byte (TTFB), which measures the time between the request for a web page/resource and when the first byte of a response begins to arrive.

You may be wondering how these events are captured by Sentry, given Sentry won’t have been initialized in the browser at this point in the page load timeline; and I wondered the same thing! The answer lies in the Performance API — a group of web standards used to measure the performance of web applications — and more specifically the Navigation Timing API, which provides some very useful metrics including high-precision timestamps to the browser each time an event (known as a PerformanceEntry) happens.

The really cool thing is that you also have direct access to the Performance API in the browser: most of the performance entries are recorded for any web page without any setup or extra code needed to retrieve them. Try it out now by opening up the dev tools console and typing window.performance. You’ll see something like this (I’ve manually grouped related timestamps and ordered them for easier parsing):

Copy

// captured from https://whitep4nth3r.com on Tues 30 July @ 13.42
{
  "timing": {
    "navigationStart": 1722343304923,

    "redirectStart": 0,
    "redirectEnd": 0,

    "fetchStart": 1722343304928,

    "domainLookupStart": 1722343304928,
    "domainLookupEnd": 1722343304928,

    "connectStart": 1722343304928,
    "secureConnectionStart": 0,
    "connectEnd": 1722343304928

    "requestStart": 1722343304988,
    "responseStart": 1722343304989,

    "unloadEventStart": 0,
    "unloadEventEnd": 0,

    "responseEnd": 1722343304998,

    "domInteractive": 1722343305161,
    "domContentLoadedEventStart": 1722343305161,
    "domContentLoadedEventEnd": 1722343305161,
    "domLoading": 1722343304996,
    "domComplete": 1722343305381,

    "loadEventStart": 1722343305381,
    "loadEventEnd": 1722343305381,  
  },
}

So how does Sentry populate a trace with those browser spans? As a result of the Performance API recording these metrics with timestamps from the moment a URL is requested in the browser, the Sentry JavaScript SDK is able to access these after initializing, backfill the full list of events that happened chronologically before the web page loaded, and send them as spans to the relevant full trace so they can be visualized in the Trace View.

What happens before a web page loads?

The window.performance provides a window (pun definitely intended) into the many different events that happen before we see any web page content appear in a browser. It returns a Performance object, which contains a timing property, shown in the above code example. While this is a quick way for us to inspect the events recorded by the browser on page load without writing any code, the Performance.timing property is now deprecated and has been superseded by the PerformanceNavigationTiming API (with only some minor changes so far).

This diagram from the Navigation Timing Level 2 specification shows the order in which PerformanceNavigationTiming events are recorded from the moment a navigation request is made in the browser, to when the load event of the current document is completed. Not all events will be available for each page load, but the order matches what we observed using window.performance above.

Let’s explore each relevant event metric to see what’s happening under the hood, and how it gets calculated by Sentry from particular timestamps to populate the browser spans in the Trace View. And hopefully, with this new knowledge, we’ll begin to understand how we might be able to optimize for web performance before the TTFB.

browser cache

If the resource is being fetched using HTTP GET (e.g. a standard request for a web page), the browser will check the HTTP cache first. fetchStart returns the time immediately before the browser starts checking the cache. The cache span in the Sentry Trace View is calculated as the time between the fetchStart timestamp and the domainLookupStart timestamp.

A non-zero value for a cache span in the Trace View represents the time taken for a browser to retrieve the resource from the browser cache. Longer cache spans could point to the use of slower or older browsers, or users who don’t clear their browser caches very often, if at all.

browser DNS

The next span reports the DNS (Domain Name System) lookup time. When a user requests a URL, the DNS is queried to “lookup” the domain in a database and translate it to an IP address. The total time taken to complete this is calculated by subtracting the domainLookupStart timestamp value from the domainLookupEnd timestamp value.

browser connect

Next, it’s time to measure the time it takes for the browser to connect to a web server. This is known as “connection negotiation”, and is measured as the time between two events: connectStart (when the browser starts to open a connection to the web server) and connectEnd (when the connection to the web server has been established).

browser TLS/SSL

If the web server the browser is connecting to is using HTTPS, a secureConnectionStart event will happen in between connectStart and connectEnd. secureConnectionStart marks when the browser and web server exchange messages to acknowledge and verify a secure encrypted connection, known as TLS (Transport Layer Security) negotiation. The value of secureConnectionStart may be 0 if HTTPS isn’t used or if the connection is persistent.

In Sentry, the connect and TLS events are reported as separate spans. In this image of the Trace View, you’ll notice that the connect event begins, the TLS event begins shortly after, and the connect end event ends as soon as TLS negotiation has finished. This representation of events is useful in being able to identify whether there are any bottlenecks in either the web server connection or the TLS negotiation independently.

browser request

After the (secure) connection with the web server has been established, the browser will officially make the request for a resource, marked by the requestStart event.

browser response

Finally, the browser will receive the first byte of content. In the Sentry Trace View, here’s where the TTFB (Time to First Byte) vertical line is marked.

Can we make PerformanceNavigationTiming events faster?

Now we understand what happens before the first byte of a web page is delivered to a browser, let’s go a little deeper to understand if we might be able to speed up the events that happen in the navigation timeline.

Can you speed up the browser cache retrieval event?

As a developer who wants to improve the performance of their own applications, I’m not sure you can speed up this event for your user-base. However, you probably could speed up this event for yourself by being diligent with your own personal browser caches. Clear your browser caches like you commit changes to a git repository: little and often.

Can you speed up a DNS lookup?

The speed of a DNS lookup can be affected by a number of things, including (but not limited to):

• The size of the DNS provider’s infrastructure: fewer “Points of Presence” (POP) around the globe will mean longer latency and slower lookups,

• The location of the POPs: if your website visitors are far away from a DNS server, DNS lookup will take longer,

• The DNS cache time: DNS is served from a cache until it expires. The length of the DNS cache time is determined by the Time to Live (TTL) value specified on the DNS record (which points a URL to an IP address). The higher the TTL, the less likely the browser will need to perform another DNS lookup on each subsequent request.

Ultimately, speeding up DNS lookups involves investing in a DNS provider that has a large and globally distributed network of POPs. If you’re a developer at a scaled-up enterprise business, this is probably taken care of for you. Additionally, setting the TTL value as high as possible for DNS records that don’t change often is probably a good tactic.

At the time of writing, I checked my personal website DNS records out of curiosity, and I had the TTL set to 5 minutes. This meant that the DNS cache expired every five minutes, causing browsers to do a fresh DNS lookup much more often than needed. Given that I’m not pointing my website URL to a new server, like, ever, I decided to change the TTL to 60 minutes.

In this very limited 5-day experiment on my personal website, I saw fewer non-zero times for the browser DNS lookup spans in Sentry since switching the TTL. If your website is not mission-critical and not money-making, this could be a good solution to help speed up DNS lookup. Bear in mind, though, that if your main servers go down and you want to point your URL to backup servers, it will take up to 60 minutes for all users around the world to see the DNS changes.

That being said, according to Sematext, “The average DNS lookup time is between 20 and 120 milliseconds. Anything between that and under is generally considered very good.” So perhaps this type of micro-optimisation might not be worth needing to remember that your TTL is set to 60 minutes when you need to change to a backup server during a primary server outage.

Improving DNS lookup for third-party resources with rel=”dns-prefetch”

Most front-end websites and apps are probably loading at least one or more resources from third-parties, i.e. resources/images/files/scripts from different domains. Each request to a different domain will also involve a DNS lookup event. Whilst it’s worth noting that third-party resources will be requested after the TTFB and so after the PerformanceNavigationTimeline events we are concerned with in this post, you can attempt to speed up the DNS lookup of these third-party resources by using the attribute rel="dns-prefetch” and associated href value on the <link> tag that requests the resource. This provides a hint to browsers that the user is likely to need to fetch things from the resource’s origin, at which point the browser can try to improve the user experience by preemptively performing DNS resolution for that origin before the resource is officially requested. This is useful when pulling in third-party fonts from Google, for example:

Copy

<link rel="dns-prefetch" href="https://fonts.googleapis.com/" />

Depending on how many third party resources are requested on page-load in parallel, this could help to speed up the in-browser events that happen after the responseEnd event, i.e. when the browser begins to parse the HTML and request all third-party resources (especially if they are render-blocking resources).

Note: don’t use dns-prefetch on resources fetched from the top-level domain of a website (i.e. resources you host with your website). Read more about using dns-prefetch on MDN.

Can you speed up the connect and TLS negotiation events?

Don’t use HTTPS? I joke. The bottom line regarding TLS negotiation time is that even back in 2010, after Google switched Gmail to use HTTPS for everything, TLS was declared “not computationally expensive anymore”. In the 2013 publication, High Performance Browser Networking, Ilya Grigorik states that “…the early days of the Web often required additional hardware to perform ‘SSL offloading.’ The good news is, this is no longer necessary and what once required dedicated hardware can now be done directly on the CPU.”

The one piece of advice Ilya gave in 2013 is to make full use of TLS Session Resumption, which is a mechanism used to “resume or share the same negotiated secret key data between multiple connections.” In short, it’s a way for your computer and a website to remember each other, so they don’t have to go through the long process of checking the encryption keys (secret password) every time you reconnect. This makes browsing faster and uses less computational power.

Unless you are directly responsible for implementing TLS on a server, making TLS negotiation as fast as possible is probably 99.999% taken care of for you. However, in the same way you can hint to a browser about resources you may need with rel="dns-prefetch", you can go one step further and use rel="preconnect" on links to external resources, which also preemptively performs part or all of the TLS negotiation. Again, this will happen after the PerformanceNavigationTiming events, but it’s good intel, nonetheless.

Can you speed up the browser request and response events (TTFB)?

As a developer, the Time to First Byte (responseStart) is ultimately what you have the most control over in the page navigation timeline. Being mindful of everything that happens between the requestStart and responseStart events, and being ruthlessly efficient in optimizing these events can have a huge impact on your page speed and resulting user experience.

Here are three things to investigate in your websites and apps:

Reduce or eliminate request waterfalls

A “request waterfall” is what happens when a request for a resource (code, data, image, CSS, etc.) does not start until after another request for a resource has finished. In terms of the PerformanceNavigationTimeline, the requestStart event may delay the responseStart event depending on the architecture of your web page or application, and how many synchronous events happen before the browser receives that first byte of data. I experienced this first-hand with my personal website; after I’d noticed that page loads had become excruciatingly slow, I investigated the situation (using Sentry) to find that each page load was making many round trips to an edge server. Choosing to remove those just-in-time requests altogether and include the required data in a static page build meant I radically reduced the TTFB by ~80%.

Perhaps your application makes a series of database calls at the time of the requestStart event. Do these queries need to happen in series, or can they happen in parallel? Even better, can you grab all the data you need from the database in a single query? If React is your thing, check out this post from Lazar on how to identify fetch waterfalls in React.

Better yet: do you need to make any just-in-time calls to the database at all? Or can you follow my lead and build your web pages statically, so all that needs to happen after requestStart is the swift delivery of a static page of HTML from a CDN (Content Delivery Network)? Note: this does not mean you can’t enhance your web page’s interactivity and fetch new data with client-side JavaScript after the page has loaded.

Cache, cache, cache

Speaking of CDNs, which enable content to be cached at edge servers around the world which are located physically closer to visitors, if your website (or a subset of its pages) are not serving personalized and/or dynamic content, you should take advantage of caching: where full HTML responses are stored and delivered on-demand rather than needing to be re-generated at request-time. As a front-end developer who uses modern hosting solutions to deliver my websites where I don’t even need to think about this level of configuration, I’m not going to pretend to be an expert on caching. But I will share this nugget of information from Google’s article, Optimize Time to First Byte:

For sites that frequently update their content, even a short caching time can result in noticeable performance gains for busy sites, since only the first visitor during that time experiences the full latency back to the origin server, while all other visitors can reuse the cached resource from the edge server.

Similarly to TLS negotiation, as a front end developer in 2024, this is something we don’t often have to worry about; it’s taken care of for us thanks to the tools at our disposal. And speaking of modern tools, many front end frameworks and libraries are now bringing HTML streaming to the masses.

Harness the power of HTML streaming

HTML streaming is where, instead of serving the entire HTML document at once, servers send pieces of it over time. The browser receives these pieces of HTML and can start parsing them, and even rendering them, so the web page can appear to load more quickly. Instead of waiting to receive an entire HTML document in between the requestStart and responseStart events, which may also involve database calls and other logic processing, HTML streaming allows for the responseStart event to happen earlier, thus reducing the TTFB.

If you’re working in the React ecosystem and want to know more, Lazar goes in-depth on HTML streaming in The Forensics of React Server Components.

Knowledge is power

All of this data about what happens before a web browser receives the first byte of data of a web page is pretty empowering. But the real power lies in putting that data in context in the Sentry Trace View. In being able to visualize and trace PerformanceNavigationTiming events and issues, we open up the door to being able to effectively debug slow parts of that timeline at a granular level, and make those all-important micro-optimizations where possible.

If your web pages and applications are as fast as they can be, however, hopefully this article has given you some useful information. Perhaps you could use your new-found knowledge on DNS to wow people at all the cool parties you probably attend.

I shared this survey on LinkedIn, Twitter, Twitch and The Claw Discord. I’m not sure how many people saw the link to the survey, but I received 138 responses. I think that’s a great turnout! (Note to self: next time ask people where they found the link to the survey in the actual survey.)

Let's take a look at the findings.

There are a lot of senior technologists out there

… but the internet is saturated with content for beginners.

• How to get started with [LIBRARY/FRAMEWORK/INTEGRATION]

• How to build your first [INSERT_THING_HERE]

• How to get your [FIRST/NEXT] job in tech

• A day in the life of a software engineer (OMG SO GLAMOROUS, MUCH TECH)

• What is [WEB_FUNDAMENTAL_HERE]?

Why is there so much of this stuff? Because content for beginners gets views; everyone can be a beginner in tech and and a result, this type of content can appeal to and be accessible to anyone. If you’re a company, “getting started” content gets people using your product quickly. And it’s a great gig for creators if you’re on a video-centric platform. Get the views, grow the channel, get paid. Beginner content is also theoretically quicker to create (but disclaimer: not necessarily easier to create well). Spin up a framework boilerplate project and talk through the moving parts; job done. Build a quick chatbot app that won’t scale in production; no problem. Explain a mind-blowing concept in under 60 seconds; people will bookmark and share that.

There’s definitely a place for this type of content. It won’t provide any solutions to that obscure problem you’ve been Googling for two weeks, but it will get people interested in technology and the possibilities it unfolds. And I’m sure there are many developers who have been inspired by this type of content to get into tech and make a great career for themselves. But what about when you’ve got a steady job in tech — what do you consume on the internet to help you level up, make you think, or be entertained by?

91% of my audience are not beginners

96% of people who took part in my survey work in tech (not just limited to software engineers). And 91% of those participants have 3+ years experience in tech. That’s 91% of my audience who are not beginners. I acknowledge that there is some bias in this survey in that I surveyed my audience, people who already know me. In the past I hypothesised in many conversations with my peers that most of my audience are pretty senior in terms of technical experience given the types of discussions we often have in the Discord or live on stream. And now I have the data that proves it.

In the crisis of confidence referenced at the top of this post, I started to doubt my place on the internet. Fewer people than I’d like engage with the things I create for work, which is understandable given it is aimed at mid-senior level developers. And my approach to streaming and building my non-work weird projects on stream maybe doesn’t appeal to a very wide audience. In light of this I wondered, do I need to experiment with different types of content? Take a different approach, perhaps? Do I finally need to create that course for beginners I’ve been thinking about for all those years? Do I need to stop building stupid (albeit fun) projects and create things that people can take more seriously so that they can take me more seriously? For now I think the answer to all these questions is “no”.

Honestly, I have no idea what “good” really looks like in terms of numbers; and I’m usually the first person to say numbers don’t matter. What matters is the value you can offer to individuals. Something that I hope I’ll be cited for when I am one day completely irrelevant is, “If anything I do, say or create helps at least one person, then I have succeeded.”

People enjoy consuming technical content on the internet outside of work hours

90% of survey respondents said they enjoyed consuming technical content outside of work hours. This number surprised me given the survey was completed by mainly mid-senior level people. As a rather senior technologist, I prefer to stay away from the internet entirely after work hours — but this could be due to my home/family situation and the different types of offline hobbies I have, so I think there’s a lot of nuance to this that probably can’t be captured in a question with a binary answer.

Most likely, people with jobs in tech don’t have the time during work hours to consume content online, and so they save it up for later to watch/read/listen at their own leisure. It could simply be that people enjoy listening to tech podcasts on their daily commute (which is technically outside of work hours).

What very senior technologists want to consume

The survey included a free text field to answer the question “What are you looking for in online tech content?” Here's a summary of the answers for survey respondents who had 10+ years of experience. Senior technologists want to consume content that is:

1. Educational and practical: Developers want comprehensive, in-depth tutorials and guides based on real-world applications and practical examples. Two particular requests stand out: “Advanced shit,” and “Breakdowns and deep subjects. Surface level stuff is kinda saturated.”

2. Entertaining and fun: Developers value content that is not only educational but also engaging and entertaining. (Again, this probably highlights the survey bias here, as you probably know by now I claim to write code for your entertainment.)

3. Relevant and timely: Developers want up-to-date information on industry trends and recent advancements to help keep their skills fresh at work.

4. Unique and creative: Developers also value unique, creative, and unconventional content, including quirky projects and surprising ideas. (Maybe I’m onto something with my stupid projects, after all.)

5. Concise and clear: Developers prefer straightforward, concise content without unnecessary waffle or theatrics, focusing on clear instructions and explanations. Some respondents specifically asked for “No drama!”

All of the above doesn’t really tell me anything new, because all of the above is what I want, and I have always strived to create what I want to consume. That being said, it’s delightful to gather data that confirms my hypotheses, and it gives me comfort that by continuing to do what I’ve been doing, I will be satisfying at least one person somewhere, somehow.

How senior technologists like to learn

The final survey question asked participants how they like to learn. Surprisingly, written content came out on top, followed by video content, courses, live content, podcasts and then “other”. It was encouraging to see written content at the top of the list, given that’s the type of content I feel like I’m best at creating to help people learn.

Conclusions

There’s a market out there for any type of technical content that people will choose to consume. We’re in some weird kind of Attention Economy, and I’d like to think that in this economy, particularly internet-savvy connoisseurs (usually senior technologists) will be very intentional about what they consume. And if they choose to consume what I create, whether that’s through reading my latest blog post, catching the odd live stream, or bookmarking something I post on the socials, then I’ve achieved something worthy of celebrating.

Now if only there was something to prevent me having such regular crises of confidence. Maybe I'll consume some content on that.

How to check an LCP score

You can conduct a one-off page speed audit to check an LCP score using tools like Page Speed Insights from Google, or Lighthouse in any Chromium browser dev tools, which will produce a report that looks something like this:

The overall performance score of 59 has been calculated from a weighted combination of five different metrics, shown in the metrics grid. If you’d like a more in-depth read about this score calculation, check out How To Hack Your Google Lighthouse Scores In 2024.

Metric scores are graded as “poor,” “needs improvement,” or “good,” and are identified by a color and shape key. The LCP score for this page on this test is 4.4 seconds, which is poor. Additionally, notice at the bottom of the image the frames that were captured during the page load timeline, which shows what a user would experience as the main content loads. We know this is bad, but how do we debug the root cause?

What causes a bad LCP score?

To begin to debug why an LCP score is slow, you can select to show audits relevant to LCP under the visual page load timeline.

Page Speed Insights is advising that our slow LCP could be improved if we:

• Reduce unused JavaScript

• Serve images in next-gen formats (such as webp and avif formats)

• Properly size images

• Eliminate render-blocking resources

• Efficiently encode images (reduce file size without compromising quality)

Expanding the item provides more information for each recommendation. Let’s expand the top item — The Largest Contentful Paint element — to see what insights we can gain.

Unfortunately, this panel isn’t telling us anything we didn’t already know. The table shows, we can see that the “Load Delay” phase accounts for 81% of the LCP, which we observed in the visual page load timeline above. But this report can’t tell us why there’s a load delay — and this is what we need to debug!

Tools like Page Speed Insights and Google Lighthouse are great for diagnosing issues and providing actionable advice for front-end performance based on data from a single isolated lab test. What these tools can’t do, however, is evaluate performance across your entire stack of distributed services and applications for a sample of your real users. How do you investigate if the poor LCP score is actually due to an issue in the backend?

Here’s where you need tracing.

How to use tracing to debug a bad LCP score

By tracking the complete end-to-end user journey from the moment a page request is made in a browser across all downstream systems and services to the database and back, tracing helps you identify specific operations causing any performance issues in your full application stack. Each trace comprises a collection of spans. A span is an atomic event full of metadata and contextual information, which helps you further understand the interconnected parts of your distributed systems. Spans are connected and associated with a trace as a result of a unique identifier sent via an HTTP header across those systems. Tracing is also useful in standalone applications that have both a server-side and client-side runtime, such as modern JavaScript meta-frameworks.

We can use tracing to find the root cause of a poor LCP score by tracing the waterfall of events from the moment a user lands on the products page to when the main content finally loads. Let’s go through it step by step.

Or you could skip all of this and scroll right down to this part and just use the Trace Explorer if you’re already using Sentry.

Step 0: Suspect you have a real LCP problem

Most of us can probably tell when a page is slow to load so you might end up skipping this step. That being said, if you did a CWV test using your high-spec dev machine using high-speed internet and the scores were bad, then you know you have a real problem to solve.

Step 1: Install an Application Performance Monitoring tool SDK (like Sentry) across your entire suite of apps and services

Sentry provides an abundance of SDKs for a variety of programming languages and frameworks. First, sign up to Sentry and create a new project for each of your applications. Each project will have a unique DSN (Data Source Name), which is what you’ll use to point your app to your Sentry project in your code.

Let’s say you’re using React for your front end. Install the Sentry React SDK via your package manager of choice.

Copy

npm install @sentry/react

Initialize Sentry in just a few lines of code and configure the browser tracing integration.

Copy

import React from "react";
import ReactDOM from "react-dom";
import * as Sentry from "@sentry/react";
import App from "./App";

Sentry.init({
  dsn: "YOUR_PROJECT_DSN",
   integrations: [
    // Enable tracing
    Sentry.browserTracingIntegration(),
  ],
  // Configure tracing
  tracesSampleRate: 1.0, //  Capture 100% of the transactions
});

ReactDOM.render(<App />, document.getElementById("root"));

For your backend, let’s say you’re running a Ruby on Rails app. Add sentry-ruby and sentry-rails to your Gemfile:

Copy

gem "sentry-ruby"
gem "sentry-rails"

And initialize the SDK within your config/initializers/sentry.rb:

Copy

Sentry.init do |config|
  config.dsn = 'YOUR_PROJECT_DSN'
  config.breadcrumbs_logger = [:active_support_logger]

  # To activate Tracing, set one of these options.
  # We recommend adjusting the value in production:
  config.traces_sample_rate = 0.5
  # or
  config.traces_sampler = lambda do |context|
    true
  end
end

Check out the Sentry docs for your preferred SDK, or create a new project in Sentry where you’ll be guided through the setup process.

Step 2: Sit back and relax whilst your APM tool (Sentry) collects data from real users

Well, you probably won’t be able to relax entirely. Your app is crap and slow to load. Instead, use this time to read angry User Feedback requests about how much of a terrible developer you are. Don’t worry; it’ll all be worth it when you finally find the real source of the LCP performance bottleneck.

Depending on how much traffic your website gets, you might need to wait a few days to get enough data.

Step 3: Explore your Core Web Vitals scores to find aggregated field data that supports your lab data

In Sentry, navigate to Insights > Web Vitals for a quick overview of your project’s overall performance score and CWV. Click the table column headings to sort the data by “LCP” descending to confirm the field data lines up with your lab data. It does? Great.

Step 4: Find sampled page load events with a poor LCP score

On the Web Vitals insights page, we’re going to click into the page route with the worst performance to view sampled data for that page route only. In our case, it’s the “/products” page. The Core Web Vitals will look different here (i.e. worse), as they’re calculated using data from just the products page rather than the full application.

The next step is to explore the full trace of events. There are many ways into the trace view in Sentry, but from this CWV summary, you can click into the LCP score block (which in this case is 6.55s) to view a set of sampled data with a variety of scores across the spectrum.

Click on the transaction at the top of the table with the worst LCP score to view the trace. Here’s where all of your debugging dreams will come true.

Step 5: Explore the full trace of those page load events to discover where the performance bottlenecks are happening

The trace view shows when the LCP happened in the timeline. Every span that was sent to Sentry before the LCP happened is now guilty until proven innocent. Thankfully, we don’t need to interrogate every single span given Sentry has already highlighted the likely causes of any slowdowns with a warning symbol. Expand the spans to investigate deeper until you find the root cause of any bottlenecks. In the case of this application, two slow database queries that happen when a request is made to the products page on the front end are causing the poor LCP score.

We successfully found the root cause of a front end performance issue that didn’t have an obvious fix. We identified the slowdown happened as a result of two specific database queries. It was almost too easy! Now, it’s time to optimize those database queries, which might not be as easy.

But wait, there’s more!

You can skip steps 3-5 and go directly to the Trace Explorer (currently in beta) by navigating to Explore > Trace. On this view, you can filter all spans across your projects by using the search field (which provides hints on what criteria you can filter by).

After discovering the slow LCP issue on the products page, I can use the Trace Explorer to filter all spans by span.description:/products to get a quick overview of the span durations associated with those spans. If I notice anything awry, I can click directly into the trace to investigate.

Try the full debugging experience in real-time

To get an idea of how this Core Web Vitals-based debugging experience might look and feel in the Sentry product, click through this interactive demo.

But wait, there’s even more!

If you’re still not convinced, check out this live Sentry workshop that I recently hosted with Lazar. You’ll get even more insight into how to use Sentry to debug your front-end issues that might have backend solutions, you’ll hear from me about a terrible debugging story that still haunts me to this day, and there may be some jokes. Leave a fun comment if you stop by!

We might use these tests to evaluate out-of-the-box performance for front-end frameworks or to celebrate performance improvements gained by some diligent refactoring. And you know you love sharing screenshots of your perfect Lighthouse scores on social media. It’s a well-deserved badge of honor worthy of a confetti celebration.

Just the fact that Lighthouse gets developers like us talking about performance is a win. But, whilst I don’t want to be a party pooper, the truth is that web performance is far more nuanced than this. In this article, we’ll examine how Google Lighthouse calculates its performance scores, and, using this information, we will attempt to “hack” those scores in our favor, all in the name of fun and science — because in the end, Lighthouse is simply a good, but rough guide for debugging performance. We’ll have some fun with it and see to what extent we can “trick” Lighthouse into handing out better scores than we may deserve.

But first, let’s talk about data.

Field data is important

ocal performance testing is a great way to understand if your website performance is trending in the right direction, but it won’t paint a full picture of reality. The World Wide Web is the Wild West, and collectively, we’ve almost certainly lost track of the variety of device types, internet connection speeds, screen sizes, browsers, and browser versions that people are using to access websites — all of which can have an impact on page performance and user experience.

Field data — and lots of it — collected by an application performance monitoring tool like Sentry from real people using your website on their devices will give you a far more accurate report of your website performance than your lab data collected from a small sample size using a high-spec super-powered dev machine under a set of controlled conditions. Philip Walton reported in 2021 that “almost half of all pages that scored 100 on Lighthouse didn’t meet the recommended Core Web Vitals thresholds” based on data from the HTTP Archive.

Web performance is more than a single core web vital metric or Lighthouse performance score. What we’re talking about goes way beyond the type of raw data we’re working with.

Web performance is more than numbers

Speed is often the first thing that comes up when talking about web performance — just how long does a page take to load? This isn’t the worst thing to measure, but we must bear in mind that speed is probably influenced heavily by business KPIs and sales targets. Google released a report in 2018 suggesting that the probability of bounces increases by 32% if the page load time reaches higher than three seconds, and soars to 123% if the page load time reaches 10 seconds. So, we must conclude that converting more sales requires reducing bounce rates. And to reduce bounce rates, we must make our pages load faster.

But what does “load faster” even mean? At some point, we’re physically incapable of making a web page load any faster. Humans — and the servers that connect them — are spread around the globe, and modern internet infrastructure can only deliver so many bytes at a time.

The bottom line is that page load is not a single moment in time. In an article titled “What is speed?” Google explains that a page load event is:

[…] “an experience that no single metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as ‘fast’, and if you just focus solely on one, you might miss bad experiences that happen during the rest of the time.”

The key word here is experience. Real web performance is less about numbers and speed than it is about how we experience page load and page usability as users. And this segues nicely into a discussion of how Google Lighthouse calculates performance scores. (It’s much less about pure speed than you might think.)

How Google Lighthouse performance scores are calculated

The Google Lighthouse performance score is calculated using a weighted combination of scores based on core web vital metrics (i.e., First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS)) and other speed-related metrics (i.e., Speed Index (SI) and Total Blocking Time (TBT)) that are observable throughout the page load timeline.

This is how the metrics are weighted in the overall score:

The weighting assigned to each score gives us insight into how Google prioritizes the different building blocks of a good user experience:

1. A web page should respond to user input

The highest weighted metric is Total Blocking Time (TBT), a metric that looks at the total time after the First Contentful Paint (FCP) to help indicate where the main thread may be blocked long enough to prevent speedy responses to user input. The main thread is considered “blocked” any time there’s a JavaScript task running on the main thread for more than 50ms. Minimizing TBT ensures that a web page responds to physical user input (e.g., key presses, mouse clicks, and so on).

2. A web page should load useful content with no unexpected visual shifts

The next most weighted Lighthouse metrics are Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). LCP marks the point in the page load timeline when the page’s main content has likely loaded and is therefore useful.

At the point where the main content has likely loaded, you also want to maintain visual stability to ensure that users can use the page and are not affected by unexpected visual shifts (CLS). A good LCP score is anything less than 2.5 seconds (which is a lot higher than we might have thought, given we are often trying to make our websites as fast as possible).

3. A web page should load something

The First Contentful Paint (FCP) metric marks the first point in the page load timeline where the user can see something on the screen, and the Speed Index (SI) measures how quickly content is visually displayed during page load over time until the page is “complete”.

Your page is scored based on the speed indices of real websites using performance data from the HTTP Archive. A good FCP score is less than 1.8 seconds and a good SI score is less than 3.4 seconds. Both of these thresholds are higher than you might expect when thinking about speed.

Usability is favored over raw speed

Google Lighthouse’s performance scoring is, without a doubt, less about speed and more about usability. Your SI and FCP could be super quick, but if your LCP takes too long to paint, and if CLS is caused by large images or external content taking some time to load and shifting things visually, then your overall performance score will be lower than if your page was a little slower to render the FCP but didn’t cause any CLS. Ultimately, if the page is unresponsive due to JavaScript blocking the main thread for more than 50ms, your performance score will suffer more than if the page was a little slow to paint the FCP.

To understand more about how the weightings of each metric contribute to the final performance score, you can play about with the sliders on the Lighthouse Scoring Calculator, and here’s a rudimentary table demonstrating the effect of skewed individual metric weightings on the overall performance score, proving that page usability and responsiveness is favored over raw speed.

The overall Google Lighthouse performance score is calculated by converting each raw metric value into a score from 0 to 100 according to where it falls on its Lighthouse scoring distribution, which is a log-normal distribution derived from the performance metrics of real website performance data from the HTTP Archive. There are two main takeaways from this mathematically overloaded information:

1. Your Lighthouse performance score is plotted against real website performance data, not in isolation.

2. Given that the scoring uses log-normal distribution, the relationship between the individual metric values and the overall score is non-linear, meaning you can make substantial improvements to low-performance scores quite easily, but it becomes more difficult to improve an already high score.

Read more about how metric scores are determined, including a visualization of the log-normal distribution curve on developer.chrome.com.

Can we "trick" Google Lighthouse?

I appreciate Google’s focus on usability over pure speed in the web performance conversation. It urges developers to think less about aiming for raw numbers and more about the real experiences we build. That being said, I’ve wondered whether today in 2024, it’s possible to fool Google Lighthouse into believing that a bad page in terms of usability and usefulness is actually a great one.

I put on my lab coat and science goggles to investigate. All tests were conducted:

• Using the Chromium Lighthouse plugin,

• In an incognito window in the Arc browser,

• Using the “navigation” and “mobile” settings (apart from where described differently),

• By me, in a lab (i.e., no field data).

That all being said, I fully acknowledge that my controlled test environment contradicts my advice at the top of this post, but the experiment is an interesting ride nonetheless. What I hope you’ll take away from this is that Lighthouse scores are only one piece — and a tiny one at that — of a very large and complex web performance puzzle. And, without field data, I’m not sure any of this matters anyway.

How to hack FCP and LCP scores

TL;DR: Show the smallest amount of LCP-qualifying content on load to boost the FCP and LCP scores until the Lighthouse test has likely finished.

FCP marks the first point in the page load timeline where the user can see anything at all on the screen, while LCP marks the point in the page load timeline when the main page content (i.e., the largest text or image element) has likely loaded. A fast LCP helps reassure the user that the page is useful. “Likely” and “useful” are the important words to bear in mind here.

What counts as an LCP element?

The types of elements on a web page considered by Lighthouse for LCP are:

• <img>

  elements,

• <image>

  elements inside an

  <svg>

  element,

• <video>

  elements,

• An element with a background image loaded using the

  url()

  function, (and not a CSS gradient), and

• Block-level elements containing text nodes or other inline-level text elements.

The following elements are excluded from LCP consideration due to the likelihood they do not contain useful content:

• Elements with zero opacity (invisible to the user),

• Elements that cover the full viewport (likely to be background elements), and

• Placeholder images or other images with low entropy (i.e., low informational content, such as a solid-colored image).

However, the notion of an image or text element being useful is completely subjective in this case and generally out of the realm of what machine code can reliably determine. For example, I built a page containing nothing but a <h1> element where, after 10 seconds, JavaScript inserts more descriptive text into the DOM and hides the <h1> element.

Lighthouse considers the heading element to be the LCP element in this experiment. At this point, the page load timeline has finished, but the page’s main content has not loaded, even though Lighthouse thinks it is likely to have loaded within those 10 seconds. Lighthouse still awards us with a perfect score of 100 even if the heading is replaced by a single punctuation mark, such as a full stop, which is even less useful.

This test suggests that if you need to load page content via client-side JavaScript, we‘ll want to avoid displaying a skeleton loader screen since that requires loading more elements on the page. And since we know the process will take some time — and that we can offload the network request from the main thread to a web worker so it won’t affect the TBT — we can use some arbitrary “splash screen” that contains a minimal viable LCP element (for better FCP scoring). This way, we’re giving Lighthouse the impression that the page is useful to users quicker than it actually is.

All we need to do is include a valid LCP element that contains something that counts as the FCP. While I would never recommend loading your main page content via client-side JavaScript in 2024 (serve static HTML from a CDN instead or build as much of the page as you can on a server), I would definitely not recommend this “hack” for a good user experience, regardless of what the Lighthouse performance score tells you. This approach also won’t earn you any favors with search engines indexing your site, as the robots are unable to discover the main content while it is absent from the DOM.

I also tried this experiment with a variety of random images representing the LCP to make the page even less useful. But given that I used small file sizes — made smaller and converted into “next-gen” image formats using a third-party image API to help with page load speed — it seemed that Lighthouse interpreted the elements as “placeholder images” or images with “low entropy”. As a result, those images were disqualified as LCP elements, which is a good thing and makes the LCP slightly less hackable.

View the demo page and use Chromium DevTools in an incognito window to see the results yourself.

This hack, however, probably won’t hold up in many other use cases. Discord, for example, uses the “splash screen” approach when you hard-refresh the app in the browser, and it receives a sad 29 performance score.

Compared to my DOM-injected demo, the LCP element was calculated as some content behind the splash screen rather than elements contained within the splash screen content itself, given there were one or more large images in the focussed text channel I tested on. One could argue that Lighthouse scores are less important for apps that are behind authentication anyway: they don’t need to be indexed by search engines.

There are likely many other situations where apps serve user-generated content and you might be unable to control the LCP element entirely, particularly regarding images.

For example, if you can control the sizes of all the images on your web pages, you might be able to take advantage of an interesting hack or “optimization” (in very large quotes) to arbitrarily game the system, as was the case of RentPath. In 2021, developers at RentPath managed to improve their Lighthouse performance score by 17 points when increasing the size of image thumbnails on a web page. They convinced Lighthouse to calculate the LCP element as one of the larger thumbnails instead of a Google Map tile on the page, which takes considerably longer to load via JavaScript.

The bottom line is that you can gain higher Lighthouse performance scores if you are aware of your LCP element and in control of it, whether that’s through a hack like RentPath’s or mine or a real-deal improvement. That being said, whilst I’ve described the splash screen approach as a hack in this post, that doesn’t mean this type of experience couldn’t offer a purposeful and joyful experience. Performance and user experience are about understanding what’s happening during page load, and it’s also about intent.

How to hack CLS scores

TL;DR: Defer loading content that causes layout shifts until the Lighthouse test has likely finished to make the test think it has enough data. CSS transforms do not negatively impact CLS, except if used in conjunction with new elements added to the DOM.

CLS is measured on a decimal scale; a good score is less than 0.1, and a poor score is greater than 0.25. Lighthouse calculates CLS from the largest burst of unexpected layout shifts that occur during a user’s time on the page based on a combination of the viewport size and the movement of unstable elements in the viewport between two rendered frames. Smaller one-off instances of layout shift may be inconsequential, but a bunch of layout shifts happening one after the other will negatively impact your score.

If you know your page contains annoying layout shifts on load, you can defer them until after the page load event has been completed, thus fooling Lighthouse into thinking there is no CLS. This demo page I created, for example, earns a CLS score of 0.143 even though JavaScript immediately starts adding new text elements to the page, shifting the original content up. By pausing the JavaScript that adds new nodes to the DOM by an arbitrary five seconds with a setTimeout(), Lighthouse doesn’t capture the CLS that takes place.

This other demo page earns a performance score of 100, even though it is arguably less useful and useable than the last page given that the added elements pop in seemingly at random without any user interaction.

Whilst it is possible to defer layout shift events for a page load test, this hack definitely won’t work for field data and user experience over time (which is a more important focal point, as we discussed earlier). If we perform a “time span” test in Lighthouse on the page with deferred layout shifts, Lighthouse will correctly report a non-green CLS score of around 0.186.

If you do want to intentionally create a chaotic experience similar to the demo, you can use CSS animations and transforms to more purposefully pop the content into view on the page. In Google’s guide to CLS, they state that “content that moves gradually and naturally from one position to another can often help the user better understand what’s going on and guide them between state changes” — again, highlighting the importance of user experience in context.

On this next demo page, I’m using CSS transform to scale() the text elements from 0 to 1 and move them around the page. The transforms fail to trigger CLS because the text nodes are already in the DOM when the page loads. That said, I did observe in my testing that if the text nodes are added to the DOM programmatically after the page loads via JavaScript and then animated, Lighthouse will indeed detect CLS and score things accordingly.

You can't hack a Speed Index score

The Speed Index score is based on the visual progress of the page as it loads. The quicker your content loads nearer the beginning of the page load timeline, the better.

It is possible to do some hack to trick the Speed Index into thinking a page load timeline is slower than it is. Conversely, there’s no real way to “fake” loading content faster than it does. The only way to make your Speed Index score better is to optimize your web page for loading as much of the page as possible, as soon as possible. Whilst not entirely realistic in the web landscape of 2024 (mainly because it would put designers out of a job), you could go all-in to lower your Speed Index as much as possible by:

• Delivering static HTML web pages only (no server-side rendering) straight from a CDN,

• Avoiding images on the page,

• Minimizing or eliminating CSS, and

• Preventing JavaScript or any external dependencies from loading.

You also can't (really) hack a TBT score

TBT measures the total time after the FCP where the main thread was blocked by JavaScript tasks for long enough to prevent responses to user input. A good TBT score is anything lower than 200ms.

JavaScript-heavy web applications (such as single-page applications) that perform complex state calculations and DOM manipulation on the client on page load (rather than on the server before sending rendered HTML) are prone to suffering poor TBT scores. In this case, you could probably hack your TBT score by deferring all JavaScript until after the Lighthouse test has finished. That said, you’d need to provide some kind of placeholder content or loading screen to satisfy the FCP and LCP and to inform users that something will happen at some point. Plus, you’d have to go to extra lengths to hack around the front-end framework you’re using. (You don’t want to load a placeholder page that, at some point in the page load timeline, loads a separate React app after an arbitrary amount of time!)

What’s interesting is that while we’re still doing all sorts of fancy things with JavaScript in the client, advances in the modern web ecosystem are helping us all reduce the probability of a less-than-stellar TBT score. Many front-end frameworks, in partnership with modern hosting providers, are capable of rendering pages and processing complex logic on demand without any client-side JavaScript. While eliminating JavaScript on the client is not the goal, we certainly have a lot of options to use a lot less of it, thus minimizing the risk of doing too much computation on the main thread on page load.

Bottom line: Lighthouse is still just a rough guide

Google Lighthouse can’t detect everything that’s wrong with a particular website. Whilst Lighthouse performance scores prioritize page usability in terms of responding to user input, it still can’t detect every terrible usability or accessibility issue in 2024.

In 2019, Manuel Matuzović published an experiment where he intentionally created a terrible page that Lighthouse thought was pretty great. I hypothesized that five years later, Lighthouse might do better; but it doesn’t.

On this final demo page I put together, input events are disabled by CSS and JavaScript, making the page technically unresponsive to user input. After five seconds, JavaScript flips a switch and allows you to click the button. The page still scores 100 for both performance and accessibility.

You really can’t rely on Lighthouse as a substitute for usability testing and common sense.

Some more silly hacks

As with everything in life, there’s always a way to game the system. Here are some more tried and tested guaranteed hacks to make sure your Lighthouse performance score artificially knocks everyone else’s out of the park:

• Only run Lighthouse tests using the fastest and highest-spec hardware.

• Make sure your internet connection is the fastest it can be; relocate if you need to.

• Never use field data, only lab data, collected using the aforementioned fastest and highest-spec hardware and super-speed internet connection.

• Rerun the tests in the lab using different conditions and all the special code hacks I described in this post until you get the result(s) you want to impress your friends, colleagues, and random people on the internet.

Note: The best way to learn about web performance and how to optimize your websites is to do the complete opposite of everything we’ve covered in this article all of the time. And finally, to seriously level up your performance skills, use an application monitoring tool like Sentry. Think of Lighthouse as the canary and Sentry as the real-deal production-data-capturing, lean, mean, web vitals machine.

And finally-finally, here’s the link to the full demo site for educational purposes.

I'm currently building a project using Astro, to which I've added basic authentication via Twitch so users can log in to view their inventory for my new stream game by calling an API on the back end (my Twitch bot). I'm using Astro in SSR mode, and authentication is provided by Auth.js via auth-astro. When using Auth.js to authenticate, it saves three cookies in the browser to remember that you've logged in to this website via Twitch.

At the time of writing, auth-astro doesn't provide sign out functionality for Astro on the server. However, I needed some sign out functionality on the server to provide a better front end experience when the Twitch accessToken was identified as invalid by my back end. I created a logout route to "delete" the authentication cookies provided by Auth.js using Astro's Astro.cookies API.

This code worked great in development, but it didn't work in production.

Copy

// src/pages/logout.astro

// DEV
Astro.cookies.delete("authjs.csrf-token");
Astro.cookies.delete("authjs.callback-url");
Astro.cookies.delete("authjs.session-token");

// PROD
Astro.cookies.delete("__Host-authjs.csrf-token");
Astro.cookies.delete("__Secure-authjs.callback-url");
Astro.cookies.delete("__Secure-authjs.session-token");

return Astro.redirect("/");

The cookie-savvy among you can probably already tell what I was doing wrong. But after deploying my project to multiple hosting platforms to check it wasn't a platform-specific problem with Astro, I learned a few things about how cookies are marked as "deleted", and how servers send instructions to browsers to create and modify cookies.

Cookies are not deleted: they're modified

As a front end developer, I am accustomed to managing cookies via client-side JavaScript using the document.cookie API. There is no way to "delete" a cookie using client-side JavaScript, you modify it: "deleting" a cookie is a misnomer. Whilst the word "delete" feels intuitive in the Astro.cookies API, it hides the fact that to "delete" a cookie, you need to invalidate it by setting an expiry date in the past.

Additionally, you're not technically modifying a browser cookie directly via server-side code. So what's actually happening?

Cookies are modified via HTTP response headers

After receiving an HTTP request, a server can send cookie modification requests to a browser via one or more Set-Cookie HTTP response headers. For example, when you call Astro.cookies.delete("my_cookie"), you'll see the following response header in the browser network tab.

Copy

Set-Cookie: my_cookie=deleted; Expires=Thu, 01 Jan 1970 00:00:00 GMT

This instructs the browser to store the my_cookie value as deleted, and sets the expiration date to a date in the past: 0 in Unix time. It's worth bearing in mind that expiring a cookie doesn't necessarily remove it from the browser storage in all browsers, but browsers will not send expired cookies to the server in subsequent HTTP requests. (Expired cookies also won't show up in the Application tab in browser dev tools.)

Why weren't my cookies being removed in production?

In the code example above, notice that the cookie names for development and production are different. The production cookies are prefixed by __Secure- and __Host-. When inspecting the HTTP headers sent on the logout page in production, I noticed this warning.

This attempt to set a cookie via a Set-Cookie header was blocked because it used the "_Secure-" or "_Host-" prefix in its name and broke the additional rules applied to cookies with these prefixes as defined in https://tools.ietf.org/html/draft-west-cookie-prefixes-05.

If you click the link to this document, you'll see that it's a draft which expired in 2016. For this reason I didn't feel inclined to read it. Why was my browser showing me this in 2024? Regardless, I did a search on the page for __Secure- and found this section on cookie prefixes.

The short version of this story is that the browser was rejecting my Set-Cookie HTTP response headers that were requesting to modify cookies. This was because the cookie options were not specified correctly: they didn't match the cookie options that were specified on the existing cookies. By checking the cookie options in the Application tab in browser dev tools, and updating the code accordingly, I was successfully able to modify the expiration date of the specified cookies, and effectively log the user out of my application.

Copy

Astro.cookies.delete("__Host-authjs.csrf-token", {httpOnly: true, secure: true, path: "/"});
Astro.cookies.delete("__Secure-authjs.callback-url", {httpOnly: true, secure: true});
Astro.cookies.delete("__Secure-authjs.session-token", {httpOnly: true, secure: true});

What do the options mean?

httpOnly: true prevents client-side JavaScript from accessing this cookie, for example via document.cookie to mitigate attacks against cross-site scripting.

secure: true indicates that the cookie is sent to the server only when a request is made with https: (except on localhost), making it more resistant to man-in-the-middle attacks.

path: "/" indicates the path that must exist in the requested URL for the browser to send the Set-Cookie header. This was required given I was redirecting to "/" straight after setting the cookies.

The reason that the initial code successfully modified the cookies in development was because the cookie names were not prefixed with __Host- or __Secure-, and because I was running the site on localhost.

Naming is hard

I'm a big fan of naming things after their specific function. Should the Astro.cookies API rename delete to modify in order to be more explicit? Probably not. In any case, I decided to open a PR to the Astro docs to clarify what was actually happening.

Why you need a personal website

Your personal website is your personal showcase: a one-stop-shop to show off your work, skills, personality, and ✨aesthetic✨. You could use your personal website as a place to collect what you’ve learned and what you’ve built over the years, whether that’s through traditional blogging or creating interactive demo pages. Or you could use it to build community through shared interests, to land that exciting new job, as a place to improve your refactoring skills, as an archive for your weekly newsletter, to test-drive Test Driven Development, or to build a proof-of-concept of something that really excites you.

Your personal website is also a great place to use as a playground for new and experimental features on the web, to try out new UI component frameworks or CSS methodologies, or to stretch the boundaries of what’s possible in a browser.

Personal websites are low-risk, high reward

Think of your personal website as a super low-risk test environment where you can build anything you ever dreamed of without having to worry about deadlines, stakeholder management, or client feedback.

And because a personal website is usually low-risk (i.e. there’s no P0 panic if you find a bug or it goes down) it’s also a great tool to help you learn about web performance. Through using a variety of tools such as Google Lighthouse, built-in browser dev tools, or an Application Performance Monitoring tool like Sentry, you can use your personal website to identify common performance issues and experiment with different fixes to see what gets the best results. What’s more, you can transfer all that learning to the things you build in your day job. And if you are using your personal website as an online resume, you’ll make a better first impression if it loads quickly and feels fast to use: win-win. (As a hiring manager in the past, I definitely inspected the DOM and the network tab of candidate websites.)

If you don’t yet have a personal website, go make one! It could be as simple as a single page of HTML deployed to a CDN. And then come back to check out these five easy tips for speeding up your personal website performance that you can apply to any website, project, or product.

1. Serve static HTML as much as possible

It’s too easy to render pages on the server in 2024. Most modern JavaScript-based frameworks come with pre-built adaptors to be able to deploy and server-side-render (SSR) your websites on demand using your preferred hosting platform. We also have edge-rendering and edge functions that allow us to intercept HTTP requests at the edge (the closest server location to the request) to add even more dynamic content to our pages based on geolocation, cookies, and more. But all of this comes at a cost — most notably to performance and your Time to First Byte (TTFB): the time it takes for the browser to receive the first byte of content from the server. (And let’s not forget the ongoing, and sometimes unexpected, monetary costs of running SSR.)

A brief history of the web

The web moves in cycles. In the 1990s the web was mainly static, delivering plain HTML documents that were stored on servers somewhere in the world; this was the Read Things era. As the web became a place where you could now do things (such as sign up and log in and CRUD), SSR — building pages on the server before sending them back to the browser — was necessary. In the early 2010s when JavaScript was more widely adopted, client-side-rendering (CSR) — sending a blank or skeleton HTML document and then building the page content in the browser — became the norm. The issue was that people still needed to read things on the internet as well as do things. And with the rise in SSR and CSR, reading things started to feel slow. In the mid-2010s, the modern web offered up a modern alternative: static site generators.

Static site generators make fast sites

Static site generators (or early “front end frameworks”) provided developers with a way to build a folder full of HTML files, each populated with the required page data at the time of build. Developers could now create tens of thousands of static HTML pages, stick them on a Content Delivery Network (CDN), and not have to worry about maintaining servers, scaling for traffic, or security policies. This was the beginning of Jamstack.

Fast-forward ten years, and “Jamstack” may be considered dead as a concept, but the principles of serving cached static content from a CDN for secure and performant websites still hold true. Serving static HTML files is much more performant than generating web pages on demand on a server for every request. This is because the server doesn’t need to do anything apart from retrieve your HTML document from the cache and send it back. No business logic, no database queries, no delays. Of course, there are times when you may need some level of dynamic page content. But on a personal website, you probably don’t need SSR.

You probably don’t need SSR

What has been interesting to observe is how the rise in popularity of “full stack front end frameworks” such as Next.js has started to promote using SSR methods and even edge-rendering over serving static content. What I also observed in the mid 2010s is that Next.js was originally marketed as yet another static site generator, encouraging developers to use dynamic page generation sparingly. But now, many blog or personal website templates built on frameworks like Next.js often come with SSR as the default page behavior. But content-based websites — which most personal websites are — don’t need SSR. Personal websites usually involve reading things, not doing things.

If you’re currently using SSR on your personal website, ask yourself if you really need to. By pre-building and serving pages statically I guarantee you’ll see performance gains. Take for example a case study on my personal website which should convince you. Over the years I experimented so hard with Edge Functions to add some dynamic elements to my static personal website that I pushed my p75 TTFB up to almost 4 seconds. I was devastated to learn this. Read how I improved the TTFB by 80% and if you want a spoiler: I just built the pages statically again.

2. Optimize images

Even if it’s just a headshot somewhere on your “about” page or a meme on your homepage, you’re probably using images on your personal website. Images are everywhere on the web. And they need to be optimized. But what do we mean by optimizing images?

Serve images in next-gen formats

If you’ve analyzed your personal website performance using Google Lighthouse, you might have been given the advice to “serve images in next-gen formats”. Next-gen (next generation) image formats are file types that use modern image compression algorithms, resulting in smaller image file sizes. This, in turn, results in better web page performance given the web browser has fewer bytes to download per image. Instead of serving PNG or JPEG image file formats, it is recommended to convert those to webp or avif file formats. Additionally, if you want to serve an animated gif, convert it to a webp file, which will preserve the animation while reducing the file size by almost 90%. Here’s a throwback to when I discovered this in 2021.

How to convert your images to next-gen formats

Depending on your preferences and how many images you need to optimize, you can use offline tools, build-time tools, third-party services, and image manipulation APIs to convert your images to modern formats on your personal website. Also, bear in mind that not all browsers support avif and webp image formats just yet, so it’s important to use the HTML <picture> element to allow the browser to choose the most appropriate image file format to download and display.

Lazar guides you through all the low-effort image optimization tips you need to make sure your personal website stays in good shape, with some bonus advice on how you can monitor your website performance using Sentry in terms of image resources.

3. Use system fonts

It’s too easy to use Google fonts. Choose a font and slap a link to the font file in the head of your pages. Done. The hardest part is deciding which fonts to use. And I get it. Fancy fonts look great. But do you really need custom fonts? Like really, really? You could get a huge performance boost by using system fonts. No downloading, no layout shifts, no flashes of unstyled content.

If you do want to use non-system fonts, it’s recommended to serve font files from the same server as your website, rather than ask the browser to fetch them from a third-party service at runtime such as Google. While you can download font files from the Google Fonts website and serve them yourself instead of linking to them, you’ll still have to convert the provided ttf font files to file formats required for the web (woff and woff2). In the past, I’ve always used Font Squirrel Webfont Generator to do this, but in 2024 this feels hacky. In my experience, Font Squirrel tends to do weird things with variable font files (which you should also use to improve your website performance).

I’m not sure why we haven’t solved the font file format problem yet. And because the best network request is the one that’s never made, why not scrap the custom fonts altogether and just use system fonts? You may fret that your website might look different on MacOS, Linux, and Windows, but maybe that’s the fun of it. And system fonts are no longer limited to just Times New Roman and Arial. Modern Font Stacks shows us just how good system fonts can look in context.

Lazar goes deeper into the web font conversation in Web Fonts and the Dreaded Cumulative Layout Shift.

4. Remove render-blocking resources

In 2022, I refactored my personal website from Next.js to Eleventy. This decision was centered around being able to know exactly what files were being delivered to the browser so that I could keep tabs on performance. With Next.js I noticed my website was making over 30 requests for separate chunked JavaScript files for a static page with no interactivity. It didn’t make sense. That same page created with Eleventy served no JavaScript files, which is correct — because the page didn’t need any JavaScript. All this is to say that as a responsible developer, you should be aware of what you’re sending down the wire to your users — especially if it ends up being a render-blocking resource. I made a YouTube short about this in 2022 to show the difference in what the two frameworks delivered to the browser.

A render-blocking resource is as it’s described: a downloadable resource that blocks the render (or “first paint”) of a web page, delaying the time that a user sees something in the browser. The more render-blocking resources that stack up on top of each other, the longer your page takes to load, and the worse your First Contentful Paint (FCP) web vital score will be. Google stipulates that to provide a good user experience, web pages must have an FCP of 1.8 seconds or less.

There are render-blocking resources we can’t escape, such as CSS (both inline CSS and CSS contained in stylesheets), but your website may have fallen victim to other render-blocking resources loaded via <script> tags in the <head> of your website pages. Take for example when the SyntaxFM team at Sentry discovered a 4kB render-blocking script that added around 500ms to each page load on average.

It may be that some of your dependencies need to be render-blocking, and that’s fine. But by considering the impact of render-blocking resources and being mindful of how and when you load JavaScript every step of the way, you’ll most likely be able to keep your Core Web Vitals scores looking good. Google offers more advice in this article on how to eliminate render-blocking resources.

5. Use less JavaScript

I am once again going to reference this evergreen piece of advice from Cassidy Williams in an article on CSS Tricks: “Your websites start fast until you add too much to make them slow.” When reaching to build that next feature on your personal website, ask yourself, can you do it without JavaScript?

Perhaps you want to build a contact form. You don’t need JavaScript for a form. How about using native HTML form functionality which includes HTML5 field validation? Why not go wild and just include a mailto link?

You probably don’t need JavaScript to achieve many modern UI animations. CSS is super-powerful these days, and I’m always looking for opportunities to use some of the newer features, such as scroll-snap-type.

You can even almost create a CSS-only masonry layout. The technology is still experimental, and in Safari Technical Preview, but let’s hope it’s coming soon.

And if you’re thinking about rendering some UI components using JavaScript on the client — can you build those components using static HTML, instead?

Challenge yourself to add less.

The HTML whitespace problem

Formatting code using Prettier is often a frustrating battle. Standard configuration options that make sense for the majority of code formatting could cause unexpected problems in the rendering of whitespace in HTML.

Say I want to render a link followed by a full stop at the end of a paragraph, like this:

Copy

<p>p4nth3rworld is a multiplayer text-based game powered by a live coding stream at <a href="https://twitch.tv/whitep4nth3r/chat">twitch.tv/whitep4nth3r</a>.</p>

A certain Prettier setting might auto-format the code to look like this. You'll notice that the full stop has been placed on a new line after the closing anchor tag.

Copy

<p>
  p4nth3rworld is a multiplayer text-based game powered by a live coding stream at 
  <a href="https://twitch.tv/whitep4nth3r/chat">
    twitch.tv/whitep4nth3r
  </a>
  .
</p>

This renders undesirable whitespace in the HTML in the browser, like this:

This happens because whitespace is treated literally in inline HTML elements: 1<b> 2 </b>3 will output a different result to 1<b>2</b>3. Given anchor tags are display: inline by default, any whitespace in and around these elements will not be ignored and will be rendered literally.

To fix this, you might need to configure Prettier's HTML Whitespace Sensitivity option — and you might need to change some other options, too.

Configure Prettier HTML Whitespace Sensitivity

Prettier allows you to specify the global whitespace sensitivity for HTML using the following options:

The default option for Prettier's whitespace sensitivity setting is "css", which should mean that full stops after a closing anchor tag don't wrap onto a new line and cause whitespace issues (given <a> elements are inline elements). However, this wasn't the case with my code. It seemed like I needed to use the strict option, which formatted the code like this.

Copy

<p>
  p4nth3rworld is a multiplayer text-based game powered by a live coding stream at
<a href="https://twitch.tv/whitep4nth3r/chat"
   >twitch.tv/whitep4nth3r</a
  >.
</p>

Now, despite the whitespace problem being solved in the resulting HTML in the browser, this presentation still wasn't ideal for me given the the closing angled brackets were put onto a new line. This was the case even though I specified that brackets should stay on the same line using the Prettier Bracket Line configuration. As it turns out, the length of my paragraph and anchor link created a bit of an edge case, and I needed to increase the printWidth setting.

Configure Prettier Print Width

Prettier Print Width specifies the line length at which your IDE will wrap text. The Prettier default is 80 characters. By arbitrarily changing prettier.printWidth to 90 in my configuration settings, the HTML was more readable in combination with the whitespace sensitivity setting.

It's worth mentioning at this point that by increasing the printWidth, the default htmlWhitespaceSensitivity: "css" produced the desired formatting results. I decided to leave the whitespace setting as strict to remind me of this pain in the future.

Here are the two settings I'm currently using:

Copy

{
  /* in pretter config file */
  htmlWhitespaceSensitivity: "strict",
  printWidth: 90

  /* in VS Code settings */
  "prettier.htmlWhitespaceSensitivity": "strict",
  "prettier.printWidth": 90
}

Ugh, what a minefield

Should I have needed to change the printWidth in order to respect the bracketSameLine setting for this particular block of code? Probably not. Alas, Prettier states that it's an opinionated code formatting tool. Make of that what you will.

The TL;DR is that the delivery and optimization of CSS have both been improved with modern tech stacks, making it practically a non-issue. The efficient and performant delivery of CSS is largely solved by HTTP/2 and modern compression algorithms, whilst modern front end frameworks take care of the boring optimization jobs such as code-splitting and minification. Gone are the days when setting up a new front end project involved hours of frustrating manual configuration of Grunt files or Gulp files to compile, minify and post-process CSS files.

Why you should minify your CSS files

Minification in CSS is the process of removing all unnecessary whitespace so that files are smaller in size, but can still be understood by the browser. In short, minifying your CSS helps to optimize your First Contentful Paint (FCP).

FCP is a Core Web Vital that measures the perceived load speed of a web page, and it marks the first point during page load where a user can see anything on the screen. A good FCP score is measured as 1.8 seconds or less and reassures the user that something is loading so that they don’t bounce away. To ensure a good FCP score, your stylesheets or inline CSS should be as small as possible (i.e. minified and compressed) so that they take less time to download and can be processed faster, allowing the browser to paint something on the page sooner. All of the above also contributes to optimizing the critical render path (the steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen). This is especially important for users who have slower internet speeds.

Additionally, CSS is a render blocking resource, meaning the browser won’t show any content until it has downloaded the CSS and constructed the CSSOM (CSS Object Model) in conjunction with the DOM (Document Object Model). This makes sense; most modern web pages won’t function correctly without CSS. Plus, if CSS is loaded and applied after HTML renders on the page, users will experience a Flash of Unstyled Content (FOUC) before the CSS rules are applied. Styling and arranging content after it has loaded will also likely negatively impact your CLS score (we’ve already got enough CLS to worry about with fonts, images and other unexpected issues!). CSS delivered in stylesheets and as inline CSS in the <head> tag of your pages are both render blocking.

CSS minification tools

There are a number of tools available to minify CSS in development or as part of your build pipeline including, but not limited to, cssnano and Vite. If you’re using sass, it’s as straightforward as adding --style=compressed to your sass command. The results you achieve may vary depending on the complexity of your CSS, but you may see numbers similar to this (processed with sass):

What’s interesting, though, is that these numbers pertain to files store on disk. Files delivered from a server will actually be much smaller. And this is where compression comes in.

Modern HTTP compression algorithms

HTTP compression is used by web servers and clients (browsers) to improve the transfer speed of resources, and it also helps to save on bandwidth costs and overheads. There are a number of compression algorithms available, but not all are supported by modern browsers.

Servers may support multiple compression types, and the most common compression types currently used on the web are gzip and Brotli. When making an HTTP request, browsers tell the server which compression methods they are able to decode, at which point the server sends the appropriately compressed file version. Browsers that do not support the available compression methods will receive uncompressed data. While sending and receiving uncompressed data probably isn’t common in 2024, it’s worth bearing in mind for people using older or more niche devices that don’t receive automatic software updates.

You can inspect HTTP request and response headers for network requests in browser dev tools to understand more about what’s described above. Here’s an example:

Request headers (sent to the server):

• Accept-Encoding lists the compression methods the client/browser supports

Response headers (received from the server):

• Content-Encoding describes the compression method used to decode the transferred data

• Content-Length provides the size of the compressed file in bytes

If you’re using Sentry performance to monitor your applications, you can also inspect the response headers for each network request in the associated span.

What’s interesting is that the difference in size between a non-minified compressed file and a minified compressed file isn’t that significant. In the case of the CSS file for my personal website, there was a saving of only 1kB.

Whilst 1kB may not seem much, the savings will most definitely benefit both you and your users on a larger scale. As of March 2024 the global median internet speed on mobile is 52.98Mbps. While that equates to being able to download 6625kB per second (calculated here and rounded up to 53Mbps), if you can shave off just 1kB from a total of 100 resources on each page load, you could be making a 15ms improvement on your page speed for those users:

Copy

How long does it take to transfer 100kB at 6.625 kB/ms?

6625kB/s transferred
6625 ÷ 1000 = 6.625 kB/ms transferred

100 kB ÷ 6.625 kB/ms = 15ms*

*This is an extremely basic calculation not taking into consideration TCP slow starts or any other network effects that affect data transfer, but it serves as an example nonetheless.

Simultaneously you’ll be saving bandwidth costs as a developer or organisation. While 1kB isn’t much of a saving for a single user, for 1000 users this equates to transferring 1MB less data.

HTTP/2 multiplexing

Another advancement that may mean CSS minification is not-that-important-anymore is HTTP/2. Released in 2015 and adopted over time, HTTP/2 allows the server to use a single connection to deliver multiple requests and responses in parallel (multiplexing). To take advantage of this, front end bundling tools and frameworks provide the ability to “code split” or “chunk” larger CSS files and JavaScript packages in order to ship smaller files simultaneously, whilst the underlying technology pieces those files together in the client for the web page to function correctly.

If a non-minified compressed CSS file is only 10kB, and then split into smaller chunks of, say, 2kB, then minification becomes kind of a non-issue. Additionally, many modern front end frameworks take care of this for us anyway.

CSS minification and code-splitting in front end frameworks

If you’re using a modern front end framework, you’ll usually get CSS minification and/or code splitting out of the box. Frameworks provide their own opinionated, yet sensible default configurations for CSS post-processing, and you can choose to optimize those options further if you wish. Additionally, by serving your websites and applications from modern hosting platforms and CDNs, you’ll benefit from HTTP/2, caching and compression without even having to think about it.

Here’s how just some of the modern JavaScript-based frameworks handle CSS today.

Astro

Astro automatically minifies and combines your CSS into chunks, and further optimizes CSS shared between pages for reuse. Another optimization from Astro is that it “inlines” any CSS chunks that are smaller than 4kB in size (i.e. puts the CSS in a <style> tag in the <head> of the page) to prevent too many network requests for small stylesheets. This provides a “balance between the number of additional requests and the volume of CSS that can be cached between pages.”

Next.js

Next.js comes with a number of pre-configured optimizations for using CSS Modules, Tailwind, Sass and and CSS-in-JS. For example, when using CSS Modules, many smaller files will be automatically bundled into fewer minified code-split CSS files to reduce the number of network requests.

Nuxt

Nuxt comes with postcss and a number of pre-configured CSS minification and optimization plugins including postcss-import, postcss-url, autoprefixer and cssnano.

SvelteKit

SvelteKit uses Vite under the hood to build and bundle projects. This comes with configurable CSS code-splitting and minification.

Where Astro inlines all CSS files smaller than 4kB in size, SvelteKit comes with an inlineStyleThreshold configuration which allows you to explicitly specify the maximum length of a CSS file in UTF-16 code units to be inlined. All CSS needed for the page and smaller than this value are merged and inlined in a <style> block.

Angular

Angular’s build process comes with an --optimization flag which enables CSS minification and inlining of critical CSS. To save even more bytes, you can also choose to use the removeSpecialComments flag during a build to remove comments in CSS and other extraneous characters.

Conclusion

With the luxury of modern web hosting platforms and CDNs caching and delivering files fast to users around the world, powerful compression algorithms and the wide adoption of HTTP/2, I guess we don’t really need to think about CSS minification anymore. It’s generally taken care of for us in modern front end tooling — albeit in opinionated ways. That being said, it is incredibly important for us, as front end developers, to understand how CSS is being delivered to the browser in our applications in order to monitor the impact it has on the performance of our apps in production.

Yes, these modern frameworks are doing a lot for us. But can we do more?

Sarah Guthals reacts and discusses the main take-away of this post.

CLS is one of the Core Web Vitals that your pages are scored (and ranked) on by Google. It’s often caused by client-side data-fetching after a page has first loaded, and loading large images, ads or embedded media players, all of which are made worse by slow internet connections. The purpose of using CLS as an indicator of performance is to ensure that we’re building great user experiences, and not causing users to accidentally perform actions they did not intend. Not all CLS is bad, however. Google states that “In fact, many dynamic web applications frequently change the start position of elements on the page. A layout shift is only bad if the user isn’t expecting it.”

How is CLS measured?

CLS is measured on a decimal scale. A good cumulative layout shift score is 0.1 or less. A poor CLS score is greater than 0.25. Similar to how Interaction to Next Paint (INP) is measured, Google assesses your page for CLS based on the largest burst of unexpected layout shifts that occur during a user’s time on the page. Smaller one-off instances of layout shift may be inconsequential, but a bunch of layout shifts happening one after the other, i.e. cumulatively, is what we need to avoid.

How to avoid unexpected cumulative layout shift

There are tried-and-tested ways to avoid causing CLS on your web pages, including but not limited to:

• Include width and height attributes on image elements and iframes.

• Provide placeholder elements (sometimes known as skeleton loaders) that are the same dimensions as dynamic elements that may be loaded via JavaScript later in the page life-cycle.

• Use the CSS at-rule @font-face: size-adjust to minimize any shifts caused by font files loading after the initial page render. Lazar Nikolov takes a deep dive into this topic in his article: Web Fonts and the Dreaded Cumulative Layout Shift.

This post is not intended to be a complete guide to preventing CLS, but to highlight an edge case you might not be aware of. If you’re interested, however, Barry Pollard writes in depth about how to fix CLS issues in Smashing Magazine.

How to check for CLS during development

You can use the Performance tab in Chromium browsers (such as Edge, Brave, Chrome and Arc) to identify layout shifts and their associated scores. You may want to simulate slower internet connectivity and slower machines by enabling CPU and network throttling, depending on the target audience of your website.

Click the reload button to record the page load and wait for the profile to generate. If any layout shifts happen, you’ll see a Layout Shifts lane. Zoom in and click on a layout shift event, which will open up a summary tab below with additional details, including the cumulative score for that event.

Additionally, a new and experimental tool in Chrome browsers called “Performance Insights” helps you identify layout shifts a lot quicker. To enable this tool, click on the three dot menu to the top right of dev tools, hover over “More tools” and click on “Performance insights”.

With the Performance Insights tab selected in dev tools, click the “Measure page load” button. This will refresh the page and record what happens on load. On the insights panel to the right, you’ll see any registered CLS with an associated score. Click the event to inspect more details about it, including the source of the layout shift in the HTML.

CLS is not just for foreground elements

Now, let’s get to what we’re really here for. We usually talk about CLS disrupting the user experience by unexpectedly shifting content on a page that a user might interact with. As a result, I always figured CLS was calculated based on content shifting in the foreground only, i.e. interactive UI elements that are part of the actual user experience.

However, I recently discovered that CLS is calculated for all page elements, including elements in the background that may not actually shift UI elements for the user. This makes perfect sense, actually. The CLS calculator can’t really be intelligent enough to take into account the z-index of a page element.

How did I discover this? Sentry found it for me on my website.

How to discover CLS in production for your real users

Whilst checking for CLS in development is good practice, nothing beats analyzing real data captured from real users interacting with your websites. I recently started using Sentry to monitor the performance and Core Web Vitals for my personal website.

I have configured Sentry Performance to capture information for 50% of my traffic. For each captured event (or transaction), Sentry sends a number of associated tags which can include sources of CLS if relevant. What’s really helpful is that Sentry also includes the HTML elements that point to the source of the CLS, so you know exactly where in your code to look to fix it.

To discover your top sources of CLS, open up Sentry and navigate to Performance > Web Vitals. Below the top level performance score and score breakdown, you’ll see a table listing all of your page URLs. Click on the CLS header to sort by score descending to find the worst score. For my date range selected, the highest CLS was 0.66. This is the p75 score, which is the highest CLS value that 75% of users experienced for that page.

Click on the top item in the table. You’ll then see an overview of all sampled events for that particular page (not just p75). Sort the table of events by CLS descending again to find the highest score. I’m going to investigate an event that reported a CLS of 0.92.

On the event details page, scroll down and look for the Tag Details section, which should show a tag key of cls.source.1. Hover over it to see the full HTML element source captured.

Now here’s where things got interesting. For this page on my site, the main source of CLS was coming from a CSS pseudo element attached to the main element, which contained an SVG that provided a little bit of design flair to the page. Here’s what I was sure of:

• The SVG was added to the page via the CSS content property.

• It had a z-index of -1 with a fixed position.

• It didn’t cause any foreground content to shift visually.

So what was the deal, here?

I broke the first rule of CLS: width and height attributes

Much to my disappointment, I discovered that I had not specified a width and height on the SVG that was added to the page via CSS. Shame on me. Fixing my mistake by adding a width and height on the SVG meant I had to make some changes to the CSS. And in hindsight, the changes actually led to more semantically correct CSS (more on that, later).

Here’s the diff of the changes and let’s explore why those changes were necessary.

Copy

main::after {   
-   content: url("path-to.svg");
+   content: "";
+   background-image: url("path-to.svg");
+   background-repeat: no-repeat;   
+   background-size: cover;
+   height: 0;
+   padding-bottom: calc(100% * 201 / 1280); /* image aspect ratio */
    position: fixed;
    bottom: 0;
    left: 0;
    width: 100%;
    z-index: -1;
  }

Why I chose a pseudo element

Pseudo-element selectors allow you to use CSS to style a specific part of a DOM element, such as the box that is drawn before or after an element. The initial value for the content property of the ::before and ::after pseudo elements for each DOM element is normal, which computes to none. This prevents the DOM from drawing an excess number of boxes that might never get used. You can read more in the official W3C spec for the content property, but it’s a difficult read.

Given this SVG was a design detail and not important in the flow of page content, I chose a pseudo element to display it to document that hierarchy in the code. Originally, the SVG was added to the page via the content property of the ::after pseudo element of the main HTML element.

The problem with styling SVGs in pseudo elemnets

Adding width and height attributes to the SVG without modifying the original CSS meant that the image didn’t span the full width of the page as intended. Instead, width: 100% in the CSS calculated the SVG width as 100% of its given width attribute size (1280px).

Copy

<svg viewBox="0 0 1280 201" width="1280" height="201" role="img"   xmlns="http://www.w3.org/2000/svg">
    <!-- SVG paths here -->
</svg>

In order to stretch an SVG to 100% of a container width using the width property in CSS, you need to be able to target the SVG element in CSS directly. Given the SVG was added via the content property of a pseudo element, this wasn’t possible: objects inserted using the content property are known as replaced elements, which are actually outside the scope of CSS. Adding a relative width attribute value of 100% to the SVG itself wouldn’t have solved the CLS issue either — because the browser needs an absolute pixel value in order to calculate the space in which to draw it.

And this got me thinking, if the content property made this so difficult to achieve, there must have been an easier way to make it work. And here’s where I started thinking about the concept of semantic CSS.

A move to semantic CSS

The use of the content property contradicted the intention of this background image. It wasn’t content, it was a background image. And so in the final implementation, I set the content property to an empty string so that the pseudo element could be drawn, and used the background-image properties to configure the SVG as a background image, as the design intended.

If you’re curious about the padding-bottom hack, this was necessary in order to scale the SVG proportionately when stretching it across the full width of the viewport given that auto-sizing isn’t an option for CSS background images. It wasn’t possible to set the width of the SVG as 100% and height as auto in order to achieve the desired result. Read more about scaling SVG in Amelia’s article on CSS Tricks.

This might have been trivial, but it matters

This was perhaps a trivial issue to investigate in such depth. However, CLS is one of those Core Web Vital scores that is prone to suffering from death by 1000 cuts. Sure, small bits of layout shift here and there are inevitable, and sometimes, acceptable. But the more you focus on solving the small problems when they arise, the less likely it is that you’ll suffer from the cumulative effect of performance issues. Which means you spend less time fixing, and more time building.

Using Sentry performance monitoring

As developers, we usually focus on performance for short bursts at a time: when a new site is launching, when a new feature is in development, or when we discover our site is really, really slow. During 2021-22 I rebuilt my website from the ground up in order to improve performance and the results were great. But, over time I added so many extra bits of experimental technology to different areas of the site that performance, once again, had become embarrassingly bad. I’d noticed this myself when loading my website over the last few months, but it was only when I added Sentry performance monitoring to my site that I was able to see the full picture.

What’s great about using a performance monitoring tool like Sentry is that it shows you real user data for your websites, across all the operating systems, browsers, mobile devices, internet connections and many other factors that affect the user experience. Previously I’ve used tools such as the Google Lighthouse in development or during a website build to analyze performance for each new build — but this only gave me a snapshot of the performance scores during the build pipeline for build servers. Real user data is far more valuable.

Here’s what the performance looked like on my homepage before any modifications from February 14-21 2024.

The most urgent thing that stood out to me to improve was the Time to First Byte (TTFB). TTFB refers to the time it takes for a browser to receive the first byte of response after it made a request to the server. Theoretically, the lower the TTFB, the sooner the browser can start painting the page, and the sooner users will see something in the browser, making them less likely to bounce away. 

The TTFB value displayed here is for the 75th percentile (p75), meaning that 3.46s was the worst score found across 75% of all homepage views. This also means that 25% of users were waiting for longer than 3.46 seconds for the page to load. This poor score indicated that there was too much processing happening on the server before the response could be sent back. Here’s what was happening.

For some time, I had been using two separate middleware functions (or Edge Functions) at request time: one to fetch data from my newsletter provider to get the latest number of subscribers, and one to fetch data from the Twitch API to show my latest stream video, or the latest thumbnail from a current live stream in progress. Both functions would grab the initial HTTP response in memory, fetch some data from a third-party API, and rewrite the HTML accordingly.

The aim of this architecture was to minimize client-side data-fetching which could block the main JavaScript thread to show some dynamic data on a statically generated homepage (and I hate skeleton loaders). This was great from a "show the user the most up to date thing" point of view, but the downsides of this is that it effectively duplicated the HTTP request and therefore doubled the time it took to show something in the browser. Add on top of this the varying API latency from two separate third-party services in static regions being called from anywhere in the world (the edge) and you start getting into a bit of a mess.

Plus, what use did the accurate newsletter subscriber number provide to anyone except me? And why did I really need to show the latest randomly generated stream thumbnail, especially given that most of the time it was a very unflattering image of me trying to work out how to code? People aren’t sitting in front of my homepage and refreshing it every few minutes to get an updated Twitch thumbnail. I had gone too far.

Approximating data is fine, actually

My priority at this point was to focus on improving the TTFB. The first step was straightforward: remove the Edge Function that fetched the number of newsletter subscribers, and instead fetch the data at build time and generate it statically. The number won’t be up to date until I do a rebuild, but we can account for small inaccuracies by adding a plus symbol to the number, or returning a string to approximate the number if the API call errors at build time.

Copy

function getNewsletterSubscribers() {
  let subscribers;

  try {
    const response = await fetch(
      "https://api.email-provider.com/subscribers",
      {
        headers: {
          //...
        },
      },
    );

    const result = await response.json();
    subscribers = `${result.count.toString()}+`;
  } catch () {
    subscribers = "loads of";
  }

  return subscribers;
}

Removing just one Edge Function from the middleware chain improved the p75 TTFB greatly — and the difference was actually noticeable in the browser as a user loading the page. I monitored this single change for a week and the p75 value for TTFB had decreased from 3.46 seconds to just 1.88 seconds. This was a 46% decrease in how long it took for 75% of users to see something on my homepage in the browser. With one small change, all Core Web Vital scores had also improved.

The problem with moving data fetching from the server to the client

The next step was to remove the Edge Function that fetched the Twitch data. My hypothesis was that moving this to the client and writing the data to the DOM when it was ready would improve the perceived performance of the page for users — even if the data wasn’t all there yet. Without the middleware intercepting the HTTP request, the TTFB would reduce, and users would see something in the browser sooner.

First, I moved the Twitch data fetching from the server to a client-side web worker, to avoid introducing new render-blocking behavior on the main thread. However, whilst the TTFB did indeed decrease, Cumulative Layout Shift (CLS) became a problem.  (I also could have opted to load the JavaScript as an async deferred script but the visual results would have been the same.) 

There are always tradeoffs to make when improving site performance, specifically with regards to Core Web Vitals. When you make improvements in one metric, you may end up sacrificing the score of another. Fetching the data and updating the DOM after the page had loaded meant that the Twitch stream thumbnail loaded up to a second later in my dev environment, causing the page content to shift. This could be even longer for real users. Layout shifts usually happen when the element’s size is not defined in the initial HTML or CSS. There are ways to get around this, such as by including a placeholder image of the same size (with height and width specified on the element) that is later replaced by the fetched image, but in my opinion this is also not a good experience, especially on slower internet connections. At this point, I had moved one performance problem from the server and created a new performance problem in the client.

It was time to make my website as static as possible again — but this approach still came with some tradeoffs.

Making sensible tradeoffs to reduce TTFB

When I rebuilt my website two years ago, I made a deliberate decision to build it as a static site using as little client-side JavaScript as possible, and the simple no-nonsense design of the site took this into account. My website has always been designed to be a marketing channel for my Twitch streams, and so I always want to include something about Twitch on the home page. When I first launched the website rebuild in 2022, I included a link to the next scheduled stream which was fetched and pre-generated at build time. Each time I went on or offline on Twitch, I used a webhook to rebuild the site to update it with new information. If you’re curious, here’s a snapshot of the website when it first launched.

To improve the TTFB without introducing new CLS, I made the homepage static again, rebuilding it using a webhook (in my Twitch bot application) each time I go on or offline on Twitch. If I’m not live on Twitch, the page is statically generated with my latest stream thumbnail and information at build time. If I am live on Twitch, here’s where the performance tradeoffs come into play.

Instead of fetching data from the Twitch API at request time to get the latest live stream information, I now use the Twitch video player embed to show the current live stream. The downside to this is that the page loads some extra client-side JavaScript to show the player. However, given that I’m live streaming for around only six hours per week, I figured this was a good tradeoff. The rest of the time you get a super-fast static experience.

Here’s a simplified view of the code for the Twitch component (which is a JavaScript function that builds static HTML) on my homepage for completeness. The isLive and vodData parameters are fetched at build time from the Twitch API.

Copy

function TwitchInfo({ isLive, vodData }) {
  return `
  ${
    !isLive
      ? `<a href="${vodData.link}">
           <p>${vodData.title}</p>
           <p>${vodData.subtitle}</p>
          <img
            src="${vodData.thumbnail.url}"
            alt="Auto-generated stream screenshot."
            height="${vodData.thumbnail.height}"
            width="${vodData.thumbnail.width}"
          />
        </a>`
      : `<div id="twitch-embed"></div>
      <script src="https://embed.twitch.tv/embed/v1.js"></script>
      <script>
        new Twitch.Embed("twitch-embed", {/* options */});
    </script>`
  }
  `;
}

Improving performance is a balancing act

Ultimately, you may have to make some compromises in order to make performance gains. By deciding that it’s acceptable to show inaccurate data and load some extra JavaScript for a few hours per week, I’ve improved the Core Web Vitals scores massively on my homepage, which is the most visited page on my site. Inaccurate data might not be appropriate for every website and app — but it’s something to consider when balancing performance improvements.

After removing both Edge Functions that ran on my homepage, and returning to a completely static build, I reduced the p75 TTFB by 80% to just 704ms. Whilst 25% of users are still experiencing a TTFB of over 704ms, 75% of my users see a page loaded in under 704ms. I’m really happy with the progress so far. If this isn’t a glorious advertisement for static sites and in turn, static site generators, I don’t know what is.

I’ve still got some further optimizations to make on the homepage, such as some local image optimizations (such as serving images in avif and webp formats where supported), rendering the webring component that loads in third-party JavaScript statically, optimizing font files (because there’s a huge fancy font file I load in to use only three characters as background textures), and perhaps addressing the render-blocking single CSS file. 

As my good friend Cassidy Williams says: “Your websites start fast until you add too much to make them slow.”

Watch a video recap

TL;DR: You need to start optimizing for INP today so your sites are not negatively impacted after March 12th.

Why the change?

The FID Core Web Vital was designed to measure how quickly a webpage responds to a user’s first action on that page. A good FID score is achieved at 100ms or less.

However, “Chrome usage data shows that 90% of a user’s time on a page is spent after it loads,” so FID doesn’t capture the full user experience. As a result, INP has been designed to measure a page’s overall perceived responsiveness by observing clicks, taps and key presses across the entire user journey on the page — rather than just the first interaction.

The final INP value is calculated as the longest time observed between the user performing an action and receiving visual feedback. Examples of user interactions include clicking a button to add a product to a cart, clicking an expandable accordion or tapping a collapsed navigation menu, and typing into an input field. INP focuses on the time it takes for visual feedback to be presented after a particular action is performed (i.e. the next paint — where painting is the process in which browsers add pixels to the screen), and it excludes eventual effects of an interaction (such as network requests or UI updates).

Investigating INP in dev tools

Let’s look at how to investigate actions and events that contribute to the INP metric using Chromium-based browsers such as Chrome, Brave, Edge, and Arc.

Choose a web page that accepts one of the following user interactions that INP measures (scrolling and moving the pointer, for example, is not measured):

• Clicking with a mouse

• Tapping on a device with a touchscreen

• Pressing a key on either a physical or onscreen keyboard

I’ve chosen to investigate what happens when I search for “web vitals” on the Sentry Docs home page. Open up the dev tools panel and click on the “Performance” tab.

Depending on the website’s target audience, it’s often useful to throttle the CPU or network speed to analyze the user experience on older machines and/or slower internet. If you want to simulate a slower CPU or network, configure the options accordingly.

Click the record button, and perform some interactions on the page.

Stop recording, and wait for the profile to load. You’ll now see a LOT of data in the form of color-coded blocks with labels in named lanes. The most important lanes to zoom in on when analyzing contributing factors to INP are “Interactions” (any user interactions performed on the page) and “Main” (the browser’s main thread).

For context, the main thread is “where a browser processes user events and paints.” By default, the browser uses the main thread to run all JavaScript on a page, layout the page, recompute any changes, and allocate and free up memory (garbage collection). This means that long-running JavaScript functions can block the main thread, leading to unresponsive pages and a bad user experience. This is what Google is encouraging developers to solve by introducing the INP metric.

When inspecting your recorded performance profile, you may see blocks on the main thread highlighted in red; this indicates a long running task. Hovering over a task gives you the time it took to run, and under that task block, you’ll find all of the separate events and function calls that made up that task. Zoom in/out by scrolling on your mouse or trackpad, and use the scrollbars to the right of the window to scroll up and down the stack.

The summary tab below the lanes shows how much time in each task was allocated to different processes. This will vary between tasks, but usually you’ll observe that “Scripting” (i.e. JavaScript processes) and “Loading” takes the longest time.

Now, let’s cross-reference the main thread activity with the interactions lane. In this example, I typed the term “web vitals” into the search input on the Sentry Docs home page. Under the task blocks on the main thread, you’ll see a number of “Event: keypress” blocks that were captured when I typed each letter. In the interactions lane, there are blocks labeled “Keyboard”, indicating when I typed. Hovering over those blocks tells us that “Long interaction is causing poor performance.”

Also notice the whiskers on either side of the blocks. These indicate that interactions are currently blocked by activity on the main thread, meaning the page might appear unresponsive. As I was typing (with CPU throttling), this unresponsiveness was obvious.

Clicking on a keyboard interaction block allows us to inspect this interaction further. The summary shows us that this interaction had an input delay of 45ms, processing time of 83.1ms, and a presentation delay of 84.638ms. The total time of the interaction took 212.74 ms.

Google states that a good INP score is equal to or less than 200ms, a poor score is greater than 500ms, and a score that needs improvement is between 200 and 500ms. Based on these benchmarks, our scores need improvement.

To understand which processes are taking the longest inside each task, select a task block, and click on the “Bottom-Up” tab below. This shows which activities directly took up the most time in total. Click the “Total Time” column header to sort by time ascending or descending.

Expand each event to see the full list of subsequent events and their respective execution times. Comparing this detailed list to what you thought should be happening can help you identify any anomalies.

Improving INP for your websites and apps

Now that you’re familiar with how to investigate blocking processes by cross-referencing interactions with main thread activity in development, how do you fix issues that cause bad INP scores? As usual, it depends. But here are some questions to ask yourself if you discover unexpected long-running tasks on your web pages that could affect your INP score:

• Are you providing timely visual feedback? Does the next paint happen within 200ms?

• Is something running when you didn’t expect it to? Can you remove that process?

• Do you really need to process each user interaction individually, or can you restrict function calls via debouncing?

• Could you extract the resulting function calls from the main thread and move them to a web worker?

There are also some more experimental ways to improve the perceived responsiveness of your pages, but proceed with caution because they may not be supported on all browsers.

navigator.scheduling.isInputPending()

With support for Chromium browsers only, isInputPending() allows you to check whether there are pending input events in the event queue, indicating that the user is attempting to interact with the page.

This could be useful in situations where you have a queue of tasks to run (such as calls to an API on each keypress), and you want to give control back to the main thread regularly to allow the page to respond to further user interaction. At the time of writing, there are no published plans to make this API available in any other browser engines.

scheduler.yield

Another experimental feature from the Chrome Team is scheduler.yield, which expands the scheduler API to make yielding control back to the main thread “easier and better” than previously used methods such as manually deferring code execution with setTimeout().

Both new APIs offer some good reading opportunities to understand how JavaScript in the browser actually works, but ultimately, without support for all browsers, it’s not something you should rush to adopt just yet.

A cross-browser JavaScript task scheduler

During my research for this post, I discovered main-thread-scheduling, a JavaScript task scheduler developed by Antonio Stoilkov that focuses on helping you improve perceived page performance, and therefore, your INP scores. It uses isInputPending() if available, but provides scheduling functionality for all browsers. Personally, I haven’t had a use case to test this just yet, but at first glance, it’s currently maintained and could be worth a try.

The bottom line

By introducing the new INP Core Web Vital to replace FID, developers are encouraged to prioritize minimizing delays in visual feedback across the entire user journey. This can reassure users that a page is responding to their actions, which, in theory, should reduce friction and bounce rates, improving the overall web experience.

The bottom line? As developers building for the web, even if we don’t always have complete control of how long it takes to fetch data and make calls to API services on the front-end, in order to achieve a good INP score, we need to make our pages feel fast, all the time.

A lot of people have asked me about my writing workflow. So here it is, including all the tools, apps and other things I use that help me produce written content. Contrary to what seems to be the norm right now, I do not use any AI tools in my workflow. I like writing directly from my brain.

0. Select topic

I manage my non-work and work-adjacent tasks in Notion. Whenever I have an idea, regardless of how big or small or silly or achievable it is, I'll add it to Notion, and use labels to categorise it by type of output (e.g. blog, silly project, website update). Today I wanted to write a short post for my site. I clicked on the filtered blog post view, and selected this one (because I hoped it would be a quick one!).

1. Draft in Notion

I write a full draft in Notion which includes collecting images, screenshots and code samples where required. Depending on the type of post, this could take some time; I might need to build an example project or do some further in-depth research. This post, though, was a case of just writing things I already knew.

Compared to writing directly in my CMS, using Notion makes it easier to add and edit content when the inspiration hits using mobile devices. It's also easier to do the next step.

2. Use a text-to-speech reader to make it make sense

This part is really important to me as it helps me keep my writing clear and straightforward. Currently I'm using the Read Aloud Chromium browser extension to read out my drafts to assess for spelling, grammar, and comprehension. Doing this also helps me separate myself from the words from my brain, and experience the post as a reader rather than a writer. I've tried a number of text-to-speech tools; some are better than others. Read Aloud isn't the best, but it's free, and works most of the time.

3. Add content to CMS

Next, I’ll copy and paste the draft text to my CMS. I’ve been using Contentful since working there in 2021. I use Rich Text rather than Markdown for my posts and what’s great about this is that copying and pasting from Notion preserves hyperlinks and formatting. If I’m including anything else like code samples, images and other embedded media, I add those as separate linked entries manually whilst working through the blog post.

4. Preview the post in the wild

In 2022 I built a custom Contentful app to build draft content to a preview branch of my static site. The app adds a button to my Contentful UI that when clicked, POSTs to a webhook that builds a specific branch of my site. Read about how I built it here: Build a CMS preview workflow for your Jamstack site.

5. Edit if necessary

Previewing content “in situ” helps me find potential formatting issues such as incorrect heading levels or weird spacing in code samples, and also encourages me, again, to experience the content as a reader, rather than a writer. At this point, I may make some slight edits to the wording. I’ll usually rebuild the preview a few times until I’m completely happy.

6. Publish

Then I hit the publish button.

7. Cross-post manually to DEV

I publish each post on my website to DEV and reference the original content with a canonical link. This step is a little painful because DEV posts are written in markdown, and as mentioned above, my posts are not. For a time I experimented with auto-importing blog posts to DEV via my RSS feed, but there are a few posts in my feed that I don’t want to post on DEV, and there was no option to hide them. This meant that I had old posts hanging around in my DEV drafts, and it felt messy.

If I really wanted, I could automate part of this step using a package that converts Contentful Rich Text to markdown. But doing this final step manually allows me to check for spelling, grammar and comprehension a third time. And yes, sometimes I’ll make edits to the post at this point and republish the changes on my site. I’m more of a perfectionist than I’d like to admit.

Jamstack in 2022

In 2022 I wrote What is Jamstack?, mainly as a way to refocus a very broad landscape influenced by Big Tech™️ shifting and changing the definition of the technology to suit its capitalistic needs. If you’re unfamiliar with the term, I would urge you to read that post before continuing with this one for some historical context.

The TL;DR of the 2022 post is this.

Jamstack projects have the following characteristics:

• Ready-to-serve assets

• Any interactivity provided without a managed server

• Any interactivity provided by some combination of JavaScript and decoupled services via APIs

Full disclaimer: I was an employee of Netlify at the time. And what’s interesting is that whilst my definition aligns mostly with the conclusions of this week’s panel discussion — the introduction of the phrase “decoupled services” was highly influenced by Netlify’s evolving business model as it started to pivot its marketing efforts towards larger enterprise businesses with more money to spend. I feel like I should apologise for this blatant insertion of business jargon, but I guess I was just doing my job. Let’s fast forward to 2023.

Jamstack as we knew it died in July 2023

Netlify published a new definition of the Jamstack in 2023, introducing yet more Big Business™️ words to describe it: “flexibility, scalability, performance, and maintainability”; “Composable architecture”. Whilst Jamstack started out as a developer community centred on building pre-rendered and portable sites, it was now a marketing term pointed directly at CTOs and technical buyers re-positioned to sell Netlify services.

This message was broadcast loud and clear when “Netlify officially killed The Jamstack Community Discord”, as described by Brian Rinaldi in Is Jamstack officially finished? Not many of you will know this, but as an employee of Netlify at the time, I posted that announcement in the Jamstack Discord; after all, I was still just doing my job.

In the panel, Cassidy summed all of this up perfectly:

If I might just shout at capitalism. I think we pulled in a whole lot of things [into the Jamstack definition] saying, “Yes that counts, yes that counts,” for the shareholders, because if it counts then that means it can be hosted on this thing.

Jamstack is actually, like, really really alive

Historically when I’ve taken part in live-streamed panels, attendance and engagement with the speakers is usually low. Surprisingly, or maybe not-so, this week’s live panel was buzzing with discussion, activity and engagement. There’s a huge group of people who believe in Jamstack and want to be part of it — again.

On a personal level, the whole experience made me realise that for the last year I’ve been lacking something deeply: a technical community home on the internet where people like to build websites like I do; a group of people who share my excitement for building portable, static websites; somewhere I don’t feel like such a nerdy outsider because I’m not religiously promoting the latest experimental breaking Next.js change or encouraging everyone to server-side render their whole entire portfolio of purely content-based landing pages for their new AI startups.

In a 2023 post titled The Tension and Future of Jamstack, Zach Leatherman lays out a bunch of evidence that “Netlify has moved on from shepherding the Jamstack […] — which is fine! (and maybe preferable?).” And I agree. Whilst it may be a little trickier to fund Jamstack community endeavours without the support of a Silicon Valley tech startup, removing the capitalistic element from Jamstack is ultimately what needs to happen in order to preserve its integrity and secure its future.

Down with capitalism. - Mike Neumegen

Watch the full panel discussion

Until we find a new home on the internet for the Jamstack community to come together, we’re planning some more live events, and Mike has been building up a library of excellent discussions with prominent community members over on thefutureofjamstack.org.

I’d like to extend a huge, huge thanks to Mike for organising the first “What’s next for Jamstack” panel and for giving us a platform to revive the Jamstack values, principals and community. I’m excited for what’s to come.

It was quite inconsequential (I think), and I only found it when I (finally) added Sentry error monitoring to the stack (yay!). But it got me thinking about some of the things we’re starting to take for granted in the web framework world — and how we might get tripped up as a result.

SyntaxError: Identifier 'button' has already been declared

My website is built with Eleventy. I’m using the Eleventy JavaScript template language and this is mainly because I moved over from Next.js and wanted to retain much of the React-based component patterns I was used to at the time.

In my header component, which is an HTML file added as an “include” on my base layout using Liquid syntax, there’s a block of inline JavaScript that powers the dark and light theme toggle, selecting the toggle button and assigning it to the variable name button.