DEV Community: Andrés Clúa

The Problem Isn’t AI. It’s the Pace.

Andrés Clúa — Tue, 18 Aug 2026 21:42:00 +0000

Swipe and there is food at the door. Swipe and there is a date on Thursday. Swipe and there is a stranger's car outside taking you home.

Ask for a function and there is code. Ask for a design and there is a mockup. Ask for a summary of a forty page document and it is done before you have finished reading the first page yourself.

None of this felt like a decision. It arrived, and we adapted to the interface without ever adapting to the change.

That is the part I keep thinking about. Not whether the technology is good. Whether the gap between how fast it moves and how fast we absorb it is still a survivable gap.

The race is worth running

I want to be clear about where I stand, because the easy version of this article is a complaint, and I do not want to write that one.

I like this. I have built things in the last two years that I could not have built in the previous ten. I read release notes for fun. The speed is genuinely exciting and I am not nostalgic for a slower industry.

The problem is not the speed. It is that the speed now exceeds my ability to form an opinion about what is moving.

Where I notice it in my own work

The clearest version for me is tooling.

I wrote a while back about Rust taking over the JavaScript toolchain. Vite, Rolldown, the whole rewrite of the layer underneath everything we ship. It was a good story to write. It was also a story where, by the time I understood the tradeoffs well enough to have a real position, the position was already outdated.

That used to be an annoyance. Now it is the normal condition. I do not reach competence with a tool anymore. I reach a working familiarity, and then the tool changes, and I am back near the start with a slightly better instinct than last time.

Evaluation has become the bottleneck. Not learning. Deciding what is worth learning.

Multiply that by every developer on a team, and you get an organisation where nobody is deeply expert in anything because expertise takes longer to build than the thing takes to be replaced. That has architectural consequences. It is why so many codebases are now three eras of tooling stacked on top of each other, with nobody left who understands the bottom layer.

The honest version of "our brains cannot keep up"

The line I first wanted to write was that our brains do not finish processing the change. It feels true. It is how the tiredness actually feels from the inside.

But I do not think I can defend it as stated, and there is a lot of confident pop neuroscience about attention spans and dopamine that does not survive contact with the actual research. So let me say the thing I can defend instead.

What lags is not biology. It is everything built on top of biology.

Norms take years. Nobody knew what phone etiquette was for a decade. Laws take longer. Professional identity takes a career, which is why a developer who trained on one paradigm spends their whole working life partly translating. Institutions are the slowest of all, and they are the layer that decides what is permitted rather than what is possible.

Those lags are measurable. You do not need a claim about neurons. The technology iterates in months and the scaffolding around it iterates in decades, and every year that ratio gets worse.

Every generation said this

I have to include this part or the article is dishonest.

People said it about the printing press. The telegraph. Radio. Television. The internet. Every one of those came with a serious argument that human beings were about to be overwhelmed, and in every case we absorbed it and the panic reads as quaint now.

"This time is different" is the most overused sentence in technology. I do not get to skip that objection just because I feel tired.

So here is the only version of the difference I can actually argue for, and I hold it loosely.

Every previous case had a plateau. The technology arrived, there was a shock, then a long flat stretch while people, laws and habits caught up, and then the next thing. The plateau is what made it survivable. Adaptation happened during the pause.

The proposal on the table now is to remove the pause.

Which brings me to the letter

On July 28, 2026, more than a thousand employees of the frontier AI labs signed a statement called Pacing the Frontier. The site listed 1,178 signatories when I checked and the form is still open. Anthropic, OpenAI, Google and Meta are all represented, including several CEOs and chief scientists.

They are not asking for a pause. The single request is that the U.S. government support an international effort to build the technical and governance tools needed to "deliberately pace the frontier of automated AI development."

Automated AI development is the phrase that matters. Models used to build better models, which are then used to build better models again. That is a description of a process with no plateau in it. The gap between capability and comprehension stops being constant and starts compounding.

What struck me most was not the request. It was the personal comments on the signatory page. Several of them are people who work on capability evaluations for a living saying the recent pace has been a shock to them too.

That is the same feeling I have on a much smaller scale about build tools. It goes all the way up. Nobody is standing somewhere calm.

So what do we actually do

I do not have a policy answer. I build websites and internal tools. The governance question is above my pay grade and I am suspicious of developers who pretend otherwise.

But I have a working answer for myself, and it is not "keep up."

Keeping up is no longer a coherent goal. There is more happening per week than any person can evaluate, and treating that as a personal failure is a category error. The skill is not consumption. It is choosing what to deliberately not keep up with, and being at peace with that choice.

For my own work that means a short list of things I go deep on and a much longer list I let pass. It means I do not adopt a tool until it has survived long enough to have known problems. It means I write about things a few weeks late, once the first wave of takes has burned off and there is something real to say.

That is a personal mitigation, not a solution. The version of this problem that operates at the scale of an industry does not get solved by individuals choosing to read less. Which is, I think, the strongest thing the letter has going for it. It is the institutional form of the same admission. Someone should be allowed to say wait, and right now nobody is.

I do not think we should stop out of fear. I do think there is something absurd about waiting until we have lost control before starting the conversation about how we would want to exercise it.

Sources: the statement and signatory list at pacingthefrontier.com, with reporting from The Next Web. Signatory counts were accurate at the time of writing.

How to Tell If You Can Actually Drop Your Animation Library

Andrés Clúa — Tue, 11 Aug 2026 11:56:46 +0000

The Demo Is Not the Migration

Every post telling me to delete my animation library opens with the same snippet.

.progress-bar {
  animation: grow linear;
  animation-timeline: scroll();
}

@keyframes grow {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

Zero bytes. Native platform. The browser does it now.

That code is real, it works, and it is genuinely great. It is also not the decision.

I lead a team that builds animation-heavy sites, so when scroll-driven animations got real browser support I took the question seriously. I expected to come out with a smaller bundle. I came out with two conclusions that sit oddly together: this is the most fun I have had with the platform in years, and I am not removing GSAP from a single project.

The reason is not that CSS is worse. It is that a stack decision is not scored on its best example.

How this decision actually works

Nobody switches stacks because the new thing is prettier. You switch when everything you currently do has an equivalent in the new thing, or when the gaps are small enough to absorb.

So the question is never "can CSS do a progress bar." It is: go through the animations that exist in your codebase right now, every one of them, and find the ones with no equivalent. Those are the whole decision. The happy path is not information, because the happy path is what the demo already showed you.

And there is arithmetic that people skip. If forty animations move to CSS and three cannot, the library is still in your bundle. You did not save 35 KB. You saved nothing, and now you maintain two animation systems, two mental models, two sets of debugging habits, and a rule about which one owns what. Partial migration is often more expensive than either endpoint.

That reframes what the rest of this article is for. It is not a comparison table. It is the inventory: what has an equivalent, what has a partial one, and what has none. I would rather you finish it able to run the same audit on your own projects than agree with my conclusion.

Starting with the thing almost every comparison gets wrong.

CSS can scrub. That was never the gap.

Scrubbing is exactly what animation-timeline does. Animation progress is tied to scroll position, one to one. The snippet at the top of this article is a scrubbed animation, running off the main thread, with no library.

What CSS does not have is smoothed scrub:

gsap.to('.panel', {
  x: -1000,
  scrollTrigger: { trigger: '.section', scrub: 1 }
})

scrub: true is one to one, same as CSS. scrub: 1 means the animation takes a second to catch up to the scroll position. It lags behind you. It eases toward the target instead of snapping to it.

That single digit is a large part of why GSAP work feels expensive and CSS scroll animations can feel mechanical. There is no CSS-only equivalent.

There is, however, a four kilobyte one, and it is probably already in your project. I come back to that below, because it is the most interesting thing I found while writing this.

What CSS is genuinely great at

I want to be fair before I list limits, because the limits are not a reason to ignore this. Some of it is better than what we were doing.

Reveals on enter, the most common item in any brief:

.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

@keyframes fade-up {
  from { opacity: 0; transform: translateY(2rem); }
  to   { opacity: 1; transform: translateY(0); }
}

That replaces an IntersectionObserver, a class toggle, and the teardown for both. I have written the JavaScript version of this hundreds of times and I do not miss it.

Progress bars are one declaration. Parallax is a keyframe with animation-range: cover. And named timelines are the part people overlook, because they unlock layouts where the scroll container is not the animated element:

.gallery {
  overflow-x: auto;
  scroll-timeline: --gallery inline;
}

.indicator {
  animation: grow linear;
  animation-timeline: --gallery;
}

Three things push me toward CSS that have nothing to do with capability. It runs on the compositor thread, which a ScrollTrigger onUpdate does not, and on a mid-range Android that gap is visible. It has no lifecycle to get wrong, which removes an entire class of bug on client-side routed sites. And it costs nothing.

Hold onto that first one. If you run WebGL it reverses completely, and that is the last section of this article.

So I use it. Just not for everything.

The refresh problem, which CSS simply does not have

This is the advantage I underrated, and if your pages have accordions, filters, lazy content or late-loading images, it is probably the one that matters most to you.

ScrollTrigger measures start and end positions when it is created and caches them. Change the page height afterwards and those numbers are stale.

GSAP's own docs are direct about it: ScrollTrigger refreshes automatically when the viewport resizes, but a value you hardcoded at creation will not update unless you made it function-based. And if you load images without width and height attributes, or fetch content that affects layout, you normally have to call ScrollTrigger.refresh() yourself in the callback.

So real code ends up looking like this:

ScrollTrigger.create({
  trigger: '.section',
  start: () => 'top top',
  end: () => '+=' + panel.offsetHeight,
  invalidateOnRefresh: true,
  scrub: true
})

accordion.addEventListener('toggle', () => ScrollTrigger.refresh())

new ResizeObserver(() => ScrollTrigger.refresh())
  .observe(document.querySelector('.dynamic-grid'))

Function-based start and end so they recompute. invalidateOnRefresh so recorded tween values are discarded. A refresh call on every DOM mutation you can anticipate. A ResizeObserver for the ones you cannot.

And refresh brings its own problems. It re-measures every trigger on the page, so it is not cheap when you have forty of them. Refresh order matters, which is why refreshPriority exists. Internally it jumps scroll position to zero so every element sits at its natural position, which is why scroll-behavior: smooth on your html element quietly breaks it. And progress is not preserved across a refresh unless you save and restore it yourself with refreshInit and refresh listeners.

None of this is a knock on ScrollTrigger. It is the unavoidable cost of caching measurements in userland.

The CSS version of that code is the CSS version of any other scroll animation:

.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Open an accordion, load a grid, swap a font, filter a list. Nothing to call. A scroll timeline is not a stored number, it is derived from layout and evaluated as part of it. When the scroll range changes, the range changes. There is no cache to invalidate because there was never a cache.

Two honest caveats.

The underlying physics do not disappear. If the scroll range changes while an animation is mid-progress, the animation's position remaps immediately to the new range, so you can still get a visual jump when something expands above the fold. The difference is that CSS self-corrects and lands correct, whereas a stale ScrollTrigger stays wrong until you refresh it. Wrong-then-right beats silently wrong.

And if you run Lenis, it has to know the new dimensions too. It observes wrapper and content size by default and exposes lenis.resize(), so this is mostly handled, but it is one more thing that can fall out of sync.

For a marketing site with static sections, this whole section is irrelevant. For anything with expandable content, filtering, or user-generated length, it is the strongest single argument for moving your simple animations to CSS.

Where it stops

This is the real body of the article. Every item here is something we ship regularly.

Smoothed scrub

Covered above. No CSS counterpart.

Real pinning

position: sticky is not pinning. ScrollTrigger's pin: true takes the element out of flow, holds it, injects spacer height so the page below does not jump, and restores it at the end.

ScrollTrigger.create({
  trigger: '.panels',
  pin: true,
  scrub: true,
  end: () => '+=' + document.querySelector('.panels').offsetWidth
})

Horizontal scroll sections, pinned storytelling, anything where pin duration is computed from measured content. Simple cases approximate with sticky and a tall parent. pinSpacing, nested pins and measured durations do not.

Orchestration

A CSS keyframe animation drives one element. A GSAP timeline sequences many, with labels, relative offsets, nesting and stagger.

const tl = gsap.timeline({ scrollTrigger: { trigger: '.hero', scrub: true } })

tl.to('.title', { y: -100 })
  .to('.subtitle', { opacity: 0 }, '-=0.3')
  .from('.cards', { y: 60, stagger: 0.08 }, 'cards')
  .to('.bg', { scale: 1.2 }, 'cards')

You can hand-roll this by giving every element the same named timeline and different animation-range values. It works. It is also a spreadsheet of magic numbers, and when a designer asks to shift one beat by 200ms you are recalculating all of them. For a solo experiment that is fine. For a team where someone else maintains it next year, it is not.

Progress in JavaScript

A shader uniform is not a CSS property. If scroll progress has to drive a canvas, a video scrub or an analytics event, you need the number in JavaScript.

ScrollTrigger.create({
  trigger: '.section',
  onUpdate: self => uniforms.uProgress.value = self.progress
})

There is a ScrollTimeline JavaScript API you can pass to element.animate(), but MDN lists it as limited availability, and it hands you an animation timeline rather than an arbitrary per-frame callback.

If you run WebGL this is the biggest item on your list by some distance, and it has a wrinkle that surprised me. It gets its own section at the end.

Responsive scene logic

ScrollTrigger.matchMedia() lets you build structurally different scenes per breakpoint with correct teardown. CSS media queries get you different values, not different structures.

The plugin surface

SplitText for per-character reveals, MorphSVG, DrawSVG, MotionPath with real control. No CSS equivalent, and these are precisely what an art director asks for by name.

Worth noting: GSAP has been 100% free since April 2025, every former Club plugin included, commercial use included, after Webflow acquired GreenSock. Cost is no longer an argument for leaving. Only bundle size and main-thread work are, and those are real but they are a tradeoff rather than a verdict.

If you use Lenis, half of this changes

I almost published without this section, and it would have been wrong.

Lenis is on most of the sites we build, and it changes the scrub answer completely. To see why, you have to know how it works, because a lot of people assume it is doing what Locomotive v4 used to do.

Old smooth scroll libraries faked it. They fixed a wrapper and translated it every frame. Under that approach, native scroll position never actually changes, so animation-timeline: scroll() sees nothing and your CSS scroll animations simply never run.

Lenis is not that. It runs on top of the native scroll engine, as a small animation layer built on scrollTo, with no transforms painted per frame, in under 4 KB. It intercepts the input, interpolates toward the target, and then sets the real scroll position each frame.

That single design decision is the whole story. The document's actual scroll offset updates, just smoothly. And animation-timeline reads the actual scroll offset.

So with Lenis on the page, your CSS scroll-driven animations inherit the smoothing for free. No configuration, no wiring, no lenis.on('scroll', ...). The lag I said CSS could not do arrives through the scroll position itself.

That is a genuinely good deal. Compare the integration cost:

// GSAP with Lenis: you wire it up
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time) => lenis.raf(time * 1000))
gsap.ticker.lagSmoothing(0)

