DEV Community: Danny Holloran

Async Svelte: Using await Directly in Your Components

Danny Holloran — Mon, 31 Aug 2026 08:05:37 +0000

Every Svelte codebase eventually grows a little pile of scaffolding around asynchronous data. A let data = $state(null), an $effect that fetches and assigns, a loading flag, an error flag, and a {#if loading} in the template. Or the {#await} block, which is fine for one promise but nests badly the moment you need two. Either way, you end up writing plumbing rather than describing your UI.

Since Svelte 5.36, you can skip most of that. The await keyword works in three places it previously did not: at the top level of a component's <script>, inside $derived(...), and directly in your markup. It is still behind an experimental flag, but the design is worth understanding now because it changes how you think about loading states.

Turning it on, and what changes

Async Svelte is opt-in. Add experimental.async wherever you configure the compiler, which usually means svelte.config.js:

export default {
  compilerOptions: {
    experimental: {
      async: true,
    },
  },
};

The docs say this flag disappears in Svelte 6, so today's opt-in is tomorrow's default. Once it is on, this is legal:

<script>
  let a = $state(1);
  let b = $state(2);

  async function add(a, b) {
    await new Promise((f) => setTimeout(f, 500));
    return a + b;
  }
</script>

<input type="number" bind:value={a} />
<input type="number" bind:value={b} />

<p>{a} + {b} = {await add(a, b)}</p>

The interesting part is what does not happen. Bump a to 2 and the paragraph does not flash 2 + 2 = 3 while the promise is in flight. Svelte holds the whole update until add(a, b) resolves, then swaps everything at once. That is the headline feature: synchronized updates. You never render a torn UI where half the values are new and half are stale, which is exactly the bug that loading flags exist to paper over.

Updates can also overlap. A fast update lands while a slower earlier one is still running, so a quick keystroke is not stuck behind a slow one.

Concurrency is automatic, waterfalls are not

Two independent await expressions in markup run in parallel, even though they read as sequential:

<p>{await one(x)}</p>
<p>{await two(y)}</p>

Both kick off immediately. The same is not true inside your <script>, where await behaves like ordinary JavaScript and runs top to bottom. Svelte will warn you about this with an await_waterfall warning when you write something like:

let a = $derived(await one(x));
let b = $derived(await two(y));

Here b is not created until a resolves. Once both exist they update independently, but that first pass is a waterfall. If you have seen the same class of bug in a React useEffect chain, this is the familiar shape with a compiler warning attached.

Loading states move into boundaries

With no loading variable to hang a spinner on, placeholder UI moves to <svelte:boundary> and its pending snippet:

<svelte:boundary>
  <p>{await delayed('hello!')}</p>

  {#snippet pending()}
    <p>loading...</p>
  {/snippet}
</svelte:boundary>

The pending snippet shows when the boundary is first created and stays until every await inside it resolves. It deliberately does not reappear for later updates, since those are globally coordinated and rendering a full-page skeleton on every keystroke would be worse than useless.

For subsequent async work, $effect.pending() tells you how many promises are outstanding in the current boundary, not counting child boundaries. That is what you reach for when you want a small "validating..." spinner next to a form field rather than blanking the section. There is also settled(), a promise that resolves once state changes and their async consequences have been flushed to the DOM.

Errors get the same treatment. Anything thrown inside an await expression bubbles to the nearest boundary, where a failed snippet receives the error and a reset function. Worth remembering: boundaries catch errors during rendering and effects, not errors from event handlers or a stray setTimeout.

The parts still in motion

This is experimental, and the docs are direct about it: the details of await handling and $effect.pending() can change outside a semver major. Effect ordering already shifts when the flag is on, with block effects like {#if} and {#each} running before $effect.pre in the same component.

Server rendering works through an awaited render(...), though frameworks handle that for you. Today a boundary with a pending snippet renders that snippet during SSR and skips its contents, with streaming planned but not shipped. Svelte 5.42 also added fork(...), which speculatively runs async work you expect to need soon, and SvelteKit is the intended consumer for preloading on hover or focus.

If you maintain a Svelte app, the useful move right now is not a rewrite. Turn the flag on in a branch, pick one component with the most loading and error bookkeeping, and see how much of it disappears. The await expressions docs and the <svelte:boundary> reference are short enough to read in one sitting.

The Web Locks API: One Tab Does the Work, the Rest Wait

Danny Holloran — Sat, 29 Aug 2026 08:06:30 +0000

A user opens your dashboard, then opens it again in a second tab, then leaves a third one parked on another monitor from yesterday. Their access token expires. All three tabs notice at roughly the same instant, and all three fire a refresh request against your auth endpoint. Two of them get back a rotated refresh token that the third has already invalidated, and now the user is staring at a login screen they did nothing to deserve.

The usual fix is a pile of localStorage flags with timestamps, a BroadcastChannel message, and a comment that says // TODO: this is racy. It is racy. localStorage has no atomic compare-and-set, so two tabs can read "no refresh in progress" in the same tick and both write "refresh in progress." What you actually want is a mutex, and the browser has shipped one since March 2022. It is called the Web Locks API, it is Baseline Widely available, and almost nobody reaches for it.

navigator.locks.request is the whole API

There is one method that matters. You give it a name, a callback, and the browser guarantees that no other code on the same origin — any tab, any iframe, any worker — runs inside a lock with that name at the same time.

await navigator.locks.request("token-refresh", async () => {
  const stored = readToken();
  if (!isExpired(stored)) return stored; // someone else already did it

  const fresh = await fetch("/auth/refresh", { method: "POST" }).then((r) =>
    r.json(),
  );
  writeToken(fresh);
  return fresh;
});

The lock is held for exactly as long as the callback's promise is pending, and it is released when the callback returns or throws. There is no unlock() to forget, and there is no leaked lock if your fetch rejects. That alone makes it safer than any flag-in-storage scheme you would write by hand.

The re-check inside the callback is the part people skip. Three tabs queue on 'token-refresh'. The first one does the network round trip. The second and third get the lock afterward, see a token that is no longer expired, and return immediately. One request, three happy tabs.

Shared locks, and not waiting at all

request() takes an options object, and two of the options carry most of the value.

mode: 'shared' gives you the readers-writer pattern. Any number of shared holders can hold the same name at once, but an exclusive holder blocks all of them. This is the same semantics IndexedDB uses for readonly versus readwrite transactions, and it is the right shape when many tabs read a cached dataset while one occasionally rewrites it.

// Many of these can run concurrently.
navigator.locks.request("catalog", { mode: "shared" }, async () => {
  return readCatalogFromIDB();
});

// This one waits for every reader to finish, then blocks new ones.
navigator.locks.request("catalog", { mode: "exclusive" }, async () => {
  await rewriteCatalogFromIDB(await fetchCatalog());
});

ifAvailable: true flips the behavior from "wait your turn" to "tell me no." The callback still runs, but it receives null instead of a Lock when the lock was already held. That is the leader-election primitive: whichever tab gets the lock becomes the one that owns the WebSocket, or the polling interval, or the background sync, and the others quietly stand down.

navigator.locks.request("sync-leader", { ifAvailable: true }, async (lock) => {
  if (!lock) return; // another tab is the leader

  await new Promise(() => {}); // hold it for the lifetime of this tab
});

That never-resolving promise looks alarming and is actually the idiom. The lock is held until the tab closes or navigates, at which point the browser releases it and a queued tab is promoted automatically. You get failover for free.

There is also signal, which takes an AbortSignal so you can give up after 200ms instead of queueing forever, and steal: true, which forcibly releases whoever holds the lock. Treat steal as a recovery tool for a wedged tab, not a normal control flow — the stolen-from code keeps running and has no idea it lost the lock. Note that signal cannot be combined with steal or ifAvailable; the request rejects with a NotSupportedError if you try.

The edges worth knowing

Locks are scoped per origin and require a secure context, so https:// or localhost only. They do not survive a reload — every lock a document holds is released when that document goes away, which is the behavior you want but also means a lock is never a durable record of anything. Store the actual state in IndexedDB and use the lock only to serialize who writes it.

Deadlock is still your problem. If tab A holds a and waits on b while tab B does the reverse, they both wait forever. Acquire locks in a consistent order, keep the critical section short, and avoid nesting request() calls when you can flatten them.

For debugging, navigator.locks.query() returns { held, pending } arrays with the name, mode, and a clientId for each. Logging that when something feels stuck is usually faster than reasoning about it.

If your app has any of the classic multi-tab bugs — duplicated token refreshes, four WebSockets where you wanted one, an IndexedDB migration that runs twice — this is a smaller fix than the workaround you are currently maintaining. MDN's LockManager reference covers every option in a page you can read in five minutes.

Form-Associated Custom Elements: Web Components That Belong in a Form

Danny Holloran — Sat, 29 Aug 2026 08:06:24 +0000

Custom elements have been shippable for years, but the illusion falls apart the moment you drop one inside a <form>. The value never shows up in FormData. required does nothing. Hitting reset leaves your control sitting there with stale state, and the browser's validation bubble refuses to point at it. So most of us reach for the same workaround: render a hidden <input> inside the component and keep it in sync by hand, forever.

That workaround has been unnecessary for a while now. Form-associated custom elements are Baseline — Chromium, Firefox, and Safari 16.4 and up — and they let a component participate in a form as a first-class control instead of a decoration sitting next to one.

Two lines make it a form control

The whole thing hinges on a static property and one method call:

class RatingInput extends HTMLElement {
  static formAssociated = true;

  #internals;
  #value = "";

  constructor() {
    super();
    this.#internals = this.attachInternals();
    this.attachShadow({ mode: "open" });
  }

  connectedCallback() {
    this.shadowRoot.innerHTML = `
      <div role="radiogroup" aria-label="Rating">
        ${[1, 2, 3, 4, 5]
          .map(
            (n) =>
              `<button part="star" type="button" value="${n}">&#9733;</button>`,
          )
          .join("")}
      </div>
    `;
    this.shadowRoot.addEventListener("click", (e) => {
      if (e.target.matches("button")) this.value = e.target.value;
    });
  }

  get value() {
    return this.#value;
  }

  set value(v) {
    this.#value = String(v);
    this.#internals.setFormValue(this.#value);
  }
}

customElements.define("rating-input", RatingInput);

static formAssociated = true tells the browser to treat the element like a form control: it gets picked up by the owning form, it inherits name, and it becomes eligible for validation. attachInternals() hands back an ElementInternals object, which is the private channel your component uses to talk to the form. Guard it — anything you can do through internals is something you probably do not want page scripts doing on your behalf, which is why it lives in a private field.

setFormValue() is the part that ends the hidden-input era. Pass it a string, a File, or a whole FormData object when one control needs to contribute several named values, and it lands in the submission:

<form id="review">
  <rating-input name="score" required></rating-input>
  <button>Submit</button>
</form>

new FormData(document.getElementById("review")).get("score"); // "4"

The lifecycle you get for free

Being form-associated also opts you into callbacks the browser fires at the right moments, so you stop wiring up listeners for things the platform already knows:

formResetCallback() {
  this.value = '';
}

formDisabledCallback(disabled) {
  this.toggleAttribute('inert', disabled);
}

formStateRestoreCallback(state) {
  this.value = state;
}

formResetCallback runs on form.reset(). formDisabledCallback fires when the element or its enclosing <fieldset> gets disabled, which is the case almost everyone forgets. formStateRestoreCallback is the one that quietly wins arguments in code review: it restores state on back-navigation and session restore, using the optional second argument to setFormValue(value, state). If your control's submission value differs from what the user actually typed — a formatted currency field, say — pass the raw input as that second argument and you get real state restoration instead of an empty box.

Validation the browser actually understands

setValidity() is where custom controls finally stop being second-class:

#validate() {
  const empty = this.hasAttribute('required') && !this.#value;

  this.#internals.setValidity(
    empty ? { valueMissing: true } : {},
    empty ? 'Please choose a rating.' : '',
    this.shadowRoot.querySelector('button'),
  );
}

The first argument is a ValidityStateFlags dictionary using the same flag names as native inputs (valueMissing, rangeUnderflow, customError, and so on). The second is the message. The third — the anchor — is the one people skip and then wonder why nothing appears: it is the element the browser points its validation bubble at. Without an anchor inside your shadow root, Chromium has nowhere to render the message and silently gives up.

Get this right and form.reportValidity(), implicit submit blocking, and the :invalid pseudo-class all work against your component exactly as they do against <input required>.

Styling states without attribute soup

The same ElementInternals object carries a states set, so internal state no longer has to leak out as a reflected attribute:

this.#internals.states.add("rated");
this.#internals.states.delete("rated");

rating-input:state(rated)::part(star) {
  color: gold;
}

:state() has been Baseline since 2024 and composes with :host() and ::part(), which means consumers can style your component's states without you publishing a contract of magic class names.

None of this is new enough to be risky anymore, and it collapses a surprising amount of glue code. Next time you are about to add a hidden input to a component, open the ElementInternals docs on MDN instead and delete it before it exists.

Next.js Partial Prefetching: One Shell Per Route, Not One Per Link

Danny Holloran — Mon, 24 Aug 2026 08:06:05 +0000

Open the Network tab on a production Next.js app and scroll a page with a long list of links. You get a waterfall of prefetch requests, one per link, most of them hitting the same route with different params. A sidebar with twenty chat threads fires twenty requests to render twenty variations of the same /chat/[id] page. The Next.js team's own writeup calls this "ridiculous," which is refreshingly blunt for a framework changelog.

Next.js 16.3 replaces that model. Instead of prefetching a page per link, it prefetches a reusable shell per route and caches it on the client for the session. Vercel calls this Partial Prefetching, and it ships as part of a bundle of opt-in behaviors called Instant Navigations.

Two gaps, two different fixes

A navigation feels slow for two independent reasons. The client has to talk to the server, which costs a network roundtrip. And the server has to actually generate a response, which costs however long your data layer takes.

Server Components fixed a lot of things but made this worse in one specific way: click a link, nothing happens, then the whole page appears. That's the server-generation gap. Under Cache Components, Next.js now forces you to make an explicit choice for every route that awaits data. Stream it with <Suspense> so the user sees a loading state immediately. Cache it with 'use cache' so the user sees previously rendered UI immediately. Or deliberately opt out:

// app/posts/[slug]/page.tsx
export const instant = false;

That last one is a real option, not a failure state. A blog post route may genuinely be better off blocking than flashing a skeleton for 80ms. Marking it instant = false tells the framework you meant it, and the dev-mode warning goes away.

Partial Prefetching handles the other gap: the network hop. If the shell for /chat/[id] is already sitting in the client cache before you click, there is no roundtrip at click time at all.

Turning it on

Both behaviors are gated behind config flags in 16.3, and both are slated to become defaults in a future major:

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

cacheComponents is the prerequisite. It's the flag that turns on the 'use cache' model and, with it, the dynamic-by-default behavior with no implicit caching. If you're upgrading an existing app, expect this to surface routes you didn't know were blocking. That's the point. The new Instant Insights panel in DevTools lists every navigation that isn't instant, so you work a queue instead of guessing.

There's also a Navigation Inspector that pauses a navigation at the shell so you can see exactly what a user would see mid-load. This matters more than it sounds, because prefetching is disabled in development, which historically made loading states nearly impossible to eyeball.

Prefetching more than the shell

The shell is the new baseline, and it is deliberately small. Sometimes that's not enough. If you want a chat header or a product title to pop in instantly rather than stream, opt that specific link into deeper prefetching:

<Link href={`/chat/${id}`} prefetch={true}>
  {thread.title}
</Link>

Even then, Next.js won't try to render the whole route. It renders down to whatever is available synchronously, derivable from the URL params or search params, or marked 'use cache'. So prefetch={true} is no longer the all-or-nothing hammer it used to be. Pair it with 'use cache' on the components you want warm, and you get a graded response instead of a binary one.

Keeping it from rotting

The failure mode here is subtle. A route navigates instantly today. Six weeks from now someone adds a cookies() read to a shared header, the route de-opts to request-time rendering, and the instant UI quietly disappears. Nothing errors. Nothing fails CI.

16.3 ships an instant() Playwright helper that asserts what must be visible without waiting on the network:

import { expect, test } from "@playwright/test";
import { instant } from "@next/playwright";

test("product title is available immediately", async ({ page }) => {
  await page.goto("/products/shoes");

  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator("h1")).toContainText("Baseball Cap");
    await expect(page.getByText("Checking inventory...")).toBeVisible();
  });

  await expect(page.getByText("12 in stock")).toBeVisible();
});

Write one of these for the two or three navigations users actually notice and you've turned a perception problem into a test failure.

Worth trying now

If you're already on 16.x, npm install next@latest gets you the non-flagged wins for free: up to 90% less dev-server memory, cached repeat builds, and roughly 22% more requests handled under load from swapping web streams for native Node streams. None of that requires touching your code.

The flags are the bigger commitment. Turn on cacheComponents in a branch, let Instant Insights tell you which routes are blocking, and decide per route whether you want to stream, cache, or block. The answer won't be the same for all of them, and that's the improvement.

Declarative Partial Updates: Out-of-Order HTML Streaming Without a Framework

Danny Holloran — Sat, 22 Aug 2026 08:06:02 +0000

HTML has one stubborn rule that has quietly shaped a decade of frontend architecture: it renders in the order it arrives. If the third section of your page needs a slow database query, everything after it waits. The usual escape hatches are all compromises. You buffer the whole response and give up streaming entirely, you reorder with CSS and break the accessibility tree, or you ship a framework whose main job is turning that server delay into a client-side spinner.

Chrome 148 has an experimental answer that skips all three. Under the umbrella name Declarative Partial Updates, two related APIs let the server send a placeholder now and fill it in later, and let JavaScript stream markup into an element instead of waiting for the full string. They are behind chrome://flags/#enable-experimental-web-platform-features today, with polyfills on npm and positive noises from other vendors.

Placeholders you fill in later

The declarative half revives something HTML has ignored for its entire life: processing instructions. In XML they carry metadata; in HTML they have always been parsed as comments and thrown away. The new API gives them a job.

<div><?marker name="user-panel"></div>

<!-- ...the rest of the page streams... -->

<template for="user-panel"> Welcome back, <strong>Dan</strong>. </template>

When the parser reaches <template for="user-panel">, it finds the matching <?marker> and swaps its own content in. The DOM you end up with contains no marker and no template, just the paragraph. The server never had to hold back the rest of the document while it waited on that user lookup.

There is a range form too, which is the one you will reach for most, because it gives you a loading state for free:

<ul id="results">
  <?start name="results">
  <li class="skeleton">Loading…</li>
  <?end>
</ul>

Everything between <?start> and <?end> renders immediately and gets replaced when the template shows up. Better still, a template can re-emit a marker, which turns this into an append loop. Stream one <template for="results"> per row as your query yields them, each ending with <?marker name="results">, and the list grows in place. No appendChild, no framework, no client-side JavaScript at all.

The scoping rule is the important restriction: a <template for> can only patch markers inside its own parent element. That is deliberate, and it means a template dropped into <body> has reach over the entire document including <head>. Worth knowing before you generate one from user input.

The JavaScript side got a rewrite too

The second half addresses a mess most of us have stopped noticing. Ask yourself, honestly, which of innerHTML, setHTML, setHTMLUnsafe, insertAdjacentHTML, and createContextualFragment sanitize their input, which run <script> tags, and which respect Trusted Types. Nobody remembers, because the answers were never consistent.

The proposal replaces that with a grid you can actually reason about. Six positions, each with a static and a streaming form:

Action	Static	Streaming
Replace contents	`setHTML()`	`streamHTML()`
Replace the element itself	`replaceWithHTML()`	`streamReplaceWithHTML()`
Insert as first child	`prependHTML()`	`streamPrependHTML()`
Insert as last child	`appendHTML()`	`streamAppendHTML()`
Insert before / after	`beforeHTML()` / `afterHTML()`	`streamBeforeHTML()` / `streamAfterHTML()`

Every one has an Unsafe twin. The naming is the whole point: the plain versions sanitize by default, the Unsafe versions do not and additionally accept runScripts: true if you actually want scripts to execute. The word "unsafe" is a speed bump, not a prohibition.

The streaming versions are the genuinely new capability. They return a WritableStream, so a fetch response can go straight into the DOM as it arrives:

const el = document.querySelector("#content");
const response = await fetch("/api/content.html");

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(el.streamHTMLUnsafe());

That is the thing SPAs have never been able to do. Initial page loads have always streamed; every client-side route change since has thrown that away and waited for a complete payload before touching the DOM.

Where this actually goes

The two halves compose, and that is where it gets interesting. Because streamHTMLUnsafe() behaves like the main parser, it processes <template for> instructions as they land. So a client-side route change can be an outline page full of markers plus a stream of templates slotting into them, with no per-element querySelector bookkeeping. That is a surprising amount of a component framework, expressed in markup.

Temper expectations on timing. This is one engine, behind a flag, and the sanitizer that setHTML depends on is still missing in Safari. The two polyfills (template-for-polyfill and html-setters-polyfill) are worth a spike, but read the fine print: the setters polyfill buffers rather than streams, so it gives you the API shape without the performance win. Treat it as a preview of where the platform is heading, not something to put in front of users this quarter.

Sources: Declarative partial updates (Chrome for Developers) and the WICG explainer.

React's Activity Component: Hide UI Without Losing Its State

Danny Holloran — Tue, 18 Aug 2026 08:05:29 +0000

A user types half a message into the compose tab, flips over to the settings tab to change a
notification preference, flips back, and the draft is gone. You know exactly why: {tab === 'compose' && <Compose />} unmounted the subtree, and unmounting throws away state.

The usual fixes are all a little sad. Lift the state up and thread it back down through props.
Park it in a store that exists only to survive an unmount. Or render everything at once behind a
display: none class and eat the mount cost of every panel on first paint. React 19.2 added a
first-class answer instead: <Activity>.

Two modes and a boundary

Activity is a component you import from react directly. It takes a mode prop that is either
visible or hidden, and it wraps the subtree you want to keep alive.

import { Activity } from "react";

function Workspace({ tab }) {
  return (
    <>
      <Activity mode={tab === "compose" ? "visible" : "hidden"}>
        <Compose />
      </Activity>
      <Activity mode={tab === "settings" ? "visible" : "hidden"}>
        <Settings />
      </Activity>
    </>
  );
}

When a boundary goes hidden, React hides its children with display: none rather than removing
them. Every useState and useReducer value in the subtree is preserved, and so is the DOM state
that React normally has no opinion about: scroll offsets, uncontrolled input values, the current
playback position of a <video>. Flip back to visible and the panel is exactly where the user
left it, with no restoration logic on your side.

Hidden does not mean paused

This is the part that trips people up, so it's worth being blunt about it: hiding an Activity
runs your cleanup functions. Every useEffect and useLayoutEffect cleanup in the subtree fires,
exactly as if the component had unmounted. Sockets close, intervals clear, observers disconnect.
When the boundary becomes visible again, the setup functions run again.

That is the behavior you want most of the time. A hidden panel holding an open WebSocket is a
resource leak with extra steps.

function LivePrices({ symbol }) {
  const [quotes, setQuotes] = useState({});

  useEffect(() => {
    const socket = new WebSocket(`wss://example.com/quotes/${symbol}`);
    socket.onmessage = (e) => setQuotes(JSON.parse(e.data));
    return () => socket.close();
  }, [symbol]);

  return <QuoteTable rows={quotes} />;
}

