Full-stack TypeScript engineer in Brighton, England, specialising in performance. I write about TypeScript, testing and building for the modern web.
Vite 8 replaced Rollup and esbuild with Rolldown, a Rust bundler, and the announcement promises builds 10-30x faster. I forced it into this site and measured properly. The bundling step got 3.2x faster. The build got 0.7 seconds faster. The gap between those two numbers is the useful part.
Design systems are sold on consistency and developer experience, and they deliver both. What rarely makes it onto the slide is that a design system is also the most duplicated dependency in your company: every page of every product pays for its architectural choices. I've spent a lot of time profiling apps where the biggest performance problem wasn't the app at all - it was the system underneath it.
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in 2024, and it's a much harder metric to game. I've spent a fair amount of time recently digging slow interactions out of production apps. This post covers how I find them and the fixes that actually work.
Writing end-to-end tests has never been the hard part. Keeping them alive is. Playwright now ships three test agents, a planner, a generator and a healer, that take on a surprising amount of that work. I've been trying them out and this post covers how they fit together.
This site has been running on the same Jekyll and webpack setup since 2018. It's been dormant for the last few years. I've rebuilt it with Astro and this post covers that move.
We utilise visual regression tests in our pipelines to give us confidence that the code we’re about to ship hasn’t unexpectedly changed anything visually. We achieve this by using Playwright’s screenshot functionality to capture the page and upload it to [Percy](https://percy.io/). We opted for Percy instead of Playwright’s built in [visual comparisons](https://playwright.dev/docs/test-snapshots) because we like having a simple and intuitive UI to review the difference. If there’s a difference between the screenshot on `main` and our proposed changes, we get a view like this which we can review and approve if we’re happy:
The business-to-business side of Houseful is composed of multiple domain teams who have ownership over particular areas of our core product, Alto. I work on one of these teams and we had a new project which was to build a developer portal to help other companies be able to integrate with our APIs. Typically, our team would have followed a two-week sprint cycle to achieve this quarterly objective. However, for this particular project, we decided to experiment with a new way of working called the Shape Up method.
On the business-to-business side of Zoopla we have a SaaS (Software as a Service) product called Alto which is a sales and lettings CRM for estate agents. The product comprises of multiple applications, each a [microfrontend](https://micro-frontends.org/). Each microfrontend uses [Playwright](https://playwright.dev/) for its automated browser based tests. These tests include:
When writing tests with React Testing Library, developers often run into the 'React state updates should be wrapped into act' warning.
I've been working with error boundaries in React. Here's how to effectively test thrown errors by components wrapped in an error boundary using Vitest and React Testing Library.
I was recently writing unit tests for a project and I wanted to test whether a function in one class had been called by a parent class. Sounds simple right? I found it a bit trickier than anticipated so wanted to share my learnings.
A friend of mine introduced me to Svelte and the approach impressed me. Instead of doing a lot of work in the browser inside a virtual DOM (like a lot of frameworks), Svelte is a compiler step, meaning the code is compiled to efficient vanilla JavaScript when the project is built. It results in a considerably lighter load whilst also being able to leverage useful functionality such as reactivity which might be why you're choosing to use a framework in the first place. I combined this with Sapper - since retired in favour of SvelteKit - to get a lightweight, statically generated application out of the box.
I came across a community group who had been managing a Google sheet to detail data about which local businesses were delivering during the Coronavirus crisis. I used this sheet as a backend for an API I built using Lambda and API Gateway.
I'm a big fan of Vue.js and Pinia for state management. Combine this with Nuxt and you can generate a static version of your Vue application and give your users a speedy site served from HTML files. I cover this and how you might approach making the content of your static site dynamic using Netlify build hooks and Contentful as a CMS.
One of things that irks me about the usability of shopping online is the inconsistent checkout experience between different merchants. Do I really need to enter the same delivery/billing address, card number, CVC code etc. into every websites specific form? Payment Request API to the rescue.
Advancing my knowledge around the topic of accessibility has been something I've been doing a lot recently. With this knowledge came the realisation that previous web applications I'd worked on could do with some improvements in this field. There are a few quick wins which could fundamentally improve the accessibility of your web application post-build.
I was asked recently how debouncing works in JavaScript. I knew why I should use it, what it did and that the helper function I'd been using was short and easy to read through. However I didn't grasp what was going on 'under the hood'.