/* CSS with Lenis: nothing */
.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
}

The CSS version has no integration code because there is nothing to sync. Both are reading the same number from the same place.

Four caveats before you get excited, because I did and then thought about it.

The smoothing is global, not per animation. Lenis has one lerp value for the entire page. ScrollTrigger's scrub is per instance, so you can have a hero lag by a full second and a progress bar track instantly. With Lenis everything shares one feel. For most sites that is fine, and arguably more coherent. For a hero where one layer should drag and another should stick to the cursor, it is not enough.

Do not double-smooth. Lenis plus scrub: 1 is a lerp on top of a lerp. It feels mushy and disconnected, and it is the most common mistake I see in this combination. If Lenis is running, use scrub: true and let Lenis own the feel.

You lose the compositor argument. This is the honest cost. One of the best things about CSS scroll-driven animations is that they run off the main thread. Lenis drives scroll from a main-thread rAF loop, so the position updates are now gated by main-thread frames. The animation still avoids the class of jank that comes from JavaScript touching style on every scroll event, but "this runs on the compositor and your JS cannot block it" is no longer true. If off-main-thread smoothness was your reason for moving to CSS, adding Lenis takes back part of what you bought.

Reduced motion removes the effect. Lenis honors prefers-reduced-motion by default and forces lerp to 1, so scroll tracks the input device one to one. That is correct behaviour, and it means users with that preference get the raw unsmoothed version of your animation. Do not build a scroll effect that only reads correctly with the lag.

The upshot: if Lenis is already in your stack, the case for CSS on simple scroll work gets meaningfully stronger, because you were paying for the smoothing anyway and CSS gets it for nothing. If it is not, adding a library to make your zero-byte solution feel right is a trade you should make deliberately rather than by habit.

Where support actually stands

Chrome and Edge shipped it unflagged in 115, July 2023. Three years of runway.

Safari landed it in Safari 26 in September 2025, added threaded scroll-driven animations in 26.4, and fixed progress-accuracy bugs in 26.5 in June 2026.

Firefox is still behind the layout.css.scroll-driven-animations.enabled flag in stable as of Firefox 152, June 2026. On by default in Nightly, and a named Interop 2026 priority, so it is coming.

Around 82% globally, which means not Baseline, blocked by Firefox.

I ship it anyway because the failure mode is benign. An unsupported browser ignores animation-timeline and the element sits at its natural state. Write it so that natural state is the visible one:

.reveal {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .reveal {
    animation: fade-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 100%;
  }
}

Visible by default, animated as enhancement. Compare that to a library failing to initialise, which usually means content stuck at opacity: 0 and a client on the phone.

Run the audit yourself

Here is the version of this you can actually apply, and it is not a list of my conclusions.

Open a real project. List every scroll animation in it. For each one, mark it green if CSS has a direct equivalent, yellow if you could get close with named timelines and some magic numbers, red if there is no equivalent at all. Reveals, parallax and progress bars will be green. Anything driving a WebGL uniform will be red.

Then look only at the red column. That column is the decision. If it is empty, you have a genuine migration and a smaller bundle. If it has three items, the library stays and the honest question becomes a different one: is CSS worth adopting alongside something I am keeping anyway?

For me the answer is yes, and for reasons the bundle-size framing misses entirely.

Reveals, parallax, progress bars: CSS. Wrapped in @supports, visible by default. Most animation work by volume, and it deletes a category of init and teardown bug.
Sections with dynamic height: CSS whenever possible. No refresh calls, no observers, nothing to invalidate.
Pinned sequences, horizontal scroll, orchestrated heroes: GSAP. No hesitation.
Anything driving WebGL or canvas: GSAP, and everything coupled to it too. The uniform needs the number in JS, and any DOM element that must stay locked to the scene has to come off the same clock.
Never both on one element. One owner per animation or you will lose an afternoon to a fight you cannot see in DevTools.
CSS first when prototyping. No install, no init, no cleanup, edit in DevTools and see it immediately. I now rough out scroll ideas in a stylesheet before deciding whether the finished version needs a timeline. Half the time it does not, and the other half I already know exactly what I am asking GSAP to do.

That is not a migration. It is a second tool, and it is a better one for a large share of the work.

If you run WebGL, one entry in that red column is different

I left this until now because it does not apply to everyone. If it applies to you, it is probably the most important section here.

Pure WebGL is easy to reason about. It is all JavaScript, so you write JavaScript. The trouble starts when a DOM element has to move with the WebGL. A heading locked to a distorted image plane. A caption sitting on a mesh as it scrolls. Text revealing in step with a shader wipe. This comes up constantly, partly because you usually want the text to stay real DOM for accessibility and SEO rather than baking it into the canvas.

Now two things have to agree, and here is the twist: the compositor advantage becomes the problem.

That was the first item on my list of reasons to like CSS. Scroll-driven animations are updated by the compositor, deliberately independent of your main thread. Your WebGL renders in a main-thread rAF. Those are two different clocks. On a given frame the CSS-animated heading can reflect one scroll position while the rendered WebGL frame reflects a slightly older one. The offset is a fraction of a frame. It is invisible in a screenshot and glaring in motion. The text swims against the image.

It reads as cheap, which on this kind of project is the single thing you were paid to avoid.

Off the main thread means on a different clock. Everywhere else that is the feature. Here it is the bug.

This is not hypothetical, it is the reason Lenis exists at all. It began as an internal tool for syncing WebGL and the DOM, and its own pitch is that jumps and delays in scroll-linked animations come from browsers running effects asynchronously from native scroll.

So the rule is about coupling, not co-presence:

A DOM element that must stay locked to WebGL: drive both from the same JS loop. Same rAF, same progress value, one source of truth. No CSS scroll-driven animation on that element, ever.
A DOM element that merely shares a page with WebGL: CSS is fine. A nav shrinking, an unrelated section fading in, a progress bar. Nobody perceives sub-frame desync between two things that are not visually related.

Get that line wrong and you produce the worst class of bug in this kind of work. Nothing breaks. Nothing errors. It just feels slightly wrong, and nobody on the call can articulate why.

Which is a decent argument for the whole thesis, actually. The snippet at the top of this article would have worked perfectly in that project, on that page, next to a WebGL scene it was quietly fighting with.

The part that generalises

None of the above is really about animation.

The pattern repeats for every stack decision I have made in fifteen years. Someone posts the snippet, the snippet is real, and the snippet is the easiest 80% of a problem whose difficulty lives entirely in the other 20%. Vue to Nuxt, REST to GraphQL, SCSS to Tailwind, npm to pnpm. The demo is always the happy path, because a demo of the hard path would not be a demo.

Stack decisions are not made on the best case. They are made on the worst thing you currently do that the new thing cannot do, and on whether keeping both is cheaper than keeping either.

Zero bytes is a great headline. It is not a feature inventory. I would rather ship 35 KB and the animation the client approved.

Sources: MDN on CSS scroll-driven animations and ScrollTimeline, the Lenis repo, and Webflow's GSAP announcement. Support figures accurate at time of writing. Check caniuse before shipping, this one is moving.

The Problem Isn’t AI. It’s the Pace.

Andrés Clúa — Wed, 29 Jul 2026 22:02:54 +0000

Swipe and there is food at the door. Swipe and there is a date on Thursday. Swipe and there is a stranger's car outside taking you home.

Ask for a function and there is code. Ask for a design and there is a mockup. Ask for a summary of a forty page document and it is done before you have finished reading the first page yourself.

None of this felt like a decision. It arrived, and we adapted to the interface without ever adapting to the change.

That is the part I keep thinking about. Not whether the technology is good. Whether the gap between how fast it moves and how fast we absorb it is still a survivable gap.

The race is worth running

I want to be clear about where I stand, because the easy version of this article is a complaint, and I do not want to write that one.

The problem is not the speed. It is that the speed now exceeds my ability to form an opinion about what is moving.

Where I notice it in my own work

The clearest version for me is tooling.

Evaluation has become the bottleneck. Not learning. Deciding what is worth learning.

The honest version of "our brains cannot keep up"

The line I first wanted to write was that our brains do not finish processing the change. It feels true. It is how the tiredness actually feels from the inside.

What lags is not biology. It is everything built on top of biology.

Those lags are measurable. You do not need a claim about neurons. The technology iterates in months and the scaffolding around it iterates in decades, and every year that ratio gets worse.

Every generation said this

I have to include this part or the article is dishonest.

"This time is different" is the most overused sentence in technology. I do not get to skip that objection just because I feel tired.

So here is the only version of the difference I can actually argue for, and I hold it loosely.

The proposal on the table now is to remove the pause.

Which brings me to the letter

That is the same feeling I have on a much smaller scale about build tools. It goes all the way up. Nobody is standing somewhere calm.

So what do we actually do

I do not have a policy answer. I build websites and internal tools. The governance question is above my pay grade and I am suspicious of developers who pretend otherwise.

But I have a working answer for myself, and it is not "keep up."

I do not think we should stop out of fear. I do think there is something absurd about waiting until we have lost control before starting the conversation about how we would want to exercise it.