Wrapped in a hidden Activity, the socket closes but quotes survives. Come back and the table
paints immediately with the last known numbers, then updates as fresh messages arrive. The user
sees stale-but-plausible data instead of a spinner. The practical requirement is that your Effects
have to tolerate running more than once, which is the same discipline StrictMode's double-invoke
has been enforcing in development for years.

Pre-rendering what nobody has clicked yet

Hidden boundaries are not inert. React still renders them, at the lowest priority it has. That
turns Activity into a way to warm up a route before the user asks for it.

<Activity mode={route === "/reports" ? "visible" : "hidden"}>
  <ReportsPage />
</Activity>

The reports page mounts, its data fetches start, its component tree gets built, all in the gaps
between higher-priority work. Navigation then feels instant because most of the work already
happened.

The catch: lowest priority is the only priority you get. There is no knob for tuning it, and if
the hidden subtree is genuinely expensive it still competes for the same main thread as everything
visible. Activity reorders work; it does not make it free. React 19.2's DevTools Performance
Tracks are the right place to check whether a background boundary is actually paying for itself.

The other cost is DOM weight. Hidden children remain in the document, so twenty hidden panels are
twenty panels' worth of nodes that the browser still has to keep in memory and account for in style
recalculation. Activity is aimed at a handful of heavy, stateful regions, such as tab groups,
wizard steps, and a route you're fairly confident is next. It is not a blanket replacement for
conditional rendering, and a list of a thousand rows should still unmount.