Sources: the statement and signatory list at pacingthefrontier.com, with reporting from The Next Web. Signatory counts were accurate at the time of writing.

HTTP Just Got Its First New Method in 20 Years. Here's Why You Should Care.

Andrés Clúa — Fri, 03 Jul 2026 12:00:27 +0000

If you have ever written this, this article is for you:

// a "search" that is actually a POST
axios.post('/api/search', { category: 'shoes', maxPrice: 100 })

Or the vanilla version:

fetch('/api/search', {
  method: 'POST',
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

We all did it. The query was too big for a URL, so we used POST. It worked. But it was always a lie. We were telling HTTP "this modifies something" when it didn't.

In June 2026 the IETF published RFC 10008. It defines a new HTTP method called QUERY. It is the first new method in more than two decades. And it fixes exactly this.

The problem in 30 seconds

GET is perfect for reading data. It is safe, idempotent and cacheable. But it cannot carry a body, and URLs have length limits. Around 8000 characters if you are lucky. Less if a proxy in the middle disagrees.

POST carries any body you want. But HTTP assumes it changes state. So no automatic caching. No safe retries. If a POST times out, the client cannot just retry it. Maybe it already did something.

For years we had to pick one. Clean semantics or a real payload. Never both.

What QUERY does

QUERY is a GET with a body. That's it.

QUERY /products HTTP/1.1
Content-Type: application/json

{
  "category": "shoes",
  "maxPrice": 100,
  "sort": "price_asc"
}

I use axios for most of my projects, so this is how it looks there:

const { data } = await axios({
  method: 'QUERY',
  url: '/api/products',
  data: {
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  }
})

There is no axios.query() helper yet, but axios passes any custom method straight through to the underlying HTTP client, in the browser and in Node. No plugin needed.

If you prefer plain fetch, same idea:

const res = await fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  })
})
const data = await res.json()

The server runs the query and returns the result. Nothing changes on the server. The spec guarantees two things:

Safe. It does not modify state.
Idempotent. Sending it twice gives the same result as sending it once.

Those two guarantees are what everything below is built on.

This pattern is going to change

Look at almost any API in production today:

POST /search        <- reads data, says it writes
POST /reports/run   <- reads data, says it writes
POST /products      <- actually writes

Two of those three endpoints are lying. Here is where APIs are heading:

QUERY /search       <- reads
QUERY /reports      <- reads
POST  /products     <- writes

Not overnight. But the direction is clear. So the two questions that matter are: what works today, and how will our apps actually change.

Compatibility: where we are right now

The RFC is weeks old, so let's be honest about the current state.

The protocol side is already fine. HTTP does not have a fixed list of methods. QUERY is just a token in the request line. Any HTTP/1.1 or HTTP/2 connection can carry it today.

Servers. Nginx and Apache will pass QUERY requests through, but your config may need small tweaks. Anything that whitelists methods (limit_except, security rules, WAFs) needs QUERY added explicitly. This is where most early friction will live.

Frameworks. This is the real bottleneck. Your router needs to understand the method. Spring has a pull request in progress. Rails is discussing it. Express lets you handle custom methods with a bit of manual work. Expect native support to roll out across 2026 and 2027.

HTTP clients. Axios and fetch can already send arbitrary methods, so both of these work today:

// axios
axios.request({
  method: 'QUERY',
  url: '/api/products',
  data: { category: 'shoes', maxPrice: 100 }
})

// vanilla fetch
fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

One detail worth knowing: axios ignores the body only on GET requests in browsers, because fetch and XHR do not allow it. For any other method, including QUERY, data becomes the request body without touching transformRequest.

The catch in browsers is CORS. QUERY is not a safelisted method like GET or POST, so cross-origin requests trigger a preflight. This applies to axios and fetch equally, since underneath it is the same mechanism. Your server has to answer the OPTIONS request with:

Access-Control-Allow-Methods: GET, POST, QUERY, OPTIONS

Same-origin requests need nothing. And in Node there is no CORS at all, so server-to-server QUERY calls work right now.

CDNs and proxies. Here is the interesting signal: the RFC was co-authored by engineers from Cloudflare and Akamai. CDN support may land before your framework ships it. That is not a coincidence. Caching is where QUERY pays off the most.

Discovery. The RFC also defines a response header, Accept-Query. A server uses it to announce that an endpoint supports QUERY and which formats it accepts. So clients and tools can detect support instead of guessing.

How our apps will change

This is the part I find more interesting than the spec itself. The migration is not just renaming a method. Some habits and workarounds simply stop making sense.

1. The fake POST endpoints disappear

Every /search, /filter, /reports endpoint that uses POST today is a QUERY endpoint waiting to happen. The body stays identical. Only the method changes:

// before
axios.post('/api/search', filters)

// after
axios.request({ method: 'QUERY', url: '/api/search', data: filters })

This will be the first and easiest migration in most codebases.

2. Retry logic gets simpler

Today, if a POST search times out, most clients do not retry. They can't. Maybe the server already processed it. So we write error screens and "try again" buttons.

With QUERY, clients and SDKs can retry automatically. The request is idempotent by contract. A whole category of defensive code in mobile apps and flaky-network handling gets thinner.

3. Caching layers move down the stack

Right now, caching a POST search means building it yourself. Redis, cache keys hashed from the body, invalidation logic. Application code.

With QUERY, the CDN can do it. Same body, same cached response, standard HTTP semantics. A lot of hand-rolled cache layers will quietly get deleted.

4. GraphQL gets a proper home

Every GraphQL query today travels over POST, even though almost all of them are pure reads. That is the most visible version of this problem. QUERY gives GraphQL correct semantics without touching the query language. Expect GraphQL clients and servers to adopt it early.

5. URLs get readable again

We have all seen this:

GET /products?filters=%7B%22category%22%3A%22shoes%22%7D&sort=price

JSON, URL-encoded, jammed into a query param because the framework offered nothing better. Those endpoints migrate to QUERY and the URL goes back to being just /products. Cleaner logs too. Query bodies do not end up in access logs and bookmarks the way URLs do.

6. Reading an API becomes self-documenting

When the method itself tells you if an endpoint reads or writes, documentation gets lighter and integration mistakes go down. New devs on your team stop asking "does this POST actually change anything?"

What I would do now

Nothing dramatic. But you can prepare:

Audit your API. List every POST endpoint that only reads. Those are your future QUERY endpoints.
Check your infra. WAFs, proxies and method whitelists that would block an unknown method.
Watch your framework's releases through 2026 and 2027.
If you control both client and server, nothing stops you from experimenting now with a small middleware.

Twenty years for a new HTTP method. The migration will take a while. The direction is already clear.

Rust Ate the JavaScript Toolchain. Then Cloudflare Bought It

Andrés Clúa — Fri, 26 Jun 2026 15:37:11 +0000

I run Vite on almost everything. Astro sites, Nuxt projects, a small group of libraries I maintain on the side. The build tool is the part of the stack I think about least, because it just works.

So when the thing under all of that changes twice in three months, I read the release notes properly.

Here is what actually changed, what breaks, and the part that made developers argue for a week straight.

For Five Years, Vite Ran on Two Bundlers

When Vite launched, it made a pragmatic bet. esbuild for the dev server, because it is fast. Rollup for production, because its output is well optimized. Two tools, two jobs.

It worked. But it had a cost. Two bundlers meant two configs, two sets of quirks, and output that could drift between dev and prod. You tuned one, and the other behaved slightly differently.

Vite 8 ends the split. It shipped on March 12 with a single bundler called Rolldown, written in Rust, with the Rollup plugin API on top. Under Rolldown sits Oxc, a Rust parser and transformer that does the TypeScript and JSX work Babel used to do.

One language. One pipeline. Dev and prod finally agree.

This Is a Pattern, Not a One-Off

esbuild (Go) made webpack look slow. Bun did the same to Node for some workloads. Biome replaced Prettier and ESLint and runs many times faster. Now Rolldown does it to Rollup and esbuild at the same time.

Every time a core JavaScript tool gets rewritten in a compiled language, the same thing happens. The speed jump is large enough to make the old version look broken.

The interesting part is not the speed. It is the compatibility.

These Rust tools do not ask you to relearn your stack. Rolldown speaks the Rollup plugin API. Biome follows ESLint and Prettier conventions. The migration is designed to be boring, and boring is the point.

The Numbers, With a Grain of Salt

The headline figure is real. Linear cut its production build from 46 seconds to 6. Vite reports builds 10 to 30 times faster than the old Rollup path. Other large projects report 3x to 8x.

I treat these like any benchmark. Your build is not Linear's build.

A small marketing site will not see a 40 second drop, because it never had a 40 second build in the first place. The gains land hardest where you were already hurting: big dependency graphs, slow CI, painful full reloads. If your build finishes in four seconds today, this is a nice-to-have, not a rescue.

Still, the scale matters. Vite sits around 130 million weekly downloads. Changing its bundler changes a large slice of the web's tooling in a single release.

What Actually Breaks

This is the part the launch posts skip. Most projects upgrade with a version bump. Some do not. Here is what I would check before touching production.

Plugins that call transformWithEsbuild will fail. esbuild is no longer bundled. You move to transformWithOxc, or you install esbuild yourself as a peer dependency.

A few more sharp edges:

build.rollupOptions is renamed to build.rolldownOptions
CJS interop behaves differently in some setups
Yarn PnP projects have reported friction

The safe path is two steps, not one. First, swap vite for the rolldown-vite package while you are still on Vite 7:

# step 1: stay on Vite 7, swap the bundler underneath
npm install rolldown-vite@latest

# run your build, check plugins, diff the output
npm run build

Then, once that is green, take the major:

# step 2: upgrade to Vite 8
npm install vite@8

This separates the bundler change from the major version change. If something breaks, you know which one did it.

Real wins, real edges. Not magic.

Then Cloudflare Bought the Whole Thing

Now the part that lit up Hacker News.

On June 4, Cloudflare acquired VoidZero, the company Evan You founded to build this toolchain. Vite, Vitest, Rolldown, and Oxc all come with it. The whole team joins Cloudflare. Evan You stays in charge of the open-source roadmap.

The pledges are what you would expect. The projects stay MIT-licensed and vendor-neutral. No Cloudflare-only features land in core Vite. Cloudflare put one million dollars into an independent Vite ecosystem fund for maintainers outside both companies.

I also read the why. Evan You was honest that VoidZero had a money problem: huge adoption, no clear revenue. The team had tried a mixed license model, and was already building a Vite-native deploy platform on top of Cloudflare before the talks (SiliconANGLE has the details). The acquisition solves the funding question in one move.

The Part Worth Arguing About

Here is what makes me pause, and it is not the build tool.

This is the second time in six months Cloudflare has bought its way into foundational web tooling. It acquired the Astro team earlier this year, with the same promises: open source, MIT, portable, governed in the open.

So one company now sits very close to Vite, Vitest, Rolldown, Oxc, and Astro. The license is open. The governance is open. The pledges read well. But influence is not the same as control, and the influence here is real.

I am not waving a flag about it. Cloudflare has kept its hands off so far, and putting money behind maintainers is genuinely good news. But "trust us, it stays neutral" is a promise, not a guarantee. The healthy move is to keep watching, not to panic.

Open source has always run on trust. This just concentrates more of it in one place.

Should You Upgrade?

For most projects: yes, and soon.

The migration is usually a version bump, with a compatibility shim covering most plugins
The speed gain is free once you are on it
Staying on the old pipeline is slowly turning into a CI tax

But move like an adult about it:

Test rolldown-vite in a branch first, then take Vite 8
Check any plugin that touches transformWithEsbuild or rollupOptions
If you run Yarn PnP, budget extra time

The Rust toolchain is here, it is faster, and the upgrade is less painful than most majors. The ownership question is a separate one. Adopt the tool on its merits, and keep an eye on who steers it.

So my take is simple. Try it. Give it a chance in a throwaway branch this week, before you have an opinion about it.

Faster builds are the easy win. But a single Rust pipeline that owns the whole thing opens a better question, and it is the one I actually care about.

If one tool now controls parsing, transforming, and bundling end to end, shouldn't our bundles be getting smaller too? That is the part I want to see next. Tell me in the comments if you are seeing it already.