What it retires

If you've written a useRef cache to stash a component's scroll position, or added a slice to
Zustand whose only job was surviving an unmount, or hand-rolled a hidden class plus a pile of
if (!visible) return guards inside your Effects, that's the pattern Activity collapses into one
boundary.

It shipped stable in React 19.2, so there's no canary flag to opt into. Pick the tab group in your
app that annoys you most, wrap each panel, and delete the state-preservation scaffolding you built
around it. The official reference covers the
remaining edge cases, including how it interacts with Suspense.

revalidateTag vs updateTag: Next.js Split Cache Invalidation in Two

Danny Holloran — Mon, 17 Aug 2026 08:05:42 +0000

There is a bug I have written at least three times. An editor updates a product description in the CMS, hits publish, refreshes the page, and sees the old copy. So I add an on-demand revalidation webhook. Then a logged-in user submits a form, gets redirected to the detail page, and sees their own submission missing. Same cache, same invalidation call, two completely different expectations about what "invalidate" means.

Next.js 16 stopped pretending those are the same operation. revalidateTag and updateTag now exist side by side, and the difference is not a naming quirk. One serves stale content while it rebuilds. The other blocks until the data is fresh. Picking the wrong one is how you end up with the bug above.

The staleness question decides which function you call

Both functions operate on cache tags, so the setup is identical. You tag cached data either through fetch or inside a 'use cache' function:

import { cacheTag, cacheLife } from "next/cache";

export async function getProduct(id: string) {
  "use cache";
  cacheTag("products", `product-${id}`);
  cacheLife("max");

  const res = await fetch(`https://cms.example.com/products/${id}`);
  return res.json();
}

cacheLife('max') says: do not bother with time-based expiry, this thing stays cached until something explicitly tells us it changed. That is the right posture for CMS content. Nobody wants a revalidate-every-60-seconds timer hammering an API that changes twice a week.

Now the invalidation. From a webhook, you want revalidateTag:

// app/api/cms-webhook/route.ts
import { revalidateTag } from "next/cache";
import type { NextRequest } from "next/server";

export async function POST(request: NextRequest) {
  const secret = request.headers.get("x-webhook-secret");
  if (secret !== process.env.CMS_WEBHOOK_SECRET) {
    return new Response("Unauthorized", { status: 401 });
  }

  const { model, id } = await request.json();
  revalidateTag(model === "product" ? `product-${id}` : model, "max");

  return Response.json({ revalidated: true, now: Date.now() });
}

That second argument matters. revalidateTag(tag, 'max') marks the entry stale rather than expiring it, so the next visitor gets the cached page instantly while a fresh render happens in the background. The single-argument form still works but is deprecated, and it is the blocking version, which means the unlucky first visitor after every content edit eats a full server render.