Leading a Dev Team Is Not a Coding Job (In Some Cases). It Just Looks Like One.

Andrés Clúa — Tue, 09 Jun 2026 13:51:26 +0000

Everyone tells you the same thing when you move into leading a dev team. "Now you stop writing code." Cool. I get it.

I lead a dev team at a digital agency. Frontend, backend, client work, mixed stacks, real deadlines. So when I made that move, I had a pretty clear picture of what the job would be. I was mostly wrong about it.

What I thought the job was

I thought leading meant being the person who makes the hard technical calls.

The architecture decisions. The "should we use WordPress or go headless on this one" conversations. The hairy bug nobody else can crack. The code review where I catch the thing that would have blown up in production.

That was the real work in my head. Everything else felt like overhead.

That part of the job does exist. But it's maybe twenty percent of it. The other eighty is something nobody really prepares you for.

The first time someone got stuck

Early on, someone on the team hit a wall on a ticket. I looked at it and saw the fix in about thirty seconds. My hand was already moving to the keyboard.

Then it hit me. The right move depends on how clear it actually is to me.

If I have it crystal clear, fine, I fix it and move on. No ceremony. But if I have any doubt, that's the signal to not solve it alone. That's when we work it through together with the person who owns it, and sometimes it's worth pulling in someone else too. The doubt is not a weakness to hide. It's the most useful thing in the room, because it's exactly where the team learns something instead of just receiving an answer.

If I fix everything the second I see it, the bug is gone today and the person is no better next week. So now I check myself before grabbing the keyboard. Is this a thirty-second fix I can hand back with an explanation, or is this a "let's look at it together" moment. That single question reset how I think about the whole role.

The moment delegation starts working

Here's the part that genuinely surprised me with how good it feels.

When you start transmitting clear ideas, and the other side responds the way you would have done it yourself (or at least follows your work patterns at 80%), something clicks. You hand off a piece of a project, you brace for it to come back wrong, and instead it comes back right. Maybe better than right.

So you hand off a bigger piece. Then a whole feature. Then a whole project.

That's the addictive part of the job nobody warns you about. Not control. The opposite of control. Watching a thing you used to hold get done well without you in the loop. The first time it happens you almost don't trust it. After a while it's the most satisfying part of the week.

You start seeing who they really are

The more this happens, the more you start noticing the shape of each person.

One gets sharp on performance. Another is the one who actually enjoys untangling a messy data model. Someone turns out to be great at the client conversation you used to dread. These specializations don't show up in a job description. They show up over months, in small moments, and a big part of leading is just paying attention long enough to see them.

And then the job is to expose them. A retro is one of the best places for this. When someone solved something clever, I don't summarize it for them. I put them in front of the team and let them walk through it. People need to be seen for what they're good at, by the people they work with, not just by me in a 1:1. That visibility is fuel, and it's free.

Throwing people into the deep end

The harder version of this is putting people into situations you've already lived through.

I've been in plenty of those. Some I walked into well prepared. Plenty I learned the hard way, getting hit until I figured it out. Part of leading is deciding when to recreate that on purpose for someone else.

Sometimes it's planned. You give someone a project that's slightly above their current level because you've seen enough to know they'll rise to it. Sometimes it's a bit "a los golpes", you let them take a hit you could have softened, because the lesson only lands when it costs something.

The skill is calibration. Too easy and they don't grow. Too hard and you break their confidence instead of building it. You're constantly guessing where that line is for each individual person, and you don't always guess right.

The variable nobody puts in the spreadsheet

And here's the thing that makes all of this messy: people aren't constant.

When I decide who goes on which project, the technical fit is only half the equation. The other half is where the person is at. Someone coming off a brutal sprint shouldn't get dropped into the next firefight. Someone who just nailed something hard might be exactly ready for a stretch. Someone going through a rough patch outside work needs a different kind of ticket this month.

And personal situations cut both ways. Sometimes life outside work is a distraction that pulls someone off their game. Sometimes the work is the calm, the steady thing someone holds onto while everything else is moving. Reading which one it is, for which person, in which week, is part of the job too.

You can't put that in a staffing spreadsheet, but it's real, and ignoring it is how good people burn out on your watch. Skill, timing, morale, what else they're carrying, who they work well with. A lot of things matter, and most of them have nothing to do with code.

Here's the payoff for getting this right over time. Even when I have to be out for four days, the team holds. They respond at maybe 80% to how I've taught them, and the gap between that and 100% is mostly the screwups I made and learned from the hard way, the ones I can now spare them from repeating. That's the whole point of teaching instead of just fixing.

And to be fully honest, I've had a margin of comfort that not every lead gets. Part of my team has been solid for more than six years. There's a real bond there, in every sense, and I don't take it for granted. I hope it stays that way. A lot of what works isn't a system I designed. It's trust that took years to build.

It's not a promotion, it's a different job

This is the thing I'd tell anyone moving into it. Leading a dev team is not "senior engineer plus meetings." It's a career change that happens to keep the same job title.

The skills barely overlap. Being great at the code can even get in your way, because it makes the keyboard so tempting. The new job is teaching, reading people, knowing when to delegate, knowing when to expose someone and when to protect them, and keeping a group of humans pointed in the same direction. The code is the most visible part. It's not the part that needs you most.

The first time someone on the team builds something better than what I would have written, a small part of me wants to find a flaw in it. That reaction is the trap. If everything good has to come from me, the team has a ceiling, and the ceiling is me. The whole job is raising that ceiling above my own head. You're trying to make yourself the least impressive engineer on the team over time. That's success, not failure.

I used to think this was the boring half of the work. Now it's the part I find genuinely interesting, because it never gets "done." There's always another person to read, another call to calibrate, another thing to hand off and watch come back better than you left it.

If you're about to make this jump, go in knowing you're starting a new job, not getting a reward for the old one. The sooner you stop reaching for the keyboard, the sooner you're actually doing it.

Visual regression testing: the missing piece in your testing stack

Andrés Clúa — Wed, 06 May 2026 15:54:34 +0000

In agencies, testing exists but it's mostly manual. Someone opens the site before deploy, clicks around, checks the forms, makes sure nothing looks broken. Sometimes there are unit tests with Vitest or Jest. Sometimes there aren't, depending on the project and the deadline. When the deadline is in three days, automated testing is the first thing to go.

And inside that manual process, there's one type of testing that's almost impossible to do well by hand: visual.

I've been researching visual regression testing for a while. I built it in research projects, tried it on side experiments, read a lot. What strikes me most isn't the tool itself. It's how rarely it's used in agency work, compared to the problem it solves and how easy it's become to set it up.

I'm not here to tell you my team has it running in production and we're rockstars. I'm here to share what I learned researching it, hoping to save you the first few hours.

Why visual testing is the hardest

Think about the types of testing you know.

Unit tests with Vitest. They check that a function returns what it should. Fast, deterministic, easy to write.

Integration tests. Slower, more fragile, still manageable.

End-to-end. Slow, fragile, environment-heavy. Less common.

Visual. Checks that the site looks the way it should. And here everything breaks. What does "looks good" even mean? How do you express that as an assertion? expect(button).toBeVisible() tells you nothing about padding, color, border-radius, or how a component looks next to three others.

Visual testing breaks the mental model of "logical assertion over code". What you want to assert is perceptual, not logical. That's why most stacks skip it.

What VRT actually does

It solves the problem indirectly. Instead of describing how something "looks good", it compares screenshots. You take a baseline, take another after a change, compare pixel by pixel. If the diff goes over a threshold, the test fails.

Not elegant in theory. Pragmatic and it works.

This catches the bugs every agency knows. You change a Tailwind variable, touch a design system component, update a UI dependency. Unit tests pass. Lighthouse passes. Site goes live. Days later a client reports the secondary button has a thicker border, or the footer lost its padding.

Why it's barely used

Four reasons, none technical.

First, agency testing is mostly manual. The human eye is bad at catching subtle visual changes. Nobody notices a padding going from 16 to 14 pixels during a quick walkthrough on a Friday afternoon. And since the manual process is already in place and "works", nobody questions what it systematically misses.

Second, the first attempt always fails. Someone sets it up on a Friday, by Monday the pipeline is red with 20 false positives, the team disables it, it dies in the repo.

Third, the team learning curve. Not because it's complex, but because every dev needs to understand baselines, when to update them, how to review diffs in a PR. If only one person gets it, it doesn't scale.

Fourth, and this one bothers me the most. Most content on the topic is written by SaaS vendors (Percy, Chromatic, Applitools) selling their product. They tell you it's complex, you need their tool, self-hosted doesn't scale. It's not true. Playwright ships everything you need.

The stack that makes sense

Playwright for running tests and comparing screenshots
GitHub Actions for CI
Screenshots versioned in your repo
A masking convention for dynamic content

No external services. No licenses. All inside your repo.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './tests/visual',
  expect: {
    toHaveScreenshot: {
      maxDiffPixelRatio: 0.01,
      threshold: 0.2,
    },
  },
  projects: [
    { name: 'mobile', use: devices['iPhone 13'] },
    { name: 'desktop', use: { viewport: { width: 1440, height: 900 } } },
  ],
})

A base test:

import { test, expect } from '@playwright/test'

const pages = ['/', '/about', '/services', '/contact']