There is a subtlety worth knowing: marking a tag stale does not trigger a rebuild. Nothing regenerates until somebody actually visits a page using that tag. If you invalidate a tag attached to ten thousand product pages, you do not get ten thousand simultaneous renders. You get renders spread across real traffic, which is usually what you want and occasionally surprising if you were expecting a burst of activity in your logs.

updateTag is for read-your-own-writes

updateTag only works inside Server Actions. Not Route Handlers, not Client Components. That restriction is the whole point: Server Actions are where a user does something and then immediately looks at the result.

"use server";

import { updateTag } from "next/cache";
import { redirect } from "next/navigation";

export async function createReview(formData: FormData) {
  const review = await db.review.create({
    data: {
      productId: String(formData.get("productId")),
      body: String(formData.get("body")),
    },
  });

  updateTag("reviews");
  updateTag(`product-${review.productId}`);

  redirect(`/products/${review.productId}`);
}

updateTag expires the entry outright. The redirect that follows will wait for a fresh render rather than handing back the version of the page that does not have the review on it. Slower, and correct. Swap in revalidateTag(tag, 'max') here and the user lands on a page missing the thing they just wrote, which reads as a broken form even though the write succeeded.

The rule I have settled on: if a human is waiting to see their own change, updateTag. If a system somewhere told you data changed, revalidateTag with 'max'.

Multi-instance is where this quietly breaks

One detail the docs are refreshingly blunt about: revalidation events are local by default. Call revalidateTag on the instance that received the webhook and only that instance's cache is invalidated. Every other instance behind your load balancer keeps serving the old page until its own copy expires.

On a single-instance deploy or a platform that handles this for you, it never comes up. Run three containers yourself and you get a genuinely confusing bug where refreshing the page flips between old and new content depending on routing. The fix is a custom cache handler implementing updateTags() to write invalidation timestamps to shared storage and refreshTags() to read them back before each request. Wrap refreshTags() in a try/catch, because a thrown error there propagates as a request failure rather than degrading to stale content.

Worth auditing your own setup before you need it. Cache invalidation being hard is a cliché, but the specific hard part here is that the failure mode is invisible in development and intermittent in production.

If you are still on the single-argument revalidateTag, that migration is the cheapest win available: add 'max' where a webhook fires it, switch to updateTag where a Server Action does.

CSS text-box-trim: The End of Fudging Vertical Padding

Danny Holloran — Fri, 14 Aug 2026 08:05:34 +0000

You give a button padding: 12px and it comes out looking bottom-heavy. So you split it: padding: 10px 12px 14px, squint, nudge the numbers, ship it. Two sprints later design swaps the type family and every one of those hand-tuned values is wrong again, because the new font reserves a different amount of invisible space than the old one did.

That invisible space has a name, and as of this month you can finally cut it off.

Where the extra space comes from

Every font ships with metrics that describe more than the letters you can see. There's room above the capitals for accents and diacritics, and room below the baseline for descenders, and the browser reserves all of it whether or not a single "p" appears in your text. On top of that, line-height adds leading, which the web splits in half and distributes evenly above and below the content area. Matthias Ott's The Thing With Leading In CSS walks through the typesetting history behind that split, but the practical upshot is simple: a text box is always taller than its text, by an amount that changes per font and per line-height.

Symmetric padding on top of an asymmetric box gives you an asymmetric-looking result. That's the whole bug.

The two properties

text-box-trim says which edges to cut. text-box-edge says where to cut to.

h1 {
  text-box-trim: trim-both; /* trim-start | trim-end | trim-both | none */
  text-box-edge: cap alphabetic; /* over-edge, then under-edge */
}

cap trims the over edge down to the top of the capital letters. ex trims to the x-height instead, which is a nicer optical match for some display faces. alphabetic trims the under edge flush with the baseline. There's a text value on both sides if you want the font's own text edges rather than the letterform edges.

In practice you'll write the shorthand and move on:

button {
  text-box: trim-both cap alphabetic;
  padding: 12px;
}

That's the version you want roughly all of the time. Now padding: 12px actually means twelve pixels of visible space on every side, in every font, and swapping the type family doesn't silently re-break your spacing.

Where it actually pays off

Optical centering. Buttons, badges, pill-shaped tags, anything small and intrinsically sized. These are the components where half-leading is proportionally largest and most obvious.

Aligning text next to non-text. Put a 40px avatar beside a heading and the heading's box is taller than its letters, so the two never quite line up. Trim the heading and they do.

Gaps that mean something. In a stacked block of text, gap and margin-block measure box edges, which include the invisible band on both sides. Trim the leading and your rhythm values start describing the space a reader actually perceives, instead of that space minus an unknown font-dependent constant.

One caveat worth being deliberate about: trimming removes visual space, not just visual space you didn't want. If you trim a button and don't add the padding back, you've quietly shrunk the tap target. WCAG 2.2's target size minimum is 24 by 24 CSS pixels, and half-leading was doing invisible work toward that number. Trim, then set the padding you actually meant.

Multi-line text behaves the way you'd hope: the trim applies above the first formatted line and below the last one, never between lines. And because it's defined in terms of over and under rather than top and bottom, it follows writing-mode correctly without any extra work.

Shipping it

Chrome and Edge have had this since 133, Safari since 18.2, and Firefox 154 turns it on by default. That release is dated August 18, 2026, which makes text-box a Baseline newly-available feature about a week from now.

Even before that lands everywhere, the failure mode is the kindest one CSS offers: a browser that doesn't recognize the property ignores the declaration and renders the spacing it always did. Nothing collapses, nothing overlaps, you just don't get the tightening. That makes it safe to add today with no fallback at all.

If the trimmed spacing is load-bearing in a particular component, gate the compensating padding behind a feature query so the two values stay in sync:

.tag {
  padding: 6px 12px;
}

@supports (text-box: trim-both cap alphabetic) {
  .tag {
    text-box: trim-both cap alphabetic;
    padding: 10px 12px;
  }
}

If you've ever used Figma's vertical trim control and wondered why the handoff never matched, this is the missing half. Adam Argyle's Chrome for Developers post has an interactive playground that's worth ten minutes of poking at with your own type stack, and the MDN reference has the full value grammar. Start with your buttons. The difference is small, and you will not be able to unsee it.

Trusted Types Is Baseline: DOM XSS Is Now a Type Error

Danny Holloran — Tue, 11 Aug 2026 08:05:20 +0000

Every codebase has one. Somewhere in a component nobody has opened in eighteen months, there is a line that reads el.innerHTML = someValue, and nobody can tell you with confidence where someValue comes from. Maybe it's a hardcoded template. Maybe it's a server response. Maybe, three refactors ago, it started carrying a slice of location.hash. That uncertainty is the entire DOM XSS problem: the sink is a plain string setter, strings all look alike, and the browser has no way to tell a trusted one from an attacker-controlled one.

Trusted Types fixes that by refusing strings outright. And as of February 2026, when Firefox 148 shipped support, it's Baseline — Chrome and Edge have had it since 83 back in 2020, Safari joined in version 26, and now the whole core browser set is covered. It's no longer a Chrome-only hardening trick you bolt onto an internal admin tool.

Turning a whole class of bug into a runtime error

The API works by locking down the risky sinks: innerHTML, outerHTML, insertAdjacentHTML, document.write, DOMParser.parseFromString, <iframe srcdoc>, script src and text content, and the code-compiling family (eval, new Function(), string-argument setTimeout and setInterval). Once enforcement is on, passing a raw string to any of them throws a TypeError.

You opt in with a CSP header:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types escape-html;

That first directive is the switch. The second is an allowlist of policy names — factories that are the only things permitted to mint a trusted value:

const escapeHTMLPolicy = trustedTypes.createPolicy("escape-html", {
  createHTML: (input) => input.replace(/</g, "&lt;"),
});

const safe = escapeHTMLPolicy.createHTML("<img src=x onerror=alert(1)>");
safe instanceof TrustedHTML; // true
el.innerHTML = safe; // fine

el.innerHTML = userInput; // TypeError

Note what this actually buys you. Trusted Types does not sanitize anything — your createHTML function is still your own code and can still be wrong. What it guarantees is that every path into a dangerous sink now runs through a named policy you declared on purpose. The DOM XSS attack surface of the entire app collapses down to the handful of lines inside your policies. That is a security review you can finish in an afternoon instead of grepping 40,000 lines for innerHTML.

Also worth knowing before you start: Trusted Types only works in secure contexts, so HTTPS or localhost.

Rolling it out without breaking production

Do not flip enforcement on first. Ship the report-only variant, let it run against real traffic, and collect what breaks:

Content-Security-Policy-Report-Only: require-trusted-types-for 'script'; report-uri /csp-reports

Violations arrive with the file, line, column, and a script-sample snippet of the offending value, which is usually enough to find the culprit immediately. If you'd rather not stand up a collector on day one, a ReportingObserver gets you the same data in the console:

new ReportingObserver(
  (reports) => {
    for (const r of reports) {
      if (r.body.effectiveDirective === "require-trusted-types-for") {
        console.warn("Trusted Types violation:", r.body);
      }
    }
  },
  { buffered: true },
).observe();

Then work the list. Most violations have a boring fix — the code didn't need string HTML in the first place:

// before
el.innerHTML = "<img src=xyz.jpg>";

// after
el.replaceChildren(
  Object.assign(document.createElement("img"), { src: "xyz.jpg" }),
);

Where you genuinely need to render untrusted HTML, reach for a sanitizer that already speaks the protocol. DOMPurify will hand back a TrustedHTML instead of a string if you ask:

import DOMPurify from "dompurify";
el.innerHTML = DOMPurify.sanitize(html, { RETURN_TRUSTED_TYPE: true });

The escape hatch is a policy literally named default, which the browser applies to any string that reaches a sink without one. It's the right tool when a third-party script from a CDN is the thing violating and you can't patch it. Use it grudgingly — a default policy re-centralizes all your sanitization decisions in one function that has no idea what context it's being called from, which is most of the way back to where you started.

Where this fits

Trusted Types and the Sanitizer API solve adjacent halves of the same problem and pair well: the Sanitizer decides what HTML is safe, Trusted Types enforces that something made that decision at all. Neither replaces a strict, nonce-based CSP for the server-rendered side of XSS.