for (const path of pages) {
  test(`visual: ${path}`, async ({ page }) => {
    await page.goto(path)
    await page.waitForLoadState('networkidle')
    await page.evaluate(() => document.fonts.ready)

    const name = path === '/' ? 'home' : path.replace(/\//g, '-')
    await expect(page).toHaveScreenshot(`${name}.png`, {
      fullPage: true,
      mask: [page.locator('[data-vrt-mask]')],
      maskColor: '#808080',
    })
  })
}

Setup is faster than ever

Two years ago, building this stack from scratch was two or three days of focused work. Today, with current codegen tools, it takes a couple of hours if you know what to ask for. The barrier dropped. The knowledge of what to ask for is still critical. If you don't know you need document.fonts.ready before the screenshot, no tool will suggest it without context.

Here's the prompt I use to scaffold it on new projects:

I need visual regression testing in this project.

Stack: [Nuxt 3 / Next.js / WordPress / whatever]
CI: GitHub Actions

Implement:

1. Install Playwright as dev dependency. Configure Chromium only.

2. Create `playwright.config.ts` with two projects: mobile (iPhone 13)
   and desktop (1440x900). Threshold 0.2, maxDiffPixelRatio 0.01.

3. Create `tests/visual/pages.spec.ts` iterating over the main public
   routes. For each route:
   - Wait for networkidle
   - Wait for document.fonts.ready
   - Scroll to bottom to force lazy loading
   - Disable animations via injected CSS
   - Take fullPage screenshot, masking [data-vrt-mask] elements
     with maskColor #808080

4. Create `.github/workflows/visual-regression.yml` that:
   - Runs on every PR
   - Shards by project (mobile, desktop)
   - Caches node_modules and Playwright browsers
   - Uploads playwright-report as artifact on failure
   - Does NOT auto-update baselines

5. Add scripts to package.json:
   - `test:visual` to run tests
   - `test:visual:update` to update baselines locally

6. Document in `tests/visual/README.md`:
   - How to run tests locally
   - When and how to approve new baselines
   - The [data-vrt-mask] convention

Do not install Percy, Chromatic, or external services.
Self-hosted with Playwright only.
```

`

Drop it into your AI tooling at the repo root and the scaffold comes out in one pass. The prompt isn't the point. Understanding why each decision is there is.

## Masking dynamic content: where it all breaks

This is by far the hardest part of the whole setup. Everything else you can build in an afternoon. Masking can take weeks of fine-tuning if your site has any real complexity.

An honest list of the enemies:

- **Dates and timestamps**. "3 hours ago", "Published May 5, 2026". They change every run.
- **Sliders and carousels**. They start in different positions, change height when slide content has different size, often have autoplay you can't easily disable.
- **Animations and transitions**. A 400ms fade-in produces a different screenshot at ms 200 vs ms 600. Multiply by every component using `motion-safe` or GSAP.
- **WYSIWYG content**. The client edits CMS text and breaks your test. But you can't mask the whole block or you're testing nothing.
- **Lazy-loaded images**. Depending on browser request order, the page has different heights mid-render. Full-page screenshots come out different each time.
- **External iframes**. YouTube, Vimeo, maps, Calendly, chat widgets. Different load times, rotating content.
- **Cookie banners, A/B tests, geolocation**. The site the CI bot sees isn't the site you see, and sometimes it's not even the same between two runs.
- **Skeletons and loading states**. Capture early, you see the skeleton. Capture late, you see the data. Both valid, both break the test.
- **Async fonts (FOUT/FOIT)**. Screenshot before fonts load, you get Arial. After, you get Inter. Catastrophic diff.
- **Real-time counters**. Any "1,234 users online" widget guarantees a false positive every run.

False positives are worse than no tests. They train the team to ignore warnings. Two months in, nobody reads the reports and the setup dies.

The rule that worked for me: anything with genuinely dynamic content gets a `data-vrt-mask` attribute. Not tooling magic, team discipline:

```vue
<template>
  <article class="post">
    <h2>{{ post.title }}</h2>
    <time data-vrt-mask>{{ post.publishedAt }}</time>
    <YouTubeEmbed data-vrt-mask :id="post.videoId" />
    <HeroSlider data-vrt-mask />
    <p>{{ post.excerpt }}</p>
  </article>
</template>
```

Playwright paints that region a neutral gray (`#808080`) before comparing. The rest gets compared pixel by pixel.

Use neutral gray, not Playwright's default magenta. When a dev opens a report with 15 diffs and half are screaming magenta blocks, their brain enters alarm mode and approves everything in a hurry. Neutral gray makes real diffs pop and masked regions disappear visually.

For animations, the highest-impact trick is killing them globally during the test:

```typescript
await page.addStyleTag({
  content: `
    *, *::before, *::after {
      animation-duration: 0s !important;
      animation-delay: 0s !important;
      transition-duration: 0s !important;
      transition-delay: 0s !important;
    }
  `,
})
```

This single line eliminates half the false positives.

For lazy images, force-scroll to the bottom before capturing. It's ugly. It works. Put it in a helper and never look at it again.

## Baseline approval

When a diff appears, someone decides if it's a bug or an intentional change. The common mistake is letting each dev approve their own baselines locally with `--update-snapshots` and committing the result. In three months you have approved baselines hiding real bugs. Someone shipped a broken margin, approved it, now it's the official state. Test passes green and lying.

What works:

1. Baselines update via PR. Never direct commit to main.
2. The PR shows visual diffs as artifact.
3. At least one reviewer who isn't the author.

```yaml
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/
    retention-days: 14
```

## When it's not worth it

If your site barely changes, one client, monthly deploys, the overhead isn't worth it. Baseline maintenance is real work.

If you have a shared design system across multiple clients, deploy several times a week, and every visual bug means an awkward conversation with a client lead, this is the best thing you'll add this year.

VRT doesn't catch logic bugs, accessibility bugs, or performance issues. It doesn't replace unit tests if you have them. It doesn't replace manual QA on critical flows like checkout or login. It's one more layer, the one covering the gap the others leave and the human eye misses worst.

## Closing

Visual regression testing is one of those tools that, when you look at it closely, you wonder why everyone isn't using it. The answer is a mix of inertia, vendor-driven content bias, and the fact that the first attempt always fails.

Visual testing remains the hardest. And it's still mostly done by hand, which in practice means it's not done at all. With today's tooling, the barrier to entry is gone. What's left is the decision.

I don't have the perfect recipe because I don't have it running in production yet. But after researching it deeply, I'm convinced any agency with a shared design system and frequent deploys should have this. And the self-hosted Playwright setup is fully viable, contrary to what the SaaS vendors want to sell you.

I'm starting to roll it into a project soon. If you already use it in production and learned things this article doesn't cover, write them. We need more honest content on this.

Claude Code, the Pricing Gap, and the Rise of Build-Your-Own AI

Andrés Clúa — Fri, 24 Apr 2026 14:03:44 +0000

On April 21, 2026, Anthropic quietly removed Claude Code from its $20 Pro plan. No email, no announcement, no changelog. People noticed because the pricing page changed overnight. A few hours later it got reverted, and Anthropic's Head of Growth posted on X that it was a test on 2% of new signups.

Simon Willison wrote the best account of what happened. He pays for Claude Max himself and is not exactly a hater. His point is simple: the revert doesn't matter. What matters is that Anthropic considered it.

The experiment got pulled. The signal didn't.

It is going to get more expensive

Claude Code is back in Pro today. But if you zoom out a bit, the direction is obvious.

GitHub did the same thing on the same day with Copilot. Earlier in April, Anthropic blocked third-party tools from running on Pro and Max subscriptions. Enterprise plans moved to per-token billing. Weekly caps got tighter. Peak-hour limits got stricter.

Claude Code already makes Anthropic billions of dollars a year. The company just raised $30B. This is not a company in crisis. It is a company figuring out how to charge more for the people who use it the most.

The logic makes sense from their side. From ours, it means one thing: the tool we built our workflow around can change price on us overnight, and there is nothing we can do about it.

The gap nobody talks about

A hundred dollars a month in San Francisco is not a hundred dollars a month in Bilbao, Buenos Aires, Lagos, or Jakarta. It is not the same for a two-person agency billing in euros, or a freelancer on a retainer, or a bootstrapped startup watching runway.

Most of the AI tooling conversation assumes one user: a well-paid dev at a US tech company. For that person, $100/month is noise. For a lot of working developers, it adds up fast. An agency with 15 devs on Max is $18,000 a year, and that is before you count Cursor, Copilot, or anything else.

But the price is not even the main problem. The main problem is depending on something you do not control. When your main tool can 5x its price on a Tuesday as a "test", you have a problem that is bigger than the bill.

You do not have to build anything from zero

When people hear "build your own AI" they imagine training a model, GPU clusters, a whole research team. That is not what this is about.

It is more like cooking at home instead of eating out every day. You do not have to grow the wheat to make bread. You buy the pieces, you put them together, you eat.

The pieces already exist. There are solid open-source models you can run locally or use through an API for a fraction of what Claude costs. There are tools like Ollama that make running one of these models about as hard as installing an app. There are terminal workflows like OpenCode that work similar to Claude Code but against whatever model you want.

The other piece, which is actually the important one, is your stuff. Your codebase, your docs, your conventions. That is the part nobody else has. That is what makes a generic model useful for the work you actually do.

When the big players go open, you should notice

If this still sounds like a fringe thing, look at Cursor.

Cursor is one of the most popular AI coding tools right now. They just launched their flagship model, Composer 2, positioning it as their own in-house thing. Less than 24 hours later, a developer named Fynn found a model ID in their API traffic that gave it away: Composer 2 is built on top of Kimi K2.5, an open-weight model from a Chinese lab called Moonshot AI.

Cursor confirmed it and later published a technical report admitting the Kimi base. VC Tomasz Tunguz made the point well: a $50B company reaches near-parity with state-of-the-art at a fraction of the price, running on an open model they did not build. That is not ideology. That is math.

If a company valued at $50B reached that conclusion, a dev in Bilbao or an agency in Madrid can reach it too. At a smaller scale, same idea.

It is not only about saving money

Cost is the easy argument. The more interesting part is what you gain when you control the model.

You can shape it to your work. A base model that you use on your own code and your own patterns gets better at your specific job, in a way a generalist model cannot, no matter how big it is.

Your code stays with you. Depending on what you work on, that is the difference between "we can use AI" and "legal says no".

No rate limits reset every Tuesday. No weekly caps. No versions deprecated on someone else's schedule. No experiment changing your plan overnight.

None of this makes Claude irrelevant. What it does is make Claude one tool in a stack, instead of the stack.

What to try

The gap between what you can run locally and what you pay a subscription for is smaller than most people think. If you have not looked at this in a year, you are working with outdated assumptions.

A reasonable starting point: install Ollama, pull a coding model, plug it into OpenCode or something similar, and take the next small task you would give Claude Code. Give it to the local setup instead. Notice where it falls short and where it surprises you.

You will find that for a lot of the routine stuff (boilerplate, refactors, small features, tests), local models are closer to what you pay for than the marketing lets on. For hard problems, you will still want a frontier model. That is fine. The point is not to replace Claude. The point is to stop depending on it.

If running local is not an option, the same logic works through APIs. There are providers selling access to these open models for a lot less than Anthropic charges.

Closing

The question in 2026 is not "cloud or local". It is "which model for which task, and who decides".

If Claude Code costs $100/month next week, what happens to how you work? If the answer is "everything breaks", that is not really an AI problem. That is a dependency problem. And it is true for every other tool in your stack.

The hedge is not loyalty. It is having a plan B. Spend a Saturday on it.

HTML in Canvas: The API That Could Change How We Build Interactive Experiences on the Web

Andrés Clúa — Fri, 17 Apr 2026 12:04:45 +0000

⚠️ Heads up before we start: Everything in this post is very experimental. HTML-in-Canvas is a proposal sitting behind a Chrome Canary flag (chrome://flags/#canvas-draw-element).

My background is more related to frontend work and I've spent more time than I'd like to admit wrestling with <canvas> specifically trying to build rich interactive experiences that look great, behave accessibly, and don't feel like I was fighting the browser the entire time.

If you've built anything intense with canvas, interactive data dashboards, creative tools, game UIs, WebGL-heavy experiences you probably know the feeling. You get beautiful, performant rendering, but you trade away a lot: accessibility, interactive text, real form elements. The moment you step inside a <canvas>, the browser's layout engine waves goodbye and you're on your own.

So when a colleague shared the HTML-in-Canvas proposal from WICG with me, my first reaction was: wait, is this real?

The Problem Canvas Has Always Had

Canvas is great at pixel-perfect rendering, WebGL shaders, games, creative tools but it has a fundamental tension with the rest of the web platform.

When you render text in canvas, you lose:

Screen reader support
Native text selection
Proper i18n and font rendering (bidirectional text, ligatures...)
The browser's built-in hit testing

Chart libraries have been working around this for years, they either maintain a hidden DOM that mirrors the canvas (complex, fragile) or they just... give up on accessibility and... neither is great.

The same problem shows up in creative tools, in-game UIs, data visualization dashboards, video export features — any time you need the power of canvas but also want your content to behave like HTML.

What HTML-in-Canvas Proposes

The idea is surprisingly straightforward: let HTML elements live inside a <canvas> and get rendered into it, while still participating in the browser's layout, hit testing, and accessibility tree.

Three new primitives make this work:

1. The `layoutsubtree` attribute

You add this to a <canvas> element. It tells the browser: "treat my children as real layout participants." They go through normal CSS layout, they're in the accessibility tree, they can receive focus — but they're not painted directly to the screen. Their rendering is invisible until you explicitly draw them.

<canvas id="canvas" layoutsubtree>
  <form id="my-form">
    <label for="name">Name:</label>
    <input id="name" type="text">
  </form>
</canvas>

2. `drawElementImage()`

This is the key method. It takes a child element and draws it into the canvas context at the coordinates you specify. The browser handles the rendering fonts, borders, shadows, everything — and gives you back a CSS transform to keep the element's DOM position in sync with where it's actually drawn.

const ctx = document.getElementById('canvas').getContext('2d');

canvas.onpaint = () => {
  ctx.reset();
  const transform = ctx.drawElementImage(my_form, 100, 50);
  my_form.style.transform = transform.toString();
};

That transform return value is doing something important: it keeps the accessibility tree and hit testing aligned with what the user actually sees on screen.

3. The `paint` event

Instead of polling with requestAnimationFrame, you get a paint event that fires when any canvas child's rendering changes. You can also call requestPaint() to force it — similar to how rAF works.

canvas.onpaint = (event) => {
  // event.changedElements tells you exactly what changed
  event.changedElements.forEach(el => {
    ctx.drawElementImage(el, getX(el), getY(el));
  });
};

And for OffscreenCanvas in workers, there's captureElementImage() — which lets you snapshot an element and transfer it to a worker thread for rendering. That's a big deal for performance-heavy canvas work.

Why This Matters for Rich Interactive Experiences

Think about the kind of experiences that live in canvas today: game UIs, creative tools, interactive data dashboards, 3D scenes with 2D overlays, immersive web experiences with custom controls. They all share the same pain: the moment you need real UI a tooltip, a form, a menu, styled labels you either fake it with canvas drawing primitives or you layer DOM elements on top and pray the positioning stays in sync.

With HTML-in-Canvas, you could just... write HTML for that content. Real HTML, with real CSS. Drop it inside your canvas, call drawElementImage() in the paint event, and let the layout engine do the hard work.

Imagine building a WebGL scene where the HUD is actual HTML keyboard-navigable, screen reader accessible, styled with CSS. Or an interactive dashboard where the chart controls are real <input> elements rendered directly into the canvas surface, with proper focus management and no z-index hacks.

Multi-line text? CSS handles it. RTL content? The browser handles it. Accessibility for your in-canvas UI? It's already in the DOM for free.

Chart libraries also benefit here: axes, legends, and tooltips are all text-heavy and layout-sensitive. Today they reimplement font measurement and text wrapping from scratch. With this API, they could delegate that entirely to the browser. But honestly, the more exciting territory is the interactive, immersive stuff the experiences that currently feel like you're building against the platform instead of with it.

An Idea: What If Someone Built a Wrapper?

Here's where I want to be clear: this is speculation, not an announcement but I've been thinking about it and OGL is a fantastic example of what a well-designed thin wrapper looks like. It doesn't try to be Three.js it just makes WebGL less painful without hiding what's happening underneath. You still think in WebGL concepts; it just removes the boilerplate.

Something similar for HTML-in-Canvas could be interesting. Imagine a small library maybe 5-10KB that handles:

The layoutsubtree setup and resize observer wiring
A declarative way to bind elements to canvas positions
The transform synchronization so hit testing always works
A simple reactive paint loop

Usage might look something like this (pure speculation):

import { CanvasScene } from 'html-canvas'; // hypothetical

const scene = new CanvasScene('#my-canvas');

scene.add('#chart-legend', { x: 20, y: 20 });
scene.add('#chart-tooltip', { x: 'dynamic', y: 'dynamic' });

scene.onpaint(({ draw }) => {
  draw('#chart-legend');
  draw('#chart-tooltip', getTooltipPosition());
});

The API surface would stay small. No magic, no virtual DOM, no framework opinion. Just a thin layer that handles the sync complexity so you can focus on what you're building.

It could be a genuinely useful side project once the API stabilizes. For now it's just an interesting thought experiment — but the kind that's worth keeping in the back of your mind.

Should You Try It?

If you're curious: yes, absolutely. Enable the flag in Chrome Canary, clone the WICG repo, and play with the demos. There's a pie chart example, a WebGL cube with HTML on its surface, and an interactive form drawn into canvas. They're genuinely cool.

But calibrate your expectations:

This is a proposal, currently in a dev trial in Chrome Canary only
The API will change — possibly significantly
No other browser has signaled implementation yet
There are real constraints (no cross-origin content, no system colors, etc.)

The right move today is to watch it, experiment in throwaway projects, and maybe file some issues if you hit interesting edge cases, I'm pretty sure the team is actively looking for feedback.

Have you hit the canvas + accessibility wall before? I'd love to hear how you've worked around it drop it in the comments.

Web Performance Is an Architecture Decision, Not a Last-Minute Fix

Andrés Clúa — Mon, 13 Apr 2026 14:08:51 +0000

I work at a digital agency and lead the tech side. One thing we try to get right from day one is performance. Not because we're obsessed with Lighthouse scores. Because we've learned that performance problems don't come from bad code. They come from bad decisions made early in the project.

The CMS you choose. How you handle third-party scripts. Whether you serve videos as raw iframes or defer them. How your CSS is loaded. Where your assets live.

These are architecture decisions. And once they're made, they're expensive to undo.

The Pattern We Try to Avoid

Here's what happens on a lot of projects across the industry. A site launches. The design looks great. Then someone runs a Lighthouse audit and the score is 43. Panic. Everyone wants to "fix performance" like it's a bug you can patch on a Friday afternoon.

It's not a bug. It's the consequence of choices nobody questioned months ago.

We try not to end up there. That means asking the uncomfortable questions at the kickoff, not at the QA stage. It means pushing back sometimes. And it means being honest about what certain tools and platforms cost you in performance before you commit to them.

Your CMS Choice Is a Performance Decision

This is the one that doesn't get enough attention. People choose a CMS based on features, familiarity, or client preference. Performance rarely enters the conversation. But it should. Because some platforms give you a head start and others put you in a hole from the beginning.

A headless CMS like Sanity, Contentful, or Storyblok gives you full control over the frontend. You decide what gets loaded, when, and how. There's no theme layer injecting scripts you didn't ask for. No plugin ecosystem silently adding database queries and stylesheets on every page load.

WordPress can absolutely be fast. I've built fast WordPress sites. But it takes discipline. The default experience is a theme that loads everything everywhere, a page builder that inlines CSS for every block variation, and a plugin for every feature that each adds its own JavaScript and stylesheet. Out of the box, a typical WordPress site with a popular theme, a form plugin, an SEO plugin, and a slider is already shipping 2MB+ of assets before you add any actual content.

That doesn't mean WordPress is bad. It means you have to fight harder for performance on WordPress than on a headless setup. And if you're not aware of that going in, you'll end up with a 43 on Lighthouse wondering what happened.

The honest breakdown from what I've seen:

Headless CMS (Sanity, Contentful, Storyblok): You own the frontend. Performance is in your hands. The CMS doesn't inject anything into your build. If it's slow, it's your fault. That's actually a good thing.

WordPress: Can be fast, but requires intentional architecture. Block themes perform better than classic themes. Avoid heavy page builders if performance matters. Audit every plugin. Know what each one adds to the page weight.

Monolithic platforms (Drupal, AEM, Sitecore): Similar challenges to WordPress but at enterprise scale. More moving parts. More potential for bloat. Performance is achievable but requires dedicated effort and expertise.

Static site generators (Astro, Nuxt, Next.js in SSG mode): The fastest option by default because you're serving pre-built HTML. But the moment you start adding client-side interactivity and third-party scripts, you can still ruin it.

The point is not that one CMS is better than another. The point is that the CMS decision is a performance decision, and it should be evaluated as one.

The YouTube Embed Problem

Here's a concrete example that comes up constantly. A client site scoring poorly on Core Web Vitals. We investigate. The biggest offender? YouTube embeds.

A standard YouTube iframe loads around 800KB of JavaScript before the user even clicks play. That's one embed. Put four on a page and the browser is downloading over 3MB of scripts for videos most visitors will never watch.

LCP tanks. INP suffers because the main thread is busy parsing scripts nobody asked for. The page feels slow because it is slow.

The fix: don't load the iframe until the user wants to watch. Show a placeholder. Load on click. Reserve the space with aspect-ratio: 16/9 so there's no layout shift.

This is one of the things I built Boostify.js to solve. Instead of dropping a raw YouTube iframe in your markup, you set up a container and let Boostify handle the deferred loading:

<div
  class="js--boostify-embed"
  style="aspect-ratio: 16/9;"
  data-url-youtube="https://www.youtube.com/embed/dQw4w9WgXcQ">
</div>

const bstf = new Boostify();

document.querySelectorAll('.js--boostify-embed').forEach(element => {
  bstf.videoEmbed({
    url: element.getAttribute('data-url-youtube'),
    autoplay: true,
    appendTo: element,
    style: { height: "auto" }
  });
});

Zero bytes of YouTube JavaScript loaded until the user interacts. The space is reserved so no layout shift. The page loads as if the video isn't there. When the user clicks, the embed loads instantly.

This needs to be a default in your component library, not a fix applied after someone complains about the Lighthouse score.

Third-Party Scripts: The Invisible Weight

YouTube is obvious because you can see it. But the worst offenders are invisible.

Google Analytics. Facebook Pixel. Hotjar. Microsoft Clarity. HubSpot tracking. LinkedIn Insight Tag. Cookie consent banners. Chat widgets. A/B testing tools.

On a typical site, I've counted 8 to 12 third-party scripts loading on every page. Each one competes for the main thread. Each one makes network requests. Each one adds weight.

None of these are critical for the user's first interaction. The user came to read content, check services, fill out a form. They didn't come so Hotjar could record their session before the page renders.

But these scripts are usually dropped straight into the <head>. Render-blocking. Loading before your actual content.

<!-- What I see on most sites when I open the source -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>
<script src="https://connect.facebook.net/en_US/fbevents.js"></script>
<script src="https://static.hotjar.com/c/hotjar-XXXXX.js"></script>
<!-- The page hasn't started rendering yet -->

With Boostify, you mark your tracking scripts with type="text/boostify" instead of type="text/javascript". The browser ignores them on load. Boostify picks them up and loads them only after the user interacts with the page (mouse move, scroll, touch).

<!-- Deferred until user interaction -->
<script type="text/boostify" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>

const bstf = new Boostify();

bstf.onload({
  worker: true,
  callback: (result) => {
    console.log('Third-party scripts loaded after user interaction');
  }
});

Your content renders immediately. Analytics loads quietly in the background when the user is already engaged. You might lose tracking on 1-2% of ultra-fast bounces, but your site is faster, which typically increases conversions overall.

My recommendation: consolidate everything into a single Google Tag Manager container, mark that one script with type="text/boostify", and let GTM handle all your tags internally. One deferred script instead of twelve blocking ones.

Loading the Right Thing at the Right Time

The onload trigger handles the global stuff like analytics and tracking. But a real page has more than that. It has a slider halfway down. A contact form with a map at the bottom. An interactive widget in a section most users never scroll to.

This is where Boostify's scroll and observer triggers come in, and where things get interesting when you combine them.

Scroll trigger: fire a callback when the user scrolls past a certain distance. Good for loading resources that you know the user will need soon, like a slider component just below the fold.

bstf.scroll({
  distance: 200,
  callback: async () => {
    // Load slider CSS and JS only when user starts scrolling
    await bstf.loadStyle({
      url: 'https://cdnjs.cloudflare.com/ajax/libs/tiny-slider/2.9.4/tiny-slider.css',
      attributes: ['media=all'],
      appendTo: 'head'
    });
    await bstf.loadScript({
      url: 'https://cdnjs.cloudflare.com/ajax/libs/tiny-slider/2.9.2/min/tiny-slider.js',
      attributes: ['type="text/javascript"'],
      appendTo: 'body'
    });

    // Initialize once loaded
    tns({
      container: '.my-slider',
      items: 3,
      slideBy: 'page',
      autoplay: true
    });
  }
});

Observer trigger: fire a callback when a specific element enters the viewport. This uses the Intersection Observer API under the hood. Perfect for content further down the page that may or may not be reached.

bstf.observer({
  options: {
    root: null,
    rootMargin: '0px',
    threshold: 0.01
  },
  element: document.querySelector('.contact-section'),
  callback: async () => {
    // Load the map embed only when the contact section is visible
    bstf.videoEmbed({
      url: 'https://www.google.com/maps/embed?pb=YOUR_MAP_EMBED',
      appendTo: document.querySelector('.map-container'),
      style: { height: '400px' }
    });
  }
});

The real power is using all three together. Think about a typical landing page:

const bstf = new Boostify();

// 1. Analytics and tracking: defer until first user interaction
bstf.onload({ worker: true });

// 2. Below-the-fold slider: load when user starts scrolling
bstf.scroll({
  distance: 300,
  callback: async () => {
    await bstf.loadStyle({ url: '/css/slider.css', appendTo: 'head' });
    await bstf.loadScript({ url: '/js/slider.js', appendTo: 'body' });
  }
});

// 3. YouTube video in the middle: load when its section is visible
bstf.observer({
  element: document.querySelector('.video-section'),
  options: { threshold: 0.01 },
  callback: () => {
    bstf.videoEmbed({
      url: 'https://www.youtube.com/embed/dQw4w9WgXcQ',
      autoplay: true,
      appendTo: document.querySelector('.video-container'),
      style: { height: 'auto' }
    });
  }
});

// 4. Contact form with map: load only if user reaches the bottom
bstf.observer({
  element: document.querySelector('.contact-section'),
  options: { threshold: 0.01 },
  callback: async () => {
    await bstf.loadScript({ url: '/js/form-validation.js', appendTo: 'body' });
    await bstf.loadStyle({ url: '/css/form.css', appendTo: 'head' });
  }
});

On initial page load, the browser downloads your HTML, your critical CSS, and your above-the-fold content. That's it. Everything else loads exactly when it's needed.

This isn't micro-optimization. On a page with a slider, two video embeds, a map, and eight tracking scripts, the difference between loading everything upfront and loading it progressively can be 4-5MB of JavaScript. That's the difference between a 2-second load and an 8-second load on mobile.

And it's an architecture decision. You set it up once in your component system. Every page benefits from it automatically.

CLS: Where Your CMS Shows Its True Colors

Cumulative Layout Shift exposes bad architecture more clearly than any other metric.

You know the experience. You're about to click a button and the page jumps because something loaded above it. A font swaps in and the layout shifts. An image loads without dimensions and pushes everything down.

This is where CMS choice really matters. A good CMS setup enforces constraints that prevent CLS. A bad one lets editors do whatever they want and hopes for the best.

If your CMS lets editors drop iframes anywhere without aspect ratio containers, you'll have CLS problems. If your theme doesn't enforce image dimensions, you'll have CLS problems. If your font loading strategy is "link to Google Fonts in the head," you'll have CLS problems.

The fix isn't a CSS hack after launch. It's building the system so these issues can't happen.

/* Defaults that should exist in every project */
img, video {
  max-width: 100%;
  height: auto;
}

.embed-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

On a headless setup, you control the component layer. You can enforce these patterns at the component level. On WordPress, you need to be more careful with theme defaults and block output. On page builder-heavy setups, good luck.

INP: The Metric That Exposes JavaScript Bloat

Interaction to Next Paint replaced First Input Delay in 2024. It's harder to pass because it measures the responsiveness of all interactions, not just the first one.

That hamburger menu that takes 400ms to respond? INP catches it. The accordion that freezes before opening? INP catches that too.

In 2026, pages at position 1 on Google show a 10% higher Core Web Vitals pass rate than those at position 9. Only 47% of sites reach Google's "good" thresholds across all three metrics. More than half the web is failing.

The most common INP killer is too much JavaScript on the main thread. Not just third-party scripts. First-party JavaScript too. Heavy page builders that inline JS for every component. Animations running on the main thread. Event listeners doing too much work synchronously.

This is another place where CMS architecture matters. A site built with a lightweight frontend framework on top of a headless CMS will naturally ship less JavaScript than a WordPress site running a page builder with 40 registered block types, each loading its own script.

And this is exactly why progressive loading matters. If you defer everything that's not immediately needed (using the onload, scroll, and observer pattern described above), the main thread is free to handle user interactions without competing for resources. INP improves because the browser isn't busy parsing tracking scripts and slider libraries while the user is trying to click things.

Performance Budgets at the Kickoff

I've never seen a creative brief that includes a performance budget. Not once across any project in any agency.

Nobody says "this page should load in under 2.5 seconds on a mid-range Android phone on 4G." But that's how Google evaluates your site. Mobile performance is the primary ranking signal. Even for desktop results.

53% of mobile visitors abandon a site that takes more than 3 seconds to load. A one-second delay reduces conversions by 7%. For a site generating $100K/month, that's $84K lost per year. For one second.

These numbers belong in every project kickoff. We try to set targets early:

LCP under 2.5s on mobile
INP under 200ms
CLS under 0.1
Total page weight under 1.5MB
No more than 3 third-party scripts loading before first paint

These aren't aggressive. They're the thresholds Google considers "good." Most sites don't hit them because nobody set them as a goal.

Field Data vs Lab Data

One more thing. Stop obsessing over Lighthouse scores in isolation.

Lighthouse is lab data. It runs in a simulated environment. It's useful for diagnostics. But Google ranks you based on field data. Real users on real devices with real network conditions.

Your Lighthouse score might be 90 because you tested on your MacBook with fiber internet. But your field data in Search Console might show real users on mid-range phones getting an LCP of 4.2 seconds.

Field data is what matters. Check your Core Web Vitals report in Search Console. That's the real score.

The Takeaway

Performance is not a task at the end. It's not a sprint before launch. It's not a plugin.

It starts with the CMS you choose and how you set it up. It continues with how you handle scripts, images, fonts, and video. It lives in your component architecture, your loading strategy, your defaults.

Some platforms make this easier. Some make it harder. Neither is inherently wrong, but you need to know the tradeoffs before you commit.

By the time someone opens DevTools and says "why is this so slow," the answer is usually "because we never decided it should be fast."

Make that decision early. Make it part of the architecture. Hold every choice accountable to it.

Boostify.js is free and open source. All the loading patterns described in this article (deferred third-party scripts, scroll triggers, observer-based loading, video embed placeholders) are available out of the box. Check it out on GitHub.

EmDash Is Not Your Next CMS. It Might Be the One After That

Andrés Clúa — Mon, 06 Apr 2026 17:20:55 +0000

Everyone is talking about EmDash. Serverless, sandboxed plugins, AI-first. Cool. I get it.

I work at a digital agency. We've been building on WordPress for years. Also Sanity, Contentful, Storyblok, Drupal, AEM. We've tried a lot. So when something new shows up, I don't get hyped that fast. I just want to know: can I use this for a real project?

We don't pick favorites

There's no "best CMS." Every project is different.

WordPress is a great tool, we build custom plugins, custom post types, REST API endpoints, tailored admin panels. It's not a blogging platform for us. It's a framework. So when people compare WordPress to newer tools by pointing at Gutenberg or starter themes... they're looking at one layer. That's not how we work with it.

Sanity is great when content modeling gets complex. Storyblok has a really nice visual editor that clients actually enjoy using. Contentful works when the client needs a clean API-first layer and doesn't want to deal with hosting. Drupal taught us a lot about structured content before headless was even a thing.

AEM is enterprise. Enterprise scale, enterprise money. It solves problems that other platforms don't even try to solve.

We picked each one for a reason.

What I like about EmDash

There are some ideas in EmDash that are genuinely interesting.

Serverless by default. No more dealing with PHP memory limits or server configs. That's nice.

Sandboxed plugins. Plugins run in isolation. No more "one plugin broke the whole site" at 2am. That alone is a big deal.

AI built into the core. Not a plugin wrapping an API. AI is part of the architecture. That opens up real possibilities for content generation and automation.

I like where this is going.

What makes me wait

But when I think about using #EmDash for a client project right now, there are a few things.

The ecosystem is basically empty. WordPress has thousands of plugins. Sanity and Contentful have mature integrations. EmDash is starting from zero. When you have a client deadline, that matters a lot.

It's developer-first. TypeScript, Astro, edge functions. And look, I love Astro. I still smile every time I see a project we built for UNDP in the Astro showcase. My team can work with all of that. But we also need to hand things over to marketing teams. They need to update pages and publish content without calling us every time. WordPress and Contentful have been refining that for years. EmDash hasn't.

It's tied to Cloudflare. WordPress runs on any hosting. Sanity and Contentful are SaaS. EmDash depends on the Cloudflare ecosystem. That's a dependency I'd think twice about for client work.

It takes longer to ship. We can go from kickoff to a working WordPress site with custom content types in days. With a new platform, there's always a learning curve. When a client has a launch date, that time gap is real.

It's not about good or bad

I'm not saying EmDash is bad. I think it's one of the most interesting things I've seen in the CMS space in a while. The architecture makes sense. The vision is clear.

But picking a CMS for client work is not just about architecture. It's about ecosystem, team readiness, how easy it is for the client, and whether this thing will still work in three years. Those things take time.

Where I'd try it

Internal projects. A proof of concept. Something where we control the timeline and the scope. That's how we've always adopted new tools. We learn them in low-risk contexts first.

If you care about developer experience, EmDash is worth exploring now. Not for your next client project. As a sandbox. Play with the serverless model, the plugin patterns, the AI workflows. The best time to learn a tool is before you need it on a deadline.

If the ecosystem grows, I can see EmDash sitting next to WordPress, Sanity, and Contentful in our toolkit. The ideas are solid. It just needs time.

One more thing

If you haven't tried Sanity, Contentful, Storyblok, or Drupal, go try them. Seriously. Yeah, 80% of content modeling feels the same across platforms. But that other 20% is where you learn things you wouldn't learn otherwise. Each one gives you a different perspective on how content should work.

AEM too, if you can afford the license. I'd say try it on something small, a personal project, just to see what's inside.

And here's something that would have sounded crazy two years ago: building your own CMS is actually possible now. With AI and a small team of solid developers who know how to use it, you can build exactly what you need. Your integrations. Your workflows. Ship features when you want, not when a vendor decides.

We're doing it. And once you have that freedom, it's hard to go back.

Maybe EmDash gets there. Maybe WordPress keeps evolving. Or maybe you just build your own thing. The point is we have more options than ever. And that's a good place to be.

WebGPU for Frontend Devs: A Practical First Project

Andrés Clúa — Wed, 18 Mar 2026 21:16:48 +0000

Most WebGPU tutorials go deep into theory or jump straight into 3D engines. If you are a frontend developer like me, that feels like learning to drive by reading the car manual.

This article is the opposite. We will build something visual, step by step, with zero GPU knowledge. By the end, you will have a real-time animated gradient running on your GPU — and you will understand every line.

What is WebGPU (in 30 seconds)

WebGPU lets your JavaScript talk directly to the GPU. Think about it like this:

Imagine you need to paint a wall. Your CPU is one very talented painter — fast, smart, and precise. But it paints one brushstroke at a time.

Your GPU is a team of 5,000 painters. Each one can only do simple strokes, but they all paint at the same time. Give them a wall with 2 million pixels? They split the work and finish in one pass.

WebGPU is the phone call that lets your browser hire that team of painters.

Browser support (March 2026)

Before we start — can your browser do this?

Browser	Status
Chrome/Edge	✅ Supported (since v113)
Firefox	✅ Supported (since v141)
Safari	✅ Supported (since 18.2)

Good news: all modern browsers support it now. For production, always check first:

if (!navigator.gpu) {
  alert("WebGPU is not supported in your browser");
}

What we are building

A full-screen animated gradient where the GPU decides the color of every pixel, 60 times per second. It looks like a lava lamp made of math.

No libraries. No frameworks. Just HTML, JavaScript, and a few lines of GPU code.

Step 1: The HTML (simple but necessary)

<!DOCTYPE html>
<html>
<head>
  <title>My First WebGPU Project</title>
  <style>
    body { margin: 0; overflow: hidden; }
    canvas { display: block; width: 100vw; height: 100vh; }
  </style>
</head>
<body>
  <canvas id="canvas"></canvas>
  <script src="main.js"></script>
</body>
</html>

Nothing new here — just a full-screen canvas. This is our "empty wall" that the GPU painters will fill.

Step 2: Connect to the GPU

Before the painters can work, you need to call the agency, confirm they are available, and give them the address. That is what this step does.

// main.js

async function init() {
  // 1. Check support
  if (!navigator.gpu) {
    throw new Error("WebGPU not supported");
  }

  // 2. Get an adapter (your physical GPU)
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw new Error("No GPU adapter found");
  }

  // 3. Get a device (your logical connection to it)
  const device = await adapter.requestDevice();

  // 4. Connect the canvas
  const canvas = document.getElementById("canvas");
  canvas.width = window.innerWidth;
  canvas.height = window.innerHeight;

  const context = canvas.getContext("webgpu");
  const format = navigator.gpu.getPreferredCanvasFormat();

  context.configure({ device, format });

  return { device, context, format, canvas };
}

What just happened — using our painting analogy:

adapter = finding the painting agency (your physical GPU)
device = signing the contract with them (your app's private connection)
context = giving them the key to the room where the wall is (connecting canvas to GPU)

This setup code is the same for every WebGPU project. Write it once, copy it forever.

Step 3: Write a shader (the fun part)

Now we need to give instructions to our painters. In GPU world, these instructions are called shaders — small programs written in WGSL (WebGPU Shading Language). The syntax looks like Rust, but simpler.

Think of a shader like a recipe card you give to each painter. Every painter gets the same recipe, but they each know their own position on the wall. So painter #4500 reads: "I am at position (200, 300). Based on this recipe, my color should be blue." All 5,000 painters follow the recipe at the same time, and the wall is painted in one pass.

For our gradient, we need a fragment shader — a recipe that takes a pixel position and returns a color.

const shaderCode = /* wgsl */`

  // A uniform is data we send from JavaScript to the GPU
  @group(0) @binding(0) var<uniform> time: f32;
  @group(0) @binding(1) var<uniform> resolution: vec2f;

  // Vertex shader: positions a full-screen triangle
  @vertex
  fn vertexMain(@builtin(vertex_index) i: u32) -> @builtin(position) vec4f {
    // A clever trick: 3 vertices that cover the entire screen
    let pos = array<vec2f, 3>(
      vec2f(-1.0, -1.0),
      vec2f( 3.0, -1.0),
      vec2f(-1.0,  3.0)
    );
    return vec4f(pos[i], 0.0, 1.0);
  }

  // Fragment shader: runs once PER PIXEL
  @fragment
  fn fragmentMain(@builtin(position) pos: vec4f) -> @location(0) vec4f {
    // Normalize coordinates to 0.0 - 1.0
    let uv = pos.xy / resolution;

    // Animated color channels using sine waves
    let r = sin(uv.x * 3.0 + time) * 0.5 + 0.5;
    let g = sin(uv.y * 3.0 + time * 0.7) * 0.5 + 0.5;
    let b = sin((uv.x + uv.y) * 2.0 + time * 1.3) * 0.5 + 0.5;

    return vec4f(r, g, b, 1.0);
  }
`;

Let me explain each part:

@vertex fn vertexMain — This draws a giant triangle that covers the entire screen. Think of it as stretching a canvas over the wall. It is a standard trick you will reuse in every full-screen effect.
@fragment fn fragmentMain — This is the recipe card. It runs once for every pixel. Each pixel receives its position and returns a color.
sin() with time — The sin function creates smooth waves. Adding time makes them move. Different speeds per color channel (red, green, blue) create that organic, shifting look.
uv — The pixel position, but normalized to a range of 0 to 1. Like a percentage: top-left is (0, 0), bottom-right is (1, 1). This way, the shader works on any screen size.

If you have used CSS gradients before, the idea is similar — but this one updates 60 times per second and you control everything with math.

Step 4: Set up the pipeline

We have the painters (GPU), the wall (canvas), and the recipe (shader). Now we need to put everything together — like a manager organizing the work before it starts. That is what the pipeline does.

It tells the GPU: "Here is the recipe, and here is the data you will need."

function createPipeline(device, format, shaderCode) {
  const shaderModule = device.createShaderModule({ code: shaderCode });

  // Create buffers for our uniform data (time + resolution)
  const timeBuffer = device.createBuffer({
    size: 4, // f32 = 4 bytes
    usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST,
  });

  const resolutionBuffer = device.createBuffer({
    size: 8, // vec2f = 2 × 4 bytes
    usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST,
  });

  // Bind group layout: tells the GPU what data to expect
  const bindGroupLayout = device.createBindGroupLayout({
    entries: [
      { binding: 0, visibility: GPUShaderStage.FRAGMENT, buffer: { type: "uniform" } },
      { binding: 1, visibility: GPUShaderStage.FRAGMENT, buffer: { type: "uniform" } },
    ],
  });

  // Bind group: connects our buffers to the shader's @binding slots
  const bindGroup = device.createBindGroup({
    layout: bindGroupLayout,
    entries: [
      { binding: 0, resource: { buffer: timeBuffer } },
      { binding: 1, resource: { buffer: resolutionBuffer } },
    ],
  });

  // The render pipeline
  const pipeline = device.createRenderPipeline({
    layout: device.createPipelineLayout({
      bindGroupLayouts: [bindGroupLayout],
    }),
    vertex: {
      module: shaderModule,
      entryPoint: "vertexMain",
    },
    fragment: {
      module: shaderModule,
      entryPoint: "fragmentMain",
      targets: [{ format }],
    },
  });

  return { pipeline, bindGroup, timeBuffer, resolutionBuffer };
}

Yes, this is a lot of code. That is the most common complaint about WebGPU. But if you look closely, it is just connecting things — like plugging cables into the right ports:

Compile the recipe → shaderModule
Create two small envelopes (buffers) to pass data to the painters: current time and screen size
Label the envelopes so the painters know which is which (bindGroup)
Put it all together in one package (pipeline)

The good news? This wiring is almost the same for every project. The creative part is always the shader.

Step 5: The render loop

Time to paint. But we do not paint once — we paint 60 times per second. Each frame, we update the time (so the colors move), tell the GPU to run the recipe, and repeat. It is like a flipbook: each page is slightly different, and together they create animation.

function startRenderLoop(device, context, pipeline, bindGroup, timeBuffer, resolutionBuffer, canvas) {
  // Send resolution to GPU (only needs to happen once, unless resized)
  device.queue.writeBuffer(
    resolutionBuffer, 0,
    new Float32Array([canvas.width, canvas.height])
  );

  function frame(timestamp) {
    // Update time (convert ms to seconds)
    device.queue.writeBuffer(
      timeBuffer, 0,
      new Float32Array([timestamp / 1000])
    );

    // Create the render command
    const encoder = device.createCommandEncoder();
    const pass = encoder.beginRenderPass({
      colorAttachments: [{
        view: context.getCurrentTexture().createView(),
        loadOp: "clear",
        storeOp: "store",
      }],
    });

    pass.setPipeline(pipeline);
    pass.setBindGroup(0, bindGroup);
    pass.draw(3); // 3 vertices = our full-screen triangle
    pass.end();

    // Submit to GPU
    device.queue.submit([encoder.finish()]);

    requestAnimationFrame(frame);
  }

  requestAnimationFrame(frame);
}

If you have used requestAnimationFrame before for Canvas 2D animations, this is the same idea. The only difference: instead of drawing with ctx.fillRect(), you write a command list and send it to the GPU. Think of commandEncoder as writing a to-do list, and device.queue.submit() as handing that list to the painters.

Step 6: Wire it all together

async function main() {
  const { device, context, format, canvas } = await init();
  const { pipeline, bindGroup, timeBuffer, resolutionBuffer } =
    createPipeline(device, format, shaderCode);

  startRenderLoop(device, context, pipeline, bindGroup, timeBuffer, resolutionBuffer, canvas);
}

main();

Open index.html in your browser. You should see a smooth, colorful gradient filling your screen — every single pixel computed by the GPU in real time. All 5,000 painters working together.

Make it your own

The shader is your playground. You can change the recipe and the painters will follow. Try replacing the color math inside fragmentMain:

Circular waves:

let dist = distance(uv, vec2f(0.5, 0.5));
let wave = sin(dist * 20.0 - time * 3.0) * 0.5 + 0.5;
return vec4f(wave, wave * 0.5, 1.0 - wave, 1.0);

Checkerboard morph:

let scale = 10.0;
let checker = step(0.5, fract(uv.x * scale + sin(time))) *
              step(0.5, fract(uv.y * scale + cos(time)));
return vec4f(checker, 1.0 - checker, 0.5, 1.0);

Noise-like pattern:

let n = fract(sin(dot(uv + time * 0.1, vec2f(12.9898, 78.233))) * 43758.5453);
return vec4f(n * 0.8, n * 0.4, n, 1.0);

Change one number, save, refresh. You will see the result immediately. This is the best way to learn — experiment and break things.

What you just learned

Here is a cheat sheet. Every WebGPU concept mapped to something you already know as a frontend developer:

WebGPU concept	Analogy
`adapter`	Finding which painting agency is available
`device`	Signing a contract with them
`shaderModule`	The recipe card you give to every painter
`buffer`	An envelope with data (time, screen size) for the painters
`bindGroup`	Labels on the envelopes so painters know which is which — like props in a component
`pipeline`	The full work plan: recipe + materials + instructions
`commandEncoder`	A to-do list you write before handing it to the painters
`device.queue.submit()`	Handing the to-do list and saying "go"
`requestAnimationFrame`	Same as always — the flipbook loop

When should you use WebGPU?

After building this, you might want to use the GPU for everything. Do not do that.

The GPU is like a factory: amazing for mass production, terrible for custom one-off work. Use the right tool for the job.

Use WebGPU when:

Processing thousands of pixels, particles, or data points at once
Running ML models in the browser
Building visualizations with 100k+ data points
Real-time image or video filters

Stick with JavaScript when:

DOM manipulation
Business logic and API calls
Anything that is not the same operation repeated thousands of times

Where to go from here

You now have the foundation. The setup code stays the same — from here, the fun is changing the recipe (shader). Some ideas:

Add mouse interaction — send mouse coordinates as another uniform, so the gradient reacts to your cursor
Compute shaders — use the GPU to process data, not just pixels (great for simulations)
Particle systems — combine vertex and fragment shaders to move thousands of objects
WebGPU Samples — official examples with more advanced patterns

Questions? Leave a comment — I will answer every one. If you built something cool by changing the shader, I would love to see it.

DEV Community: Andrés Clúa

The Problem Isn’t AI. It’s the Pace.

The race is worth running

Where I notice it in my own work

The honest version of "our brains cannot keep up"

Every generation said this

Which brings me to the letter

So what do we actually do

How to Tell If You Can Actually Drop Your Animation Library

The Demo Is Not the Migration

How this decision actually works

CSS can scrub. That was never the gap.

What CSS is genuinely great at

The refresh problem, which CSS simply does not have

Where it stops

Smoothed scrub

Real pinning

Orchestration

Progress in JavaScript

Responsive scene logic

The plugin surface

If you use Lenis, half of this changes

Where support actually stands

Run the audit yourself

If you run WebGL, one entry in that red column is different

The part that generalises

The Problem Isn’t AI. It’s the Pace.

The race is worth running

Where I notice it in my own work

The honest version of "our brains cannot keep up"

Every generation said this

Which brings me to the letter

So what do we actually do

HTTP Just Got Its First New Method in 20 Years. Here's Why You Should Care.

The problem in 30 seconds

What QUERY does

This pattern is going to change

Compatibility: where we are right now

How our apps will change

1. The fake POST endpoints disappear

2. Retry logic gets simpler

3. Caching layers move down the stack

4. GraphQL gets a proper home

5. URLs get readable again

6. Reading an API becomes self-documenting

What I would do now

Rust Ate the JavaScript Toolchain. Then Cloudflare Bought It

For Five Years, Vite Ran on Two Bundlers

This Is a Pattern, Not a One-Off

The Numbers, With a Grain of Salt

What Actually Breaks

Then Cloudflare Bought the Whole Thing

The Part Worth Arguing About

Should You Upgrade?

Leading a Dev Team Is Not a Coding Job (In Some Cases). It Just Looks Like One.

What I thought the job was

The first time someone got stuck

The moment delegation starts working

You start seeing who they really are

Throwing people into the deep end

The variable nobody puts in the spreadsheet

It's not a promotion, it's a different job

Visual regression testing: the missing piece in your testing stack

Why visual testing is the hardest

What VRT actually does

Why it's barely used

The stack that makes sense

Setup is faster than ever

Claude Code, the Pricing Gap, and the Rise of Build-Your-Own AI

It is going to get more expensive

The gap nobody talks about

You do not have to build anything from zero

When the big players go open, you should notice

It is not only about saving money

What to try

Closing

HTML in Canvas: The API That Could Change How We Build Interactive Experiences on the Web

The Problem Canvas Has Always Had

What HTML-in-Canvas Proposes

1. The layoutsubtree attribute

1. The `layoutsubtree` attribute

2. `drawElementImage()`

3. The `paint` event