If you own an app that handles anything sensitive, the report-only header is close to free — one line of config, zero behavior change, and a list of exactly where your DOM XSS risk lives. Start there, and decide later whether to enforce.

Further reading: MDN's Trusted Types API reference and the web.dev deep dive.

The Long Animation Frames API: Find What Actually Broke Your INP

Danny Holloran — Mon, 10 Aug 2026 08:06:37 +0000

Your real user monitoring dashboard says the 75th percentile INP on your product page is 412ms. You open DevTools, click the same button forty times, and every interaction comes back at 60ms. Nothing reproduces. So you start guessing: maybe it's the analytics tag, maybe it's the third-party chat widget, maybe it's that one useEffect that everybody is afraid to touch.

The Long Tasks API was supposed to help here, and it mostly didn't. It would tell you a task ran for 210ms and attribute it to "self" or an iframe container, which is roughly as actionable as a smoke alarm that only reports "somewhere in the house." The Long Animation Frames API is the replacement, and it does the thing you actually wanted all along: it hands you a script URL, a function name, and a character offset.

A frame is a better unit of measurement than a task

Slow interactions are rarely one fat task. They're usually five medium tasks, a ResizeObserver callback, and a style recalculation, all landing between two paints. Long Tasks only saw the fat ones, and it stopped measuring before rendering even started.

LoAF widens the window. It reports on any animation frame whose total work exceeded 50ms, covering everything from the first task in that frame through style, layout, and paint. Entries arrive with entryType of long-animation-frame:

const observer = new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    console.log({
      duration: frame.duration,
      blockingDuration: frame.blockingDuration,
      scriptTime: frame.renderStart ? frame.renderStart - frame.startTime : 0,
      styleAndLayout: frame.styleAndLayoutStart
        ? frame.paintTime - frame.styleAndLayoutStart
        : 0,
    });
  }
});

observer.observe({ type: "long-animation-frame", buffered: true });

Four timestamps do most of the work. startTime is when the frame began, renderStart is when script handed off to the rendering pipeline, styleAndLayoutStart is where recalc and layout begin, and paintTime is where it ends. Subtracting them tells you whether you have a JavaScript problem or a layout problem, which are fixed in completely different ways.

The one field to alert on is blockingDuration. It sums the over-50ms portion of every long task in the frame plus the rendering time, so it approximates how long the main thread was genuinely unavailable to a user. A 300ms frame with a 20ms blockingDuration is fine. A 120ms frame with a 90ms blockingDuration is not.

Script attribution is the whole point

Every LoAF entry carries a scripts array of PerformanceScriptTiming objects, and this is where the guessing stops:

const worst = frame.scripts.sort((a, b) => b.duration - a.duration)[0];

console.log({
  url: worst.sourceURL, // https://cdn.example.com/widget.js
  fn: worst.sourceFunctionName, // handleScroll
  char: worst.sourceCharPosition, // 18422
  invoker: worst.invoker, // window.onscroll
  invokerType: worst.invokerType, // event-listener
  duration: worst.duration,
  forcedLayout: worst.forcedStyleAndLayoutDuration,
  paused: worst.pauseDuration,
});

invokerType tells you how the script got run: event-listener, user-callback, resolve-promise, module-script, classic-script. That distinction matters, because a slow event-listener is your code to fix and a slow classic-script during load is usually a tag manager you need to defer.

forcedStyleAndLayoutDuration is quietly the best field in the API. If it's a meaningful chunk of duration, you have layout thrashing: something read offsetHeight or getBoundingClientRect() inside a write loop and forced synchronous layout. You now know which function, in which file, at which character.

The caveat worth knowing before you build dashboards on this: attribution only covers same-origin main-thread scripts. Cross-origin iframes, web workers, service workers, and browser extensions can lengthen a frame without ever showing up in scripts. When you see a big duration with a nearly empty scripts array, that absence is itself the signal.

Tie it to the interaction, not just the clock

A stream of slow frames is noise until you connect it to a specific bad interaction. The easiest path is web-vitals with the attribution build, which already correlates LoAF entries with the INP interaction for you:

import { onINP } from "web-vitals/attribution";

onINP(({ value, attribution }) => {
  if (value < 200) return;

  const culprit = attribution.longAnimationFrameEntries
    .flatMap((frame) => frame.scripts)
    .sort((a, b) => b.duration - a.duration)[0];

  beacon("/rum", {
    inp: value,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processing: attribution.processingDuration,
    presentation: attribution.presentationDelay,
    script: culprit && `${culprit.sourceURL}:${culprit.sourceFunctionName}`,
  });
});

Send the single worst script, not the whole entry. A busy page can produce dozens of LoAFs in a session and serializing all of them will cost you more than the insight is worth.

LoAF shipped in Chrome 123 after an origin trial, and it's still Chromium-only. That sounds limiting until you remember that Chrome is also where your Core Web Vitals field data comes from, so the coverage gap and the metric you're optimizing line up almost exactly. Start by logging blockingDuration and the top script for interactions over 200ms, then read the Chrome documentation and the spec once you know which part of your frame is actually on fire.

Invoker Commands: Wiring Buttons to Dialogs and Popovers Without JavaScript

Danny Holloran — Thu, 02 Jul 2026 14:09:01 +0000

Originally published on danholloran.me

Every time you wire up a modal, you end up writing the same three lines of JavaScript: grab the button, grab the dialog, attach a click listener that calls showModal(). Do it again for the close button. Do it again for the next popover, the next dropdown, the next confirmation box. Across a real app, that adds up to a pile of glue code whose only job is connecting one element to another. The Invoker Commands API deletes most of that glue by letting a button say, right in the HTML, what it controls and what it does.

Two attributes, no listener

The API adds two attributes to <button>: commandfor points at the id of the element you want to control, and command names the action. For a dialog, that looks like this:

<button command="show-modal" commandfor="confirm">Delete</button>

<dialog id="confirm">
  <p>Delete this item?</p>
  <button command="close" commandfor="confirm">Cancel</button>
</dialog>

There is no script here at all. The first button opens the dialog as a modal; the button inside closes it. The browser ships a set of built-in commands for exactly the elements that used to need boilerplate: dialogs get show-modal and close, and popovers get toggle-popover, show-popover, and hide-popover.

A popover menu is just as terse:

<button command="toggle-popover" commandfor="menu">Menu</button>

<div id="menu" popover>
  <a href="/profile">Profile</a>
  <a href="/logout">Log out</a>
</div>

Why this beats a click handler

The obvious win is less code, but the real win is behavior you would otherwise have to remember to implement. Because the browser owns the interaction, you inherit correct focus management, the Escape-to-close behavior for dialogs and popovers, and the accessibility relationships between the trigger and its target for free. That is a category of bug (the modal that traps focus wrong, the popover that does not close on outside click) that simply stops happening.

There is also a deliberate constraint: only <button> can be an invoker. Links and inputs cannot use commandfor, because a command is an action, and buttons are the element with the right keyboard and semantic behavior for actions. And since the wiring lives in markup, it works the moment the HTML parses, before any JavaScript hydrates. For server-rendered pages and islands-style architectures, that means your dialogs and menus are interactive without waiting on a bundle.

Custom commands for your own behavior

Built-ins cover dialogs and popovers, but the API is not limited to them. You can define your own command with a double-dash prefix, following the same "dashed-ident" convention as CSS custom properties. The -- namespace is reserved: the browser guarantees it will never ship a built-in command starting with it, so your names can never collide with a future addition.

A custom command fires a command event on the target element, and you listen there:

<button command="--rotate-left" commandfor="photo">Rotate left</button>
<button command="--reset" commandfor="photo">Reset</button>

<img id="photo" src="/cat.jpg" alt="A cat, upright" />

const photo = document.getElementById("photo");

photo.addEventListener("command", (event) => {
  if (event.command === "--rotate-left") {
    // rotate and update alt text
  } else if (event.command === "--reset") {
    // reset
  }
  // event.source is the button that triggered the command
});

One gotcha worth internalizing: the command event does not bubble. You have to listen on the target element itself, not on a shared ancestor, so event delegation patterns will not pick it up.

Where support stands

This is not a "someday" feature. As of late 2025 the Invoker Commands API reached Baseline across Chrome and Edge (135+), Firefox, and Safari, so you can use it in production for the browsers most projects target. If you still support older versions, it degrades cleanly: a <button> with command/commandfor is just a button where the attributes are ignored, so a small click-handler fallback (or a feature check like "command" in HTMLButtonElement.prototype) keeps things working everywhere.

The practical rule of thumb: reach for command and commandfor first for dialogs, popovers, and simple UI toggles, and only drop down to JavaScript when you need genuinely custom behavior, which the custom-command event gives you a clean hook for. You end up with fewer listeners, less hydration-order fragility, and accessibility handled by the platform instead of by you.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Fallow: A Codebase Truth Layer for Agent-Written Code

Danny Holloran — Wed, 01 Jul 2026 19:29:44 +0000

Originally published on danholloran.me

Most of the code in my side projects lately wasn't typed by me. I write the issue, an agent writes the branch, and I review the PR. That workflow is fast, but it quietly moves the hard part downstream. When you review a lot of generated diffs, you stop worrying about whether a function works and start worrying about the stuff a diff never shows you: the export nothing imports anymore, the near-identical helper that already exists two folders over, the module that just started reaching across a boundary it had no business touching.

ESLint and Prettier don't catch any of that, because they can't. A linter reads one file at a time. The problems I actually run into are relationships between files, and that's exactly the gap Fallow fills.

What Fallow actually checks

Fallow calls itself a "codebase truth layer," and the framing is accurate. Instead of linting files, it builds a module graph across your whole TypeScript/JavaScript project and answers questions no file-local tool can:

Dead code — unused files, exports, dependencies, types, and circular dependencies
Duplication — copy-pasted blocks, from exact matches to semantic clones with renamed variables
Complexity — the riskiest functions and the files worth refactoring first
Architecture drift — imports that cross layer or module boundaries they shouldn't

The pitch that sold me is the honest one on the README: "Built for AI-assisted development. No AI inside." It's a Rust binary, it's deterministic, and it's fast enough that speed never becomes an excuse to skip it. On a 20,000-file Next.js project it finishes dead-code analysis in under two seconds. On anything I'm building solo, it's basically instant.

npx fallow

 Dead code   3 unused files, 12 unused exports, 2 unused deps       18ms
 Duplication 4 clone groups (2.1% of codebase)                      31ms
 Complexity  7 functions exceed thresholds                           4ms

No config for the first run. It ships 90 framework plugins, so it already knows what an entry point looks like in Next, Nuxt, SvelteKit, Astro, and the rest.

Where it fits with my other guardrails

Fallow didn't replace anything in my setup. It filled the one hole the others left.

The way I think about it now, each tool owns a different scale. Prettier owns formatting. ESLint owns file-local correctness. My CLAUDE.md (or AGENTS.md) owns intent: a handful of rules I want every generated change to respect, like rule of three before you abstract, early returns over nested conditionals, and keep functions small. Those guidelines shape the code as the agent writes it. Fallow owns the part none of the others can see, which is what the change did to the codebase as a whole.

The command that ties it into review is audit:

npx fallow audit --format json

It scopes dead code, duplication, and complexity to just the changed files and returns a verdict: pass, warn, or fail, with a real exit code. That runs cleanly in CI, but it's just as useful the moment before I open a PR. If the agent left an orphaned export or quietly duplicated a utility, I see it as a fact instead of hoping I'll spot it by eye at line 300 of a diff.

Because the JSON output includes a per-issue actions array, the agent itself can consume it. The loop becomes: generate the change, run fallow --format json, read the findings, fix the obvious ones, and hand me a cleaner PR to review. There's an MCP server for wiring it directly into Claude Code, Cursor, and friends, but honestly the CLI plus a line in the agent instructions gets you most of the value.

Getting started

Running it once costs nothing:

npx fallow            # dead code + duplication + health
fallow dead-code      # just cleanup candidates
fallow health --score # project health score, 0-100
fallow fix --dry-run  # preview automatic cleanup

When you're ready to make it stick, fallow init writes a tailored .fallowrc.json and can scaffold a pre-commit hook. Start every rule at warn so it surfaces problems without blocking you, then promote the ones you care about to error:

{ "rules": { "unused-files": "error", "unused-exports": "warn" } }

In CI it's a one-liner (uses: fallow-rs/fallow@v2), and the --baseline flag means you only fail on new issues, which makes it painless to adopt on a codebase that's already a little messy.

Delegating code to agents doesn't remove the need for review. It just changes what review is about. Fallow gives me a factual read on what a change did to the whole project, so I can spend my attention on the parts that actually need judgment instead of playing spot-the-dead-export. If you're shipping code you didn't personally type, that's a trade worth making.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.