Forem: RAXXO Studios

Claude's Next Model: Sonnet 4.8 and Mythos Rumors, Sorted

RAXXO Studios — Sun, 24 May 2026 13:26:49 +0000

Claude Opus 4.7 shipped 2026-04-16 and is the current public flagship, not a rumor
Claude Sonnet 4.8 is not announced, traced to one leaked string in Claude Code source
Claude Mythos exists and is real, but it is restricted to a handpicked group of companies
Anthropic conceded on 2026-04-16 that Opus 4.7 still trails its Mythos Preview model
Plan on Opus 4.7 and Sonnet 4.6 today, do not pause work for an undated model

The internet decided Claude has a secret super-model and a phantom Sonnet 4.8 on the way. Some of that is true. Most of it is not. I sorted the confirmed releases from the leak-blog fan fiction so you can plan a build without chasing ghosts.

What is actually shipping right now

Start with what I can point at and use today. No leaks required.

Claude Opus 4.7 went generally available on 2026-04-16. It is the current public flagship. Anthropic's own announcement frames it as a coding and long-running-task model, with a "notable improvement on Opus 4.6 in advanced software engineering" and the ability to handle "complex, long-running tasks with rigor and consistency."

The numbers Anthropic published are specific, so I trust them more than any rumor table:

CursorBench: 70 percent, versus Opus 4.6 at 58 percent.
BigLaw Bench: 90.9 percent accuracy at high effort.
Rakuten-SWE-Bench: resolves roughly 3x more production tasks than Opus 4.6.
Vision: accepts images up to 2,576 pixels on the long edge (about 3.75 megapixels), more than 3x the pixels of earlier Claude models.

Pricing for Opus 4.7 stayed put at 5 EUR-equivalent per million input tokens and 25 per million output tokens (Anthropic lists it in dollars, but the ratio is what matters for planning). That is the same as Opus 4.6, which is the rare case where a stronger model did not get more expensive. For a solo operator that detail matters: a capability jump with a flat token cost means I can upgrade my hardest workloads without re-running the math on every batch job.

On the Sonnet side, Claude Sonnet 4.6 released 2026-02-17 and is still the current Sonnet. It is the workhorse I reach for on volume tasks: cheaper, fast, good enough for most of my drafting and parsing jobs while Opus 4.7 handles the hard reasoning. I split work between the two on purpose. Routing every call to the flagship is how a small studio burns a token budget for no real gain. Sonnet 4.6 does the bulk grind, Opus 4.7 does the thinking, and that two-tier split has held steady through this whole rumor cycle.

So the lineup as of late May 2026 is simple. Opus 4.7 for the heavy work. Sonnet 4.6 for the rest. Everything past this point is either a countdown or a rumor.

The June 15 deadline that is not a rumor

Before chasing future models, clear the one date that will actually break things if you ignore it. The original Claude Opus 4 and Claude Sonnet 4 retire on 2026-06-15. After that, requests pinned to those model IDs stop working.

This is the boring, confirmed news that matters more than any leak. I have covered the specifics in the June 15 retirement of Opus 4 and Sonnet 4, so I will keep it short here.

The migration is mechanical. If you call claude-opus-4 or claude-sonnet-4 anywhere (a script, an agent, a hardcoded config, a cron job you forgot about), swap the model ID to a current one before the cutoff.

My quick checklist:

Grep your whole codebase for old model strings, not just the obvious app code.
Move heavy reasoning calls to Opus 4.7. Move volume calls to Sonnet 4.6.
Re-run your eval set after swapping. Prompts tuned for an older model sometimes drift on a newer one.
Check any third-party tools or plugins you depend on. They have their own deadlines.

The reason I lead with this instead of the shiny rumors: a hard retirement date is a fact you can act on this week. A leaked string about Sonnet 4.8 is not. One of these will cause a 2 AM outage if you ignore it. The other will not exist for months, if at all.

If your stack still references the retiring models, fix that first. Then come back and enjoy the speculation.

Claude Sonnet 4.8: where the rumor came from

Here is the headline a lot of blogs ran: Claude Sonnet 4.8 is coming. Here is the honest version: it is not announced, and the evidence is thin.

As of 2026-05-23, Anthropic has made no announcement, published no API model ID, released no benchmarks, and given no date for a Sonnet 4.8. So where did the rumor start?

A single leaked string. In late March 2026, a JavaScript source map was accidentally shipped with Claude Code, and someone spotted a "4.8" reference inside it. That string is the entire signal. Nothing came with it. No spec, no date, no confirmation.

Why I am skeptical, not dismissive

A string in a source map is not nothing. Internal builds reference unreleased things all the time. But it is also not a release. A few reasons I am keeping this in the rumor column:

The originating report flagged itself as uncertain. The post that surfaced it added a question mark, which tells you the finder was not confident either.
A prediction market on a Sonnet 4.8 release by 2026-05-24 sat at around 3 percent. The crowd does not believe it is imminent.
It would break Anthropic's versioning pattern. Opus 4.5 and Sonnet 4.5 matched. Opus 4.6 and Sonnet 4.6 matched. Jumping Sonnet to 4.8 with no 4.7 in between would skip a step Anthropic has never skipped.

That last point is the one I weigh most. Anthropic has been consistent: the Opus and Sonnet minor versions move together. A lone "4.8" that leaps past a Sonnet 4.7 is more likely a placeholder, a test ID, or an internal experiment than a near-term product. Labs leave dead strings and forward-looking IDs in their code constantly. A grep hit is a clue, not a launch date.

There is also a tell in how these posts get written. The headline says "Claude Sonnet 4.8 Release Date" with full confidence. The body, if you read it, walks it all back and admits nothing is announced. That gap between headline and body is the cleanest signal that a piece is chasing search traffic rather than reporting news.

My rule for any reader who finds this article while deciding what to build on: if a post hands you a Sonnet 4.8 benchmark table, a price, or a confirmed release date right now, it is fabricating. Treat it that way. The honest answer in late May 2026 is "no Sonnet 4.8 exists yet," and that answer will not change until Anthropic publishes a model page.

Claude Mythos and the Opus 5 question

The Mythos story is the opposite of the Sonnet 4.8 story. Mythos is real. Anthropic confirmed it. The fan fiction is in the details, not the existence.

On 2026-04-16, the same day Opus 4.7 shipped, Anthropic publicly conceded that Opus 4.7 does not match the performance of a more capable internal model called Mythos. Per Axios, the company said benchmark charts show Opus 4.7 beating ChatGPT 5.4 and Gemini 3.1 Pro, while still falling short of "its Mythos Preview model." That is an unusual move: a lab admitting in public that it is sitting on something stronger than what it just released.

Mythos is not public. Axios reports access is limited to "a handpicked group of tech and cybersecurity companies," and the model is withheld over safety concerns. Anthropic's stated goal is "a broad release of Mythos-class models" once it learns enough from deploying safeguards.

What is confirmed vs what is leak-blog guesswork

Mythos first surfaced through a large source-code and document exposure. A misconfigured data store left around 3,000 internal files reachable without authentication in late March 2026, then a researcher disclosed it and Anthropic locked it down within hours. I covered that incident in the source leak that first surfaced Mythos.

From the leak and Anthropic's own statements, here is my confidence split:

Confirmed: Mythos exists, and Anthropic calls it a major capability advance.
Confirmed: It is restricted, withheld for safety, given to a small set of companies.
Reported but unverified: Mythos is "far ahead of any other AI model in cyber capabilities," and can find and exploit vulnerabilities faster than human defenders. That phrasing comes from leaked docs, not a published benchmark.
Not confirmed: the name "Opus 5." The community attached that label. Leaked docs frame Mythos as a new capability class, not a version bump, and Anthropic has not blessed "Opus 5."

The cybersecurity angle is the most consequential part of the story and the part with the least public proof. If you want the security framing, I dug into Mythos powering Project Glasswing. Read it knowing the specifics are still reported, not benchmarked.

How I plan around all of this as a solo builder

Strip the drama and the planning answer is short. Build on what exists. Watch the rumors for free.

I run a one-person studio, so I cannot afford to architect around a model that might land in Q3, might be named something else, and might never go public in my tier. Here is the framework I actually use.

Treat the timeline as three buckets

Shipping now: Opus 4.7, Sonnet 4.6. These are the only things I let into production.
Confirmed but inaccessible: Mythos. Real, stronger, not available to me. I track it, I do not depend on it.
Rumored: Sonnet 4.8, "Opus 5," "Claude 5," and the speculated Q2 to Q3 2026 window for the next major model. None of these names are official. None get a line item in my plans.

My practical rules

Pin to current model IDs, but isolate them. I keep the model name in one place so a future swap is a one-line change, not a hunt.
Never delay a launch for an unannounced model. The cost of waiting is certain. The arrival of Sonnet 4.8 is not.
Re-run evals on every model bump. A newer model is not automatically better for your exact prompt. Measure, do not assume.
Read the leak blogs for direction, not numbers. They are useful for "Anthropic is clearly investing in cyber and long-horizon agents." They are useless for "here is the exact benchmark."
Keep a one-line note on the rumor, then move on. I track Mythos and Sonnet 4.8 in a single text file with a date and a confidence tag. That is the right amount of attention for something I cannot use yet.

The direction Anthropic is signaling is not subtle. It conceded in public that it has a stronger model than it ships. It is gating that model on safety and handing it to a narrow set of partners first. It keeps shipping minor versions of Opus and Sonnet on a tight cadence. Put those together and the realistic read is more capable models arriving steadily, with the frontier ones arriving slowly and to a few hands. None of that tells me a name or a date. All of it tells me the safe bet is to build clean on today's models and keep the swap cheap.

The signal here is that Anthropic has a stronger model than it ships, and a steady cadence of minor versions. The noise is every specific date, score, and name attached to models that do not have a public page yet. If you want the same model setup I run day to day, I keep it documented in my Claude setup blueprint.

Bottom Line

Here is the whole thing in one breath. Opus 4.7 (shipped 2026-04-16) and Sonnet 4.6 (shipped 2026-02-17) are real and usable today. Opus 4 and Sonnet 4 retire 2026-06-15, so migrate before then. Mythos is real, stronger than Opus 4.7 by Anthropic's own admission, and locked to a small set of companies for safety reasons. Claude Sonnet 4.8 is not announced and rests on a single leaked string. "Opus 5" and "Claude 5" are community labels, not confirmed names, and any next-major-model date in the Q2 to Q3 2026 range is speculation.

If you only do one thing this week, it is not waiting for a phantom model. It is grepping your codebase for the retiring model IDs and swapping them. That is the deadline with teeth.

I will keep updating as Anthropic actually announces things, not as leak blogs invent them. If you want a clean starting point that already runs on the current models and is easy to re-point when the next one lands, take a look at my Claude setup blueprint and skip the guesswork.

Claude's Big May: Limit Reset, Code w/ Claude, Small Business

RAXXO Studios — Sun, 24 May 2026 13:26:13 +0000

On May 15 2026 Anthropic manually reset everyone's 5-hour and weekly Claude limits across Pro, Max, Team, and Enterprise.
At its Code w/ Claude events, roughly half a packed room said Claude wrote a pull request they shipped in the past week.
Claude for Small Business launched May 13 2026 with 7 connectors and 15 ready-to-run agentic workflows.
KPMG put Claude in front of 276,000+ employees and PwC expanded to Claude Code and Cowork.
A solo studio gets the same agentic workflows the big firms just bought, minus the seat count.

May 2026 was the month Claude stopped feeling like a tool I open and started feeling like infrastructure other people build companies on. Four things blew up in four weeks: a surprise limit reset, a developer conference moment that made the internet flinch, a small-business package, and two consulting giants going all-in. Here is what each one actually was, and what it changes for a one-person studio like mine.

The enterprise wave nobody saw coming this fast

Two announcements bookended the month and they matter even if you never touch enterprise software. On 2026-05-19 Anthropic announced a global alliance with KPMG, embedding Claude inside KPMG's "Digital Gateway" platform with access for more than 276,000 employees. Around the same window, PwC expanded its existing alliance, rolling out Claude Code and Cowork starting with US teams.

I am not a 276,000-person firm. So why do I care? Because when the big consultancies standardize on a model, three things happen downstream. The model gets hardened for boring, high-stakes work (audit trails, compliance, document review), which trickles into the same product I pay 20 EUR a month for. The integrations get built once and reused everywhere. And the "is AI ready for real work" debate quietly ends, which makes my own AI-built products easier to sell to skeptical buyers.

The Digital Gateway detail is the part I keep thinking about. KPMG did not bolt a chatbot onto its website. It put Claude inside the platform its people already use to do audits and advisory work, in front of more than a quarter of a million employees. That is the difference between a pilot and a commitment. When a firm whose entire product is professional judgment decides Claude is safe enough to sit in the workflow, the bar for "trustworthy AI" just got set in public by people who get sued for being wrong.

There is also a competitive read here. I have written before about Anthropic's lead in enterprise AI spend, and these two deals are that thesis playing out in public. KPMG and PwC are not experiments. They are committed budgets and headcount. For a solo builder, that is free validation: the foundation I rely on is being battle-tested by people with far more to lose than me.

What I am not going to do

I am not going to deep-dive the enterprise economics here. The short version: the firms get a model that handles document-heavy, repeatable work at scale, and Anthropic gets reference logos plus enormous usage data. If you want the full breakdown of what enterprise dominance means for small builders, I covered it separately. For this roundup, the takeaway is simpler. The big money arrived, and it arrived fast.

The surprise limit reset that lit up the community

Here is the moment that got the most love from regular users. On 2026-05-15 Anthropic manually reset everyone's rate limits, both the 5-hour window AND the weekly cap, restoring full quotas across Pro, Max, Team, and Enterprise. The official word came from the @ClaudeDevs account: "Happy Friday! We've reset everyone's 5-hour and weekly rate limits." A Friday afternoon gift, server-side, no action required.

For context, this landed on top of an already generous month. Earlier in May, around the SpaceX and Colossus compute news, Anthropic had doubled the 5-hour limits across paid plans and removed the peak-hour throttling that used to quietly cut quotas during busy periods. I broke that down when it happened in my piece on the May limit doubling earlier this month. So the reset was not a one-off apology. It was the cherry on a deliberate "use Claude more, we have the compute now" stretch.

Why a free reset is a real signal

A rate limit reset sounds small. It is not. Limits are the most honest signal a model provider sends about its supply. When Anthropic gives everyone a clean slate AND keeps the doubled caps, it is saying the data centers can take it. That confidence shows up in my workflow as fewer "you have hit your limit" walls in the middle of a build session.

What I did with it was practical. I batched the heavy stuff. Two articles drafted, a landing page rebuilt, a Liquid section refactored, all in the window after the reset, while the quota was fresh. The lesson I keep relearning: when the platform hands you headroom, spend it on the work you have been rationing.

There is a quieter signal in the timing too. The reset landed on a Friday afternoon, peak hours across the major developer regions, the exact window where you would normally expect throttling, not generosity. Handing out fresh quotas at the busiest moment is a flex. It says the compute is not the constraint anymore. For someone who used to plan a build day around limit windows, that is a genuine shift in how I work. I stopped checking the meter and started checking my own output.

The Code w/ Claude moment that made the internet flinch

The viral one. Across Anthropic's Code w/ Claude developer events this May, an engineer asked the room a simple question: who here has shipped a pull request in the last week that was completely written by Claude? Roughly half the hands went up. Then came the follow-up: who shipped it without reading the code? According to MIT Technology Review's 2026-05-21 coverage, most of those hands stayed up, which got a nervous laugh from the crowd.

A note on logistics, because the sources differ. Simon Willison's live blog placed a San Francisco leg around 2026-05-06, while MIT Technology Review's writeup described a London stop around 2026-05-19. It was a series, not a single night, so I am not going to pin the "half the room" moment to one city. The point holds either way: in a room full of working developers, delegating a whole PR to Claude was already normal.

What the coverage actually argued

MIT Technology Review framed the event as a glimpse of "coding's future, whether you like it or not." InfoQ went deeper on the mechanics, covering Managed Agents, more proactive workflows, and a "capability curve" framing where the model keeps climbing toward harder tasks. Anthropic's own engineering lead reportedly described Claude as roughly "as good as a midlevel engineer," still needing humans for system design and the gnarly debugging.

That last line is the one I underlined. Midlevel engineer for the grunt work, human for the architecture. That is not a threat to a solo builder. That is a description of how I already work. I do the deciding. Claude does the typing. The "did anyone read it" laugh is the real warning, though: shipping unread code is how you inherit bugs you cannot explain at 2am.

Claude for Small Business, aimed straight at people like me

This is the launch I cared about most. On 2026-05-13 Anthropic shipped Claude for Small Business, a package of connectors plus 15 ready-to-run agentic workflows that plug Claude directly into the tools small operators already live in: Intuit QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, and Microsoft 365.

The workflows read like a to-do list I have been avoiding:

Payroll planning
Monthly financial close and reconciliation
Invoice chasing (politely getting money owed to you)
Sales campaign management and lead triage
Tax-season prep and contract review
Content strategy

Daniela Amodei, Anthropic's co-founder and president, put the pitch plainly: Claude "helps take the late-night work off their plates." For anyone who has done their own books after dinner, that line lands.

The extras that make it more than a feature drop

Two add-ons stood out. First, a free "AI Fluency for Small Business" course, built with PayPal and taught by actual small-business owners, on how to use AI safely and well. Second, a "Claude SMB Tour" of free half-day workshops across 10-plus US cities starting 2026-05-14 (Chicago first, then stops including Dallas, Baltimore, San Jose, and Salt Lake City). Attendees even get a one-month Claude Max subscription thrown in.

I run my whole studio solo, so the connectors that grab me are the boring ones: monthly close, invoice chasing, contract review. If you do touch the marketing side, the campaign and content workflows pair naturally with a scheduler like Buffer so the drafting and the posting both run on rails. This whole package also rhymes with Claude's finance agent templates from earlier in the year. Anthropic is clearly building a stack for people who do not have a finance team, because they ARE the finance team.

What a solo studio should actually do with all this

Roundups are useless without a move. Here is mine, in order of what paid off fastest.

Spend the headroom, do not hoard it

The doubled limits and the reset mean I stopped self-rationing. I now schedule my heaviest Claude sessions in a single block and let it run: drafting, refactoring, image prompts, the lot. Treating quota as scarce when the platform is shouting "abundant" is just leaving value on the table.

Steal the small-business workflows, skip the seats

I do not need the enterprise contract to get the small-business brain. The 15 workflows are a template library for running a one-person operation: financial close, invoice chasing, contract review, content strategy. I picked the three that eat my evenings and wired Claude into them first. The connectors I already use (Google Workspace, plus the accounting side) did most of the heavy lifting.

Read the code, always

The Code w/ Claude "did anyone read it" laugh is my permanent reminder. Half a room shipping unread AI code is a trend, not a recommendation. I let Claude write the PR. I still review every line before it ships. That single habit is the difference between leverage and liability. The cost of an unread bug is not the bug. It is the hour you spend later staring at code you never understood, in a system you did not design, while a customer waits. Reviewing the diff takes minutes. Inheriting a mystery costs a day.

Use the validation as a sales tool

When KPMG puts Claude in front of 276,000 people, I no longer have to argue that AI-built work is "real." The biggest, most risk-averse firms on earth already settled that for me. I lean on that when I describe how my products get made. Skeptics trust crowds.

Bottom Line

May 2026 was not one big Claude story. It was four smaller ones that point the same direction. Limits went up and got reset, so there is more room to build. A conference made it plain that shipping Claude-written code is already normal, with the only real caveat being "read it first." A small-business package handed solo operators the same agentic workflows the big firms are paying for. And KPMG and PwC removed the last excuse for treating AI work as not-quite-real.

For a one-person studio, the net is good news. The platform I depend on is getting more generous, more capable, and more trusted, all at once. My job is to spend that headroom on real output, steal the workflows that buy back my evenings, and never ship a line I have not read.

If you want the exact setup I run, the connectors, the review habits, and the guardrails that keep AI work shippable, I keep it documented in my Claude setup blueprint. Take what fits your studio and leave the rest. The point is to build more, not to brag about how the work got made.

CSS Scroll-Driven Animations: 6 Patterns I Ship in 2026

RAXXO Studios — Sun, 24 May 2026 13:25:37 +0000

A scroll progress bar needs three CSS lines with scroll(root block), zero JavaScript.
view() plus animation-range: entry reveals cards as they enter the viewport.
Named scroll-timeline drives parallax layers at different speeds from one scroller.
Sticky scrubbing ties a tall container's scroll progress to an image or text.
Per-item view() timelines stagger list reveals without any offset math in JS.
Gate everything with @supports and kill motion under prefers-reduced-motion.

I deleted a 14 KB scroll library from my last project and replaced it with about 40 lines of CSS. The animations got smoother, the bundle shrank, and the main thread stopped choking on scroll listeners. Native scroll-driven animations are the reason. Here are the six patterns I actually ship in 2026, with copy-pasteable code for each.

The whole feature rides on one property: animation-timeline. Instead of timing an animation against a clock, you time it against scroll position. Two functions do most of the work. scroll() tracks how far a scroll container has scrolled. view() tracks how far an element has moved through the scrollport. Pair either with @keyframes and the browser runs the animation off the main thread. No requestAnimationFrame, no IntersectionObserver, no jank.

Pattern 1: A scroll progress bar with scroll(root block)

The reading-progress bar at the top of a long article is the cleanest demo of the feature. It maps document scroll position straight onto a transform. No JavaScript at all.

You need a fixed element and a @keyframes rule that scales it from 0 to 1 on the X axis. The scroll(root block) timeline reads the root scroller's progress along the block axis (vertical in most writing modes). scaleX is the right transform here because it animates on the compositor and stays buttery.


.progress-bar {
  position: fixed;
  inset: 0 0 auto 0;
  height: 4px;
  background: #e3fc02;
  transform-origin: left;
  transform: scaleX(0);
  animation: grow-progress linear;
  animation-timeline: scroll(root block);
}

@keyframes grow-progress {
  to { transform: scaleX(1); }
}

Three things to notice. First, there is no animation-duration. With a scroll timeline the duration is the scroll distance, so auto is implied and the value you set is ignored in Chromium. Firefox is the exception: it wants a non-zero duration to apply the animation at all, so I add animation-duration: 1ms defensively. Second, linear matters. An eased progress bar lies about how far you have read. Third, transform-origin: left anchors the growth so the bar fills left to right.

I use scroll(root block) for page-level progress. If the scroller is a nested overflow: auto panel, swap root for nearest and the timeline binds to the closest ancestor scroll container instead. The block keyword can become inline, x, or y when you need a horizontal scroller. This pattern alone replaced a small JavaScript helper I had been copying between projects for years, part of my push toward pure-CSS animation patterns over runtime dependencies.

Pattern 2: Reveal-on-scroll cards with view()

Fade-and-rise reveals used to mean an IntersectionObserver, a .is-visible class, and a CSS transition. Now view() does it in pure CSS. The view() timeline tracks a single element as it crosses the scrollport, from the moment it enters at the bottom to the moment it leaves at the top.


.card {
  opacity: 0;
  translate: 0 32px;
  animation: reveal linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

@keyframes reveal {
  to {
    opacity: 1;
    translate: 0 0;
  }
}

animation-range: entry 0% entry 100% is the heart of it. The entry range covers the phase where the element is entering the scrollport, from first pixel visible (0%) to fully crossed the bottom edge (100%). The card finishes its reveal exactly when it has entered, not when it is centered, so the motion reads as natural rather than late.

I reach for both as the fill mode so the start frame holds before the range begins and the end frame holds after. Without it the card snaps back to opacity: 0 once it scrolls past, which looks broken. Note the translate property instead of a transform offset. I keep transforms free for other uses and animate translate and opacity only, since both are compositor-friendly.

Want the reveal to start a touch later? Try animation-range: entry 25% cover 50%. That delays the start until the element is a quarter into its entry and finishes it when the element covers half the scrollport. Tuning these two numbers is most of the design work. I store my preferred ranges and easings as variables so reveals stay consistent across a site, an approach I wrote up in my motion design tokens.

Pattern 3: Parallax layers with a named scroll-timeline

Parallax means layers moving at different speeds against the same scroll. A named scroll-timeline makes this trivial. You name the scroller once, then point as many animations at it as you like, each with its own @keyframes and travel distance.


.parallax {
  scroll-timeline-name: --hero-scroll;
  scroll-timeline-axis: block;
  overflow-y: auto;
  height: 100svh;
}

.layer-back {
  animation: drift linear;
  animation-timeline: --hero-scroll;
}
.layer-front {
  animation: drift-fast linear;
  animation-timeline: --hero-scroll;
}

@keyframes drift { to { translate: 0 -40px; } }
@keyframes drift-fast { to { translate: 0 -160px; } }

The scroller gets scroll-timeline-name set to a dashed-ident (--hero-scroll). Any descendant can then set animation-timeline: --hero-scroll to ride that progress. Different translate distances in the keyframes produce different apparent speeds, which is the parallax illusion. The background drifts 40px, the foreground 160px, across the full scroll of the container.

By default a named scroll-timeline only reaches direct descendants of the scroller. If a layer lives outside that subtree, declare timeline-scope: --hero-scroll on a shared ancestor and the name becomes visible across the whole tree. I only add timeline-scope when the DOM forces it, because keeping the animated layers inside the scroller is simpler to reason about.

One caution: parallax is the pattern most likely to feel like too much. I keep distances small and always honor reduced-motion (Pattern 6). Subtle depth beats a carnival ride every time.

Pattern 4: Sticky section scrubbing

Scrubbing is the effect where a sticky element changes as you scroll past a tall container. Think of a phone image that rotates, or a headline that swaps, driven entirely by how far through the section you have scrolled. The trick is a tall outer container with a position: sticky child, animated against the container's own view() progress.


.scrub-section {
  height: 300svh;
  position: relative;
}

.scrub-sticky {
  position: sticky;
  top: 0;
  height: 100svh;
  display: grid;
  place-items: center;
}

.scrub-visual {
  animation: scrub linear both;
  animation-timeline: view();
  animation-range: contain 0% contain 100%;
}

@keyframes scrub {
  from { scale: 0.8; rotate: -6deg; }
  to   { scale: 1;   rotate: 0deg; }
}

The outer .scrub-section is 300svh tall, so it occupies three screens of scrolling. Its child sticks to the top and stays pinned while the section scrolls past. I drive .scrub-visual with animation-range: contain 0% contain 100%. The contain range covers the entire window during which the section fully fills (or is fully contained by) the scrollport, which is exactly the pinned phase. So the visual scrubs from start to end across all three screens of stick.

from/to keyframes give a clean two-state scrub. Add intermediate percentages for multi-step sequences: 50% { rotate: 3deg; } introduces a midpoint wobble. Because the timeline is scroll-bound, scrubbing back up reverses the animation automatically. There is no state to manage and nothing to reset. This single pattern replaces the bulk of what I used to reach for a JS scroll library to do.

Pattern 5: Staggered list reveals, no JS

Staggered reveals (items appearing one after another as the list scrolls in) usually need JavaScript to compute per-item delays. With view() per item, the stagger emerges for free, because each item has its own position in the scrollport and therefore its own progress.


.stagger-item {
  opacity: 0;
  translate: 0 24px;
  animation: rise linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 30%;
}

@keyframes rise {
  to { opacity: 1; translate: 0 0; }
}

Each .stagger-item runs the same animation against its own view() timeline. Since items sit at different scroll positions, item two enters slightly after item one, so its reveal fires slightly later. The visual stagger is a side effect of layout, not of any delay value. No nth-child math, no inline custom properties, no observer.

The range entry 0% cover 30% tunes the feel. It starts each reveal as the item begins entering and finishes it when the item covers 30% of the scrollport. A tighter range like entry 0% entry 60% makes items pop faster and overlap less. A wider one spreads the motion out. For a long list, a tighter range keeps the cascade from dragging.

If you want a deliberate cascade that does not depend on item spacing, you can add small animation-delay-style offsets through the range itself per group. I rarely bother. The natural stagger from view() looks more organic than evenly timed delays, and it adapts automatically when content reflows on mobile. One CSS rule, any number of items, correct on every viewport. This is the pattern that convinced me to delete my old reveal helper for good.

Pattern 6: Reduced motion and progressive enhancement, done right

Scroll-driven animations are an enhancement. They must never be load-bearing for content. Two guards keep them safe: a feature query so unsupported browsers get the static layout, and a reduced-motion query so people who ask for less motion get it.


/* Static, accessible baseline lives in the normal rules.
   Motion is added only when both checks pass. */
@supports (animation-timeline: scroll()) {
  @media (prefers-reduced-motion: no-preference) {
    .card {
      opacity: 0;
      translate: 0 32px;
      animation: reveal linear both;
      animation-timeline: view();
      animation-range: entry 0% entry 100%;
    }
  }
}

The structure matters. I never set opacity: 0 in the base rule. If I did, a browser without scroll-timeline support (or a user with reduced motion) would see permanently invisible cards. Instead the baseline is the finished, visible state. The motion, including the starting opacity: 0, lives entirely inside the nested @supports and @media block. Strip away the enhancement and the page still reads perfectly.

@supports (animation-timeline: scroll()) gates on the actual feature, not a browser sniff. @media (prefers-reduced-motion: no-preference) flips the logic so motion is opt-in by the user's OS setting, which is the polite default. If you prefer the inverse pattern, wrap the motion normally and add a @media (prefers-reduced-motion: reduce) { animation: none; } override, but I find the no-preference gate harder to get wrong.

Browser reality in 2026

Here is the honest support picture as of May 2026. Chromium (Chrome and Edge) has shipped this since Chrome 115, so it has been stable for a long time. Safari shipped it in Safari 26, which closed the biggest gap. Firefox has it fully implemented but still behind a flag by default, so treat Firefox as unsupported in production and let the @supports baseline carry it. caniuse puts global support around 85% and climbing. One Firefox quirk to remember: it requires a non-zero animation-duration to apply scroll-driven animations, so adding animation-duration: 1ms costs nothing and helps. There is also a scroll-timeline polyfill if you need the effect on older engines, though I prefer graceful degradation over shipping a polyfill.

Bottom Line

Native scroll-driven animations changed how I build scroll effects. Six patterns cover almost everything I need: a progress bar, reveals, parallax, sticky scrubbing, staggered lists, and the guards that keep it all safe. The total cost is a few @keyframes rules and one animation-timeline line each. No scroll listeners, no observers, no library to update when it breaks.

The discipline that makes this work is putting the visible, accessible state in the base rules and adding motion only inside @supports plus a reduced-motion check. Get that wrong and a Firefox user stares at blank cards. Get it right and the page degrades to a clean static layout everywhere, then layers in smooth, compositor-driven motion where it is welcome.

If you want the durations and easings behind these snippets to compose cleanly across a whole site, that comes down to a small token system rather than one-off values. I document how I structure design and motion work, plus the rest of the studio toolkit, over at the RAXXO studio. Steal the patterns, tune the ranges, and delete a scroll library this week.

CSS :has() in Production: 6 Selectors That Replaced JavaScript Across My Sites

RAXXO Studios — Sat, 23 May 2026 21:39:57 +0000

Six :has() selectors deleted roughly 240 lines of JS across my sites
Form validation styling now uses form:has(:user-invalid), zero input listeners
nav:has(a[aria-current]) styles parent menus without click handlers
Theme toggle, empty-cart layout, and image cards all run on :has(), no JS

I deleted about 240 lines of JavaScript last month and the UI got faster, not worse. The trick was :has(), the CSS parent selector that quietly hit Baseline in late 2023 and is boringly safe in 2026. Here are the six selectors I actually shipped to raxxo.shop and three other sites, with the JS they replaced. If you want the foundational set first, I covered those in the :has() patterns that changed how I write UI. This piece is the production cut.

Form validation styling without a single input listener

The old pattern: attach an input or blur listener to every field, check validity in JS, then add or remove an is-invalid class on the wrapper so the label and helper text could turn red. On a six-field checkout that was a wall of event wiring, and it always desynced when a framework re-rendered the field.

:has() plus the :user-invalid pseudo-class does the whole thing in CSS. :user-invalid only flips after the user has actually interacted with the field, so you do not scream red at someone who just loaded the page.

Before, roughly per field:


const field = wrapper.querySelector('input');
field.addEventListener('blur', () => {
  wrapper.classList.toggle('is-invalid', !field.checkValidity());
});

After, once, for all fields:


.field:has(input:user-invalid) {
  --field-border: #ff5470;
}
.field:has(input:user-invalid) .field__hint {
  color: #ff5470;
  opacity: 1;
}
.field:has(input:user-valid) .field__check {
  opacity: 1;
}

That replaced 38 lines of listener code on the checkout form alone. The border, the hint text, and a little green check now react to the input's own validity state, scoped to the wrapper so nothing leaks. I still keep one tiny bit of JS for the submit button (disabling it until the whole form is valid), because :has() cannot yet style an element based on a sibling form's overall validity in a way I trust across every browser. Everything visual, though, is CSS.

Two practical notes from shipping this. First, lean on the native constraint attributes (required, type="email", pattern, minlength) so the browser does the validity math for you. :user-invalid reads straight from that, which means your visual rules and your actual form submission agree by construction, with no second source of truth to drift. Second, the reduced-motion crowd gets a cleaner experience here too, since there is no class-toggle flash when a framework re-renders the field mid-typing. I measured the checkout interaction before and after on a mid-range phone: the input-to-paint delay on each keystroke dropped because the main thread no longer runs a validity check and a class write per event. It is a small number, a few milliseconds, but it is the kind of jank you feel on a long form. If you want the broader picture on dropping JS for CSS-native behavior, see Pure CSS Animations That Replace JavaScript Libraries.

Parent-of-active-child navigation that knows where you are

Highlighting the parent menu item of the current page used to mean reading the URL in JS, looping over nav links, and toggling an active class on the right `

`. Every router change meant re-running it. Miss an edge case and the wrong section stays lit.

If your links already carry aria-current="page" (and they should, for screen readers), :has() lets the parent style itself:


.nav__group:has(a[aria-current="page"]) > .nav__label {
  color: var(--lime);
  font-weight: 600;
}
.nav__group:has(a[aria-current="page"]) {
  border-left: 2px solid var(--lime);
}

No loop, no class toggling, no router hook. The accessibility attribute is the single source of truth, and the visual state follows it for free. This deleted a 22-line nav-highlighter module that I had copy-pasted into four projects, which means four fewer places to fix when the markup changes.

One thing to watch with :has() and specificity. The selector takes the specificity of its most specific argument, so .nav__group:has(a[aria-current="page"]) is heavier than a plain .nav__group. If a later, simpler rule fails to override it, that is usually why. I keep these state selectors in a dedicated cascade layer so the ordering stays predictable and I am not fighting specificity by hand. Worth knowing before you sprinkle :has() everywhere and wonder why one override stopped working.

A second selector in the same family handles the mobile drawer. I wanted the page to lock scroll when the menu is open, and I was toggling a body.menu-open class in JS. Now a hidden checkbox drives it and the body reacts to a state further down the tree is not possible (you cannot select up to from a deep checkbox without a wrapper), so I scope it to the app shell instead:


.app:has(#menu-toggle:checked) .app__scroll {
  overflow: hidden;
}

The drawer open and close animation, the overlay fade, and the scroll lock all run from one checkbox state. That is two selectors, zero JS, replacing what used to be a small state machine. The View Transitions work I did later leans on the same instinct of letting the platform hold state. Background on that is in View Transitions API patterns I use across my sites.

Empty states and quantity-aware layout, decided by content

This is the selector that made me a believer. A cart, a search result list, a dashboard widget: they all need to look different when empty versus full, and they often need to react to how many children exist. The classic approach counts items in JS and sets a data-count attribute or an is-empty class.

:has() reads the content directly. Empty state first:


.cart:has(.cart__item) .cart__empty { display: none; }
.cart:not(:has(.cart__item)) .cart__items { display: none; }
.cart:not(:has(.cart__item)) .cart__checkout { display: none; }

The empty message shows only when there are no items, and the checkout button hides itself. No counting, no flag. When the last item is removed from the DOM, the layout flips on its own.

Quantity-aware layout uses :has() with quantity selectors. I wanted a results grid that switches to a single centered column when there is exactly one result, and a tighter grid past nine:


.results:has(.card:only-child) {
  grid-template-columns: minmax(0, 36rem);
  justify-content: center;
}
.results:has(.card:nth-child(10)) {
  gap: 8px;
}

The second rule fires only once a tenth card exists, so dense lists get tighter spacing automatically. Pair it with :has() to detect a loading skeleton and dim the surrounding toolbar, and you have an entire responsive-to-content system with no resize observers and no item counters. This replaced about 50 lines across the cart and the lab search page.

The one caveat worth repeating: :has() reacts to the DOM as rendered, so if your framework virtualizes a long list and only paints 20 of 400 rows, the :nth-child math counts the painted rows, not the data behind them. Know your renderer. In practice this only bit me once, on a virtualized log viewer, and the fix was to drive the count selectors off a small wrapper attribute the renderer already set, then use :has() for the purely visual states inside each row. The rule of thumb I landed on: use :has() for "does this thing contain that thing" questions, and let your data layer answer "how many" when the list is virtualized.

Theme toggles, image cards, and selected table rows

Three smaller wins that each killed a chunk of script.

Theme toggle without JS. I used to listen for a toggle, write data-theme to `, and persist it. For a no-persistence toggle (a preview switch in a settings panel), a checkbox and:has()` are enough:

`css

.preview:has(#dark-toggle:checked) {
--bg: #1f1f21;
--text: #F5F5F7;
}

The whole preview pane re-themes from one checkbox. For the site-wide theme I still use a few lines of JS, only because I want the choice saved to storage and applied before first paint to avoid a flash. Visual switching, though, needs no script.

Card-with-image variants. A content card should lay out differently when it has a thumbnail versus when it is text only. Instead of adding a has-image class server-side, the card detects its own image:

`css

.card:has(.card_media) {
grid-template-columns: 8rem 1fr;
}
.card:has(.cardmedia img[src$=".svg"]) .card_media {
padding: 16px;
}

The layout adapts to whatever the CMS sends, and SVG logos even get extra padding so they do not sit edge to edge. No template branching.

Selected table rows. Bulk-select tables usually toggle a row-selected class on every checkbox change. With :has(), the row styles itself and the table header can show a bulk-action bar the moment any row is checked:

`css

tr:has(input[type="checkbox"]:checked) {
background: rgba(227, 252, 2, 0.08);
}
.table:has(tbody input:checked) .table__bulkbar {
display: flex;
}

That deleted the last row-selection listener I had. Three selectors, three fewer scripts. None of this needs a build step, a library, or a polyfill in 2026. :has() is Baseline (every modern engine shipped it by the end of 2023), so the only browsers that miss it are ones you have already dropped.

Bottom Line

Six selectors, four sites, roughly 240 lines of JavaScript gone. The pattern is always the same: find the place where JS is reading the DOM just to add a class, and let :has() read the DOM instead. Forms react to their own validity, nav follows aria-current, carts respond to their contents, and tables light up selected rows, all without listeners that desync on re-render. The UI got more robust because the state lives in one place, the markup, not in a script trying to mirror it.

Start with the empty-state selector. It is the lowest risk and the easiest to feel. Then go hunting for classList.toggle calls and ask whether the element could just look at its own children. Most of mine could. If you want the rest of how I keep RAXXO's frontend lean and on-brand, the work and the tools I lean on live at the RAXXO Studios page. Steal the selectors, ship them, delete some code.

EU Reverse-Charge VAT for Solo SaaS Buyers: The Zero-Euro Math Most Devs Miss

RAXXO Studios — Sat, 23 May 2026 21:38:40 +0000

Reverse-charge means you self-account VAT on foreign SaaS and deduct it in the same return, so the net is zero
A valid VAT ID on file with the vendor is what triggers reverse-charge instead of a consumer sale
Standard taxation usually beats the small-business exemption once your stack is tool-heavy, because you can reclaim input VAT
Four traps: missing VAT ID, treating VAT as a cost, skipping the zero return, buying tools as a consumer

A solo studio in the EU buys most of its tools from abroad. AI models, design apps, hosting, schedulers, all billed from the US or Ireland. The first time one of those invoices shows VAT due, a lot of solo devs panic. The good news is boring: when you do it right, the VAT on those purchases costs you exactly nothing.

What Reverse-Charge Actually Is

Reverse-charge is a rule for cross-border business-to-business services inside the EU VAT system. Normally the seller charges VAT and pays it to their own tax office. For digital services sold to a business in another EU country, that flips. The seller charges no VAT, and the buyer becomes responsible for accounting it instead. Hence the name: the charge is reversed onto you.

Here is the part most people miss. "Accounting for it" does not mean writing a check. It means you record the VAT on both sides of your return at the same time. You add it as VAT you owe (because you imported a service), and you add the identical amount as input VAT you can reclaim (because you bought it for your business). The two entries cancel.

So a 100 EUR SaaS subscription does not become 119 EUR. It stays 100 EUR in real money out the door. The VAT exists only as two matching numbers on a form, one positive, one negative, summing to zero.

This applies to almost every foreign tool a studio touches. An AI coding assistant billed from the US, a video tool from Ireland, a cloud host in another member state. For US vendors the mechanism is technically "VAT on imported services from a non-EU supplier," but for a business buyer the bookkeeping result is the same shape: self-account, then deduct.

The catch is that this only works cleanly if two things are true. You have to be a business with a valid VAT identification number, and you have to be on standard taxation rather than the small-business exemption. Get those wrong and the zero stops being zero. That is where the next two sections come in, because the setup matters more than the math.

The VAT ID Requirement and Why Standard Taxation Wins

The trigger for reverse-charge is your VAT identification number. Not your local tax number, the EU-wide VAT ID (the one with the country prefix). When you enter that ID in a vendor's billing settings, their system recognizes you as a business in another member state and stops adding VAT. No ID, and most platforms treat you as a private consumer and charge their local rate, which you usually cannot reclaim. That single field is the difference between a zero-cost VAT flow and a permanent surcharge on every invoice.

So step one is mundane: get a VAT ID, then paste it into every tool you pay for. Stripe, the AI vendors, the hosting bill, all of them have a tax field in account settings.

Now the bigger decision. Many solo founders start on the small-business exemption, where you charge no VAT to your own customers and skip most VAT paperwork. It sounds simpler, and for a service business with almost no expenses it can be. But it has a hidden cost: under the exemption you generally cannot reclaim input VAT on what you buy. For a tool-heavy studio paying for ten or fifteen subscriptions, that reclaim is exactly the lever that makes reverse-charge net to zero.

Drop the exemption and go to standard taxation, and the picture flips in your favor. You charge VAT to local customers and pass it on, you reclaim input VAT on your tools, and reverse-charge imports wash out completely. The admin is a periodic return instead of nothing, but for anyone comfortable with a spreadsheet or a bookkeeping tool it is a small price for stopping VAT from quietly eating into your tool budget. For the practical side of running those returns, see Solo Studio Bookkeeping in 90 Minutes a Month.

This is a general pattern, not personalized advice. Thresholds and the exact paperwork vary by country, so confirm the specifics for where you are registered.

How the Zero Nets Out on Your Return

Numbers make this concrete. These are illustrative round figures, not anyone's real books.

Say in one quarter your studio buys foreign SaaS worth 1,000 EUR net. AI tools, a design app, hosting, a scheduler. Every vendor has your VAT ID, so every invoice arrives with no VAT added. Total cash out: 1,000 EUR.

At your local standard rate (use 20 percent for the example), the reverse-charge VAT on that 1,000 EUR is 200 EUR. On the periodic VAT return you make two entries. First, you declare 200 EUR of VAT due on services received from abroad. Second, in the input VAT section you declare the same 200 EUR as reclaimable, because those services were bought for your taxable business. Line one says you owe 200. Line two says you are owed 200. Net effect on the return: zero.

The form fields differ by country, but every EU VAT return has a box for VAT on cross-border services received and a box for deductible input VAT. Reverse-charge fills both with the same figure. You are not paying twice and you are not owed anything back. You are recording a transaction that, for a fully deductible business, has no cash consequence.

Where it starts to matter is alongside the rest of your return. If you also charged VAT to local customers, that output VAT is real money you collect and forward. The reverse-charge entries sit beside it, cancelling each other, while the customer VAT flows through normally. The studio's actual position is set by what you sell and what you spend, never by the reverse-charge mechanic itself, which is designed to be neutral.

One more practical note: keep the invoices. Even though no VAT changed hands with the vendor, you still need the document to support both the self-accounted VAT and the deduction. A tidy folder per quarter is enough. If you run sales through a platform like Shopify, export those records on the same cadence so everything reconciles in one sitting. For the wider workflow, Solo Studio Invoicing in 2026 walks through connecting invoicing, tax, and exports.

Three or Four Mistakes That Break the Zero

Most reverse-charge problems are setup errors, not math errors. Four show up again and again.

First, no VAT ID on file with the vendor. If you skipped that billing field, the platform charged you its local consumer VAT. That VAT is usually not reclaimable through reverse-charge, so it becomes a real surcharge on every renewal. Fix: add your VAT ID to every paid tool, and check that new invoices arrive with no VAT line.

Second, booking the reverse-charge VAT as a real expense. Some founders see "VAT due" on the return and treat it as a cost, or pay it without recording the matching deduction. That turns a zero into an unnecessary payment. The VAT due and the input VAT are a pair. Record both, every time, or use software that posts the two legs automatically.

Third, forgetting to file the return when it nets to zero. A quarter with only reverse-charge entries still nets to zero, but zero is a number you have to declare, not a reason to skip filing. A missed or late return invites penalties even though no tax was actually owed. Put the deadline in your calendar and file the zero like any other return.

Fourth, mixing consumer and business purchases. Buying a tool with a personal account and a private card, then trying to deduct it on the studio's return, breaks the trail. The invoice has to be in the business name with the business VAT ID for reverse-charge and the deduction to hold up. Keep one clear payment method and one account for studio tools, and the bookkeeping stops being guesswork.

None of these are hard. They are just easy to get wrong on the first invoice, before anyone has explained how the mechanism actually behaves.

Bottom Line

Reverse-charge VAT on foreign SaaS sounds intimidating and turns out to be neutral. Provide a valid VAT ID, sit on standard taxation rather than the small-business exemption, and self-account each import while deducting the same amount on the same return. The two entries cancel, and that 100 EUR tool stays 100 EUR.

The studios that get tripped up are the ones treating it as a real cost, skipping the VAT ID field, or never filing the zero return. The studios that breeze through it set up the billing fields once and let a clean monthly routine carry the rest. For a tool-heavy operation, standard taxation plus reverse-charge is almost always the cheaper, calmer path.

This is general practical experience, not formal tax advice. Rates, thresholds, and forms differ by country, so confirm the details for your registration before you rely on any of it. If you want to see how this fits into a working one-person operation, the wider setup lives at the RAXXO Studios page, alongside the invoicing and bookkeeping pieces it connects to.

I Replaced ESLint + Prettier with Biome Across 16 Repos: Setup, Wins, and 2 Gotchas

RAXXO Studios — Sat, 23 May 2026 21:37:26 +0000

Swapped ESLint plus Prettier for Biome across 16 repos, dropping from 5 dev dependencies to 1
One shared biome.json now governs every project, no more per-repo config drift
Lint plus format fell from roughly 9 seconds to under 1 second on the biggest repo
Two real gotchas: a thin plugin ecosystem and one import-sorting rule that needed a manual pass

For two years every RAXXO repo shipped with the same four-headed config monster: ESLint, Prettier, the plugins that glue them together, and the config files nobody wanted to touch. Last month I deleted all of it and moved 16 repos to Biome. The lint-plus-format step that used to take about 9 seconds now finishes in under a second, and the dev dependency list got a lot shorter.

Why I Walked Away From ESLint Plus Prettier

The setup worked. That was never the problem. The problem was that keeping it working cost time on every single repo. A typical project carried eslint, prettier, eslint-config-prettier, eslint-plugin-import, and whatever framework plugin the stack needed. Five packages, two config files (.eslintrc and .prettierrc), and a .eslintignore that always drifted out of sync with .prettierignore.

Multiply that by 16 repos and the math gets ugly fast. When a Prettier major version landed, I had to bump it everywhere, re-test formatting on every project, and chase the inevitable conflicts where ESLint wanted one thing and Prettier wanted another. The classic fight was quotes and trailing commas. You install eslint-config-prettier just to tell ESLint to stop arguing with the formatter. That package exists only because two tools are doing overlapping jobs.

Speed was the other wall. On my largest repo, a full eslint . pass sat around 7 seconds, and adding prettier --check . on top pushed the combined gate close to 9 seconds. That is slow enough that you stop running it locally and let CI catch things, which means slower feedback and noisier pull requests.

Biome collapses both jobs into one binary written in Rust. It is a formatter and a linter in the same tool, configured by a single biome.json. No plugin bridge, no "turn off the rules that conflict with the formatter" dance, because there is only one tool deciding. I had been watching it mature for a while, and once it covered the rules I actually relied on, the cost of staying on the old stack stopped making sense. For the broader pattern of trading a pile of plugins for one focused tool, I went through the same exercise with build tooling in the 6 Vite plugins that replaced my Webpack config.

Migrating 16 Repos Without Losing a Weekend

I did one repo by hand first to learn the shape of the work, then scripted the rest. Biome ships a migrate command that reads your existing config and translates it, which removed most of the guesswork.

The per-repo flow was four steps. Install Biome as the only lint and format dependency:


bun add -D --exact @biomejs/biome

Generate a starting config and pull in the old settings:


bunx biome init
bunx biome migrate eslint --write
bunx biome migrate prettier --write

Rip out the dead packages and their config files:


bun remove eslint prettier eslint-config-prettier eslint-plugin-import
rm -f .eslintrc .eslintrc.json .eslintignore .prettierrc .prettierignore

Then run the one command that both formats and lints with fixes applied:


bunx biome check --write .

That check command is the whole point. It formats, it lints, and with --write it applies every safe fix in a single pass. No more chaining two tools in your scripts.

To avoid copy-pasting config 16 times, I keep one shared biome.json in a tiny internal package and extend it per repo. A project config is now four lines:


{
  "$schema": "https://biomejs.dev/schemas/2.0.0/schema.json",
  "extends": ["@raxxo/biome-config"],
  "files": { "includes": ["src/**", "scripts/**"] }
}

The shared base holds the real rules:


{
  "formatter": { "enabled": true, "indentStyle": "space", "lineWidth": 100 },
  "linter": {
    "enabled": true,
    "rules": { "recommended": true }
  },
  "assist": { "actions": { "source": { "organizeImports": "on" } } }
}

CI got simpler too. The old job ran two steps; now it runs one:


- run: bunx biome ci .

biome ci is the read-only mode for pipelines. It checks formatting and lint rules and fails on any diff, without writing files. Across all 16 repos the migration took an afternoon, most of which was reviewing diffs rather than fixing breakage. If you want the runtime context behind these commands, I switched everything to Bun across every new RAXXO project first, which is why bunx shows up everywhere here.

The Wins Were Bigger Than I Expected

The headline is speed. On my largest repo the combined lint-and-format gate dropped from roughly 9 seconds to under 1 second. That is not a typo and it is not cherry-picked: Biome runs its checks in parallel across cores, and a single Rust binary has none of the Node startup and plugin-resolution overhead that the old chain paid on every invocation. Smaller repos that used to take 2 to 3 seconds now feel instant, low enough that the pre-commit hook stopped being something I wanted to skip.

Fast feedback changes behavior. When the check is under a second, I run it constantly while writing code instead of waiting for CI to flag a stray semicolon. Pull requests got quieter because formatting and obvious lint issues are fixed before the commit ever lands.

The dependency cut was the quiet win. Each repo went from five lint-and-format packages to one. Across 16 repos that is a meaningful drop in install time, lockfile churn, and the surface area I have to keep patched when a security advisory lands. Fewer transitive dependencies also means fewer of those 2am supply-chain headaches.

Then there is the mental overhead I got back. One config format. One CLI to remember. One thing to upgrade when a new version ships, instead of coordinating ESLint, Prettier, and three plugins that all version independently. New repos are faster to spin up because the lint-and-format story is extends one shared config and done. This is the same standardization payoff I wrote about after I unified icons in why I standardized on Phosphor icons across my repos, where collapsing many choices into one default removed a whole category of decisions.

I also stopped paying for the eslint-config-prettier tax entirely. When one tool owns both formatting and linting, there is nothing to reconcile, so a whole class of conflict bugs simply does not exist anymore.

Two Gotchas I Will Not Sugarcoat

This was not free of friction, and pretending otherwise helps nobody.

The first gotcha is the plugin ecosystem. ESLint has a decade of community rules, and Biome does not match that breadth yet. Most of what I relied on has a built-in Biome equivalent, but a few specialized ESLint plugins had no direct replacement. One repo leaned on a custom rule that enforced an internal import-boundary convention, and there was no Biome rule for it. I had two choices: drop the check or move it into a small standalone script. I moved it. If your team depends on a niche plugin or a hand-written ESLint rule, audit that before you commit to the switch, because you may end up rebuilding it.

The second gotcha was import sorting, and it bit me on the first repo. Biome organizes imports through its assist actions, not through a lint rule, and its sort order is not identical to what eslint-plugin-import produced. The first time I ran biome check --write it re-sorted imports across the whole codebase, which created a large and noisy diff. Worse, in two files the new grouping reordered a side-effect import (a CSS file that had to load before a component) and the ordering actually mattered at runtime. Nothing crashed loudly, but a style sheet loaded a beat late. The fix was to run the import organize step on its own first, review that diff in isolation, then commit it separately before touching any logic:


bunx biome check --write --formatter-enabled=false --linter-enabled=false .

Doing the import pass as its own commit kept the real review readable and let me catch the side-effect ordering before it shipped. Once that one-time cleanup was in, every repo after it went smoothly. Lesson learned: treat the first import re-sort as a dedicated migration commit, not a side effect of your normal check.

Bottom Line

If you run more than a couple of JavaScript or TypeScript repos and you are tired of babysitting ESLint, Prettier, and the glue packages between them, Biome is worth a serious look. One binary, one biome.json, one biome check --write that formats and lints in a single pass. My combined gate went from about 9 seconds to under a second, and every repo dropped from five lint-and-format dependencies to one.

It is not a drop-in for everyone. If you depend on a deep bench of ESLint plugins or custom rules, check coverage first, and plan a dedicated commit for the initial import re-sort so a stray side-effect ordering does not slip through. For most solo builders and small teams, the speed and the simpler config are well worth that one afternoon of migration.

I document every one of these stack decisions as I make them, both the wins and the things that bit me. If you want to see how the rest of the toolchain fits together across the studio, the full picture lives at RAXXO Studios.

ElevenLabs Studio Workflow: 4 Patterns for 12-Minute Solo Episodes

RAXXO Studios — Fri, 22 May 2026 10:10:16 +0000

Scripted-narration solo pod: 12 min finished in 38 min using ElevenLabs v3, costs 0.34 EUR per episode
Tutorial with code intercuts uses voice cloning + SSML pauses, 51 min total, 0.52 EUR
Multi-voice debate format runs 4 voices through one v3 Studio project, 1h 12 min, 0.71 EUR
B-roll narration for short-form pulls 6 clips from the long script in 14 min, 0.18 EUR per pack

I record almost zero of my own voice now. The four patterns below cover every piece of audio I ship for RAXXO Studios, from a 12-minute solo episode to a 30-second TikTok cut. Each one runs inside ElevenLabs Studio with a single project per episode. I track time-to-publish and cost per episode for each pattern because both numbers used to scare me off podcasting entirely.

Pattern 1: Scripted-Narration Solo Pod

This is the workhorse. One narrator, one script, one finished 12-minute MP3. I use it for the weekly RAXXO Lab audio companion that mirrors a blog article.

The flow is dead simple. I paste the script into v3 Studio, pick a single voice (a cloned one I made from 40 minutes of my own recordings), and let the engine render. The script is the blog post with three edits: contractions added, em dashes replaced with commas, and any inline code stripped out so the narrator does not try to read curly braces.

What v3 Studio does well here is paragraph-level emotion tagging. I drop a [thoughtful] or [laughing slightly] tag at the top of paragraphs that need a tone shift. Two or three tags per 12-minute script is the right amount. More than that and the voice starts to sound theatrical.

Time-to-publish from final script: 38 minutes. Breakdown: 6 minutes to paste and tag, 9 minutes to render in 1500-character chunks, 14 minutes to scrub and regenerate three lines that came out wrong, 9 minutes to export, normalize loudness in Auphonic, and upload to the host.

Cost per episode: 0.34 EUR. A 12-minute script is roughly 1800 spoken words, which is 9500 characters. At the Creator plan rate of about 18 EUR for 500,000 characters, that lands at 0.34 EUR of consumed budget. Two regenerations push it to 0.36 EUR. For comparison, the same episode recorded the old way (record, edit, master) used to eat 2.5 hours of my time and roughly 70 EUR of opportunity cost.

The killer feature is consistency. Episode 12 sounds exactly like episode 1. The cloned voice does not have a cold, did not stay up late, and never has a Berlin tram going past the window.

Pattern 2: Narrated Tutorial With Code Intercuts

Tutorials need to switch register. The narration explains the why in a warm tone, the code reading needs to be slower and more precise, and the wrap-up returns to the warm tone. v3 Studio handles this with a single project plus SSML pauses.

The setup: I segment the script into three voice blocks per section. Block A is the explanation, block B is the code walkthrough, block C is the takeaway. I drop a 500-millisecond SSML pause before each code block (``) and slow the code reading by 8% using the speed slider on that block only. The voice stays the same, only the pacing changes.

For code with symbols I write the symbols phonetically inside the script. const fn = (x) => x * 2 becomes const f n equals open-paren x close-paren arrow x times two. Ugly but it reads correctly the first time. The first 6 tutorials I tried without this hack had at least 2 regenerations per code block. Now I get most of them in one render.

Time-to-publish: 51 minutes for a 12-minute tutorial episode. The extra 13 minutes over Pattern 1 is the phonetic code rewrite and the per-block speed adjustments.

Cost per episode: 0.52 EUR. Tutorials run longer in characters (more verbose explanations), so the same 12-minute target spoken minutes hits roughly 14,500 characters. The slower code blocks also push character billing slightly because the engine pads silence.

Two things I learned the hard way. First, never paste real terminal output into the script. The narrator will try to read it. Replace it with a one-sentence summary. Second, the [whisper] tag does not survive code blocks. Use a separate voice block with manual volume reduction instead. That cost me 9 EUR of regenerations across three tutorials before I figured it out.

If you want the full story on getting voice consistency right, the deeper dive lives in the ElevenLabs vs Other AI Voice Tools comparison.

Pattern 3: Multi-Voice Debate Format

This is the most fun pattern and the only one that draws real listener feedback. Four characters debate a take, like "should solo studios run Postgres or SQLite," and each one has a distinct voice, accent, and pace. The whole 12 minutes runs inside one v3 Studio project, no audio editor needed.

Voice picks: I use one cloned voice for the host, plus three library voices chosen for clear separation. A clipped British male for the skeptic, a slow Midwest American female for the practitioner, and a fast New York male for the contrarian. The library has hundreds of options; I pick the four that sound least like each other.

The script is structured as a screenplay. Each line starts with [host], [skeptic], [practitioner], or [contrarian]. v3 Studio's project view lets me assign a voice to each tag globally, so I do it once at the top of the project. Reassigning later is one click.

The trick that makes this not sound like a synthesized panel: I write in actual interruptions. Lines that get cut off mid-thought with a hyphen at the end. Lines that respond to the previous speaker by name. Beats of [laughs] and [skeptical] sprinkled in where a human would react. These tiny touches are what make the format feel produced, not algorithmic.

Time-to-publish: 1 hour 12 minutes for a 12-minute episode. Most of the extra time is writing the script. The rendering itself is no slower than Pattern 1.

Cost per episode: 0.71 EUR. Four voices, more emotion tags, occasional [laughs] calls that count as characters. Higher than Pattern 1 but still under one euro per finished episode.

For the bigger picture on where AI voice is going and the ethics around it, AI Voice Generation: Tools, Ethics, and Practical Use Cases is the primer I send people first.

Pattern 4: B-Roll Narration for Short-Form Social Cuts

The fourth pattern is the multiplier. Every long episode I produce gets sliced into six short-form clips for Reels, Shorts, and TikTok. Instead of re-recording the narration for each cut, I extract six 25-to-40-second segments straight from the long-form script and re-render them with v3 Studio at a slightly punchier delivery.

The reason I re-render rather than slice the long-form audio: short-form needs different pacing. The long episode breathes. A Reel cannot afford a 600ms pause. So I take the same words, drop the SSML pauses, bump the speed by 5%, and add a [confident] tag at the start. Same voice, tighter delivery.

I batch all six into one v3 Studio project. Each segment is its own block so I can re-render any single one without touching the others. Total render time is under 3 minutes for six clips.

For B-roll footage I pair the audio with motion plates generated from Magnific and a few stock clips I keep in a per-episode folder. The visuals get queued separately, but the narration is locked in by the time I open the editor.

Time-to-publish for a 6-clip pack: 14 minutes. Breakdown: 4 minutes to slice the script, 3 minutes to render, 4 minutes to export and rename, 3 minutes to drop into the social scheduler.

Cost per pack: 0.18 EUR. Each clip averages 700 characters, so six clips is about 4200 characters. Roughly 0.15 EUR plus a regeneration or two.

Distribution is handled by Buffer. One scheduler holds the long-form post on Spotify, the YouTube clip on the studio channel, and the six short-form pieces across Instagram, TikTok, and YouTube Shorts. The whole pack goes from voice render to scheduled in under 30 minutes.

Bottom Line

Four patterns, one tool, every audio piece I ship for RAXXO Studios. Total cost for a long episode plus its six short-form children: about 0.52 EUR for the workhorse case, 0.89 EUR for the debate format. Total time-to-publish for the full package, long plus shorts: 52 to 86 minutes depending on the pattern.

What used to be a podcast production stack with a microphone, a DAW, a noise reducer, a leveler, and three hours of attention is now a paste-tag-render loop inside a browser. The voice sounds like me because the cloned voice IS me, just one that does not get tired. The math works at zero scale (one episode a week) and at twenty scale (a launch week).

If you want the studio storefront where all the audio companions live alongside the products they pair with, that runs on Shopify. The hub for everything in the AI Voice/Video cluster is here.

5 agent-browser Workflows That Replaced My Manual Daily Checks

RAXXO Studios — Fri, 22 May 2026 10:01:44 +0000

Replaced 5 manual daily checks with agent-browser scripts saving 6 hours per week
Slack unread sweep across 14 channels runs in 22 seconds, replaced a 40 EUR/month notifier
IG insights pull every morning, killed a 29 EUR/month analytics SaaS
Shopify order check and syndication status sweep run before coffee
Competitor pricing watch fires a desktop notification when 3 rival stores move price

I used to start every morning with 12 browser tabs and a checklist. Slack, Instagram, Shopify, Dev.to, Hashnode, three competitor stores. By the time I finished checking everything, two hours were gone and the actual work had not started. So I wrote 5 agent-browser scripts that do the rounds for me. Total time saved: about 6 hours per week.

Here is what each one does, the actual command shape, and what it replaced.

1. Slack Unread Sweep Across 14 Channels

The first script is the one I run before I even open my laptop properly. It walks 14 Slack channels, captures any unread count above zero, and prints a single block of text I can scan in 10 seconds.

Old workflow: open Slack, click every channel, mentally track which ones moved. Took about 8 minutes a day, longer if I got distracted in the first channel I opened. I had also tried a paid Slack notifier at 40 EUR per month that flooded me with desktop pings I learned to ignore.

The agent-browser version connects to my already-running Chrome, navigates to each channel URL, reads the unread badge, and writes a summary to a file.


// slack-sweep.js
const channels = ['general', 'dev', 'design', 'sales', 'support'];
for (const ch of channels) {
  await page.goto(`https://app.slack.com/client/T0XXX/${ch}`);
  await page.waitForLoadState('networkidle');
  const snap = await page.snapshotForAI();
  const unread = snap.match(/(\d+) unread/)?.[1] || '0';
  console.log(`${ch}: ${unread}`);
}

I run it with dev-browser --connect ./slack-sweep.js. The connect flag attaches to my logged-in Chrome session, so no auth dance. Total runtime: 22 seconds for all 14 channels.

The script also writes the output into my terminal statusline, so when I cd into any project I see a number like "Slack: 3 channels active" without having to switch apps. That nudge replaced the panicked "did I miss something" feeling that used to drag me back into Slack three times an hour.

Time saved per week: roughly 50 minutes. Money saved: 40 EUR per month from killing the paid notifier.

2. Instagram Insights Pull, Daily

Instagram does not have a clean API for personal accounts. The Graph API needs a Business account and OAuth dance, and even then the daily insights data is two days behind. So I scrape my own insights page instead.

Old workflow: open IG on phone, tap profile, tap insights, screenshot, type the numbers into a spreadsheet. Eight taps, every morning. I also paid 29 EUR per month for an analytics SaaS that mostly showed the same numbers IG already shows for free.

The script opens the insights page, captures impressions and reach for the last 7 days, and appends one row to a CSV.


// ig-insights.js
await page.goto('https://www.instagram.com/raxxostudios/insights');
await page.waitForSelector('[role="tab"]:has-text("Last 7 days")');
const snap = await page.snapshotForAI();
const impressions = snap.match(/Impressions[\s\S]+?(\d[\d,]+)/)?.[1];
const reach = snap.match(/Reach[\s\S]+?(\d[\d,]+)/)?.[1];
const today = new Date().toISOString().slice(0, 10);
require('fs').appendFileSync('ig-daily.csv', `${today},${impressions},${reach}\n`);

The snapshotForAI() call is the key trick. It returns a flattened DOM string that is dramatically easier to regex than raw HTML. I learned that pattern from the dev-browser README and have leaned on it for every script since.

Time saved: 10 minutes per day. SaaS cancelled: 29 EUR per month.

One thing to watch: Instagram changes the DOM structure roughly every 6 weeks. My script broke twice in 3 months. Each time the fix was a 5-minute regex tweak after re-running snapshotForAI() and seeing what the new labels looked like. Compared to the SaaS I cancelled (which broke for 11 days in February and went silent on support), I will gladly take a 5-minute fix every other month.

3. Shopify Order Check Before Coffee

I run Shopify for raxxo.shop and like to know overnight orders the moment I sit down. The admin app on phone is fine but it forces me into the phone before I have decided I am awake.

Old workflow: phone in bed, unlock, app, orders, scroll. Twice I ended up doomscrolling for 30 minutes before I even stood up.

The agent-browser version pulls the order count for the last 12 hours and the total sales sum, then writes it to a file I display in my terminal statusline.


// shopify-orders.js
await page.goto('https://admin.shopify.com/store/c88aa1-4/orders?created_at_min=' +
  new Date(Date.now() - 43200000).toISOString());
await page.waitForLoadState('networkidle');
const snap = await page.snapshotForAI();
const count = snap.match(/(\d+) orders?\s/)?.[1] || '0';
require('fs').writeFileSync('/tmp/shopify-status.txt', `Overnight: ${count} orders`);

The Shopify admin is heavy but agent-browser handles it well because the script attaches to my real Chrome, so cookies and 2FA are already past. Runtime: 4 seconds.

The bigger win is not the time, it is removing the phone from the morning. That alone was worth writing the script.

I also added a second variant that pulls the inventory level for my 3 most-watched products. If any product drops below a threshold I set, it writes an entry to a restock.txt file I check on Mondays. Same 10-line shape as the order check, different selector. The pattern is so reusable that any new check costs me about 10 minutes to add.

4. Syndication Status Sweep After Every Publish

I cross-post every blog article to Dev.to, Hashnode, and a handful of other platforms. Most of that pipeline is API-driven, but two platforms only have web UIs, and I want to know they actually accepted the post before I move on to the next task.

Old workflow: open Dev.to, search my username, scroll to find the new post, click it, confirm it rendered. Repeat on Hashnode. Repeat on Medium when I still bothered with it. Eight minutes of clicking per article.

The script opens each platform's "my posts" page, checks that the most recent post matches the slug I just published, and prints a status line per platform.


// syndication-check.js
const slug = process.argv[2];
const targets = [
  { name: 'Dev.to', url: 'https://dev.to/raxxostudios' },
  { name: 'Hashnode', url: 'https://raxxostudios.hashnode.dev' }
];
for (const t of targets) {
  await page.goto(t.url);
  const snap = await page.snapshotForAI();
  const ok = snap.toLowerCase().includes(slug.toLowerCase());
  console.log(`${t.name}: ${ok ? 'LIVE' : 'MISSING'}`);
}

I wired this into the post-publish hook in my blog publishing pipeline. The minute the publish step finishes, it kicks off this check and prints to terminal. If a platform reads MISSING, I know to re-fire the syndication for that one only.

Time saved per article: 8 minutes. I publish about 4 articles a week, so 32 minutes recovered.

5. Competitor Pricing Watch, Once an Hour

Three competitor stores sell products in my space. I do not change my prices reactively, but I do want to know if all three move at once. That is usually a signal something upstream changed (supplier, ad costs, a new platform rule).

Old workflow: I tried to remember to check weekly, failed most weeks, then panicked once a month and binge-checked all three.

The script visits each store, captures the price of one anchor product, and appends to a log. A separate one-liner checks if all three moved in the same direction in the last 24 hours and fires a desktop notification.


// pricing-watch.js
const stores = [
  { name: 'rival-a', url: 'https://rival-a.com/products/anchor', sel: 'price' },
  { name: 'rival-b', url: 'https://rival-b.com/products/anchor', sel: 'price' },
  { name: 'rival-c', url: 'https://rival-c.com/products/anchor', sel: 'price' }
];
for (const s of stores) {
  await page.goto(s.url);
  const snap = await page.snapshotForAI();
  const price = snap.match(/€\s?(\d+[.,]?\d*)/)?.[1];
  require('fs').appendFileSync(`pricing-${s.name}.log`, `${Date.now()},${price}\n`);
}

I run it on a cron job hourly with dev-browser --headless ./pricing-watch.js. Headless mode is fine here because none of these stores need auth. The notification fires only when all three logs show a movement in the same direction, which has happened twice in 6 weeks.

Time replaced: maybe an hour per month of manual checks. The real value is the alert, not the time.

The cron line for this one looks like 0 * * * * cd /Users/me/scripts && dev-browser --headless ./pricing-watch.js >> pricing.log 2>&1. Hourly is plenty, since these stores rarely move price more than once a week. I keep the logs raw and parse them with a quick awk one-liner when I want to see the 30-day trend.

Bottom Line

5 scripts, about 6 hours saved per week, 69 EUR per month in SaaS cancelled. The whole setup took an afternoon to write, and most of the scripts share the same 10-line pattern: connect to Chrome, navigate, snapshot, regex, write to file.

If you have any morning routine that involves the same 3 browser tabs every day, you can probably replace it with a 15-line agent-browser script. The hardest part is realising you do not need a paid SaaS or a bot, you just need a script that does what you used to do with your fingers.

For more on the underlying tool, see my earlier piece on AI Agents Just Got a Real Browser. For other ways to chain agents together, jump to The Claude Cowork Plugin Ecosystem. Or browse the full RAXXO Lab for more practical builds.

5 Vercel Edge Config A/B Tests That Lifted My Shopify CTR

RAXXO Studios — Fri, 22 May 2026 10:00:26 +0000

Hero copy split lifted clicks 18% with a 12-line Middleware snippet and zero rebuilds
Geo flag for free shipping pulled checkout intent up 9% in DE/AT/CH only
Sticky CTA variant beat the static button 14% on mobile, no layout shift
Price display test (1.234,56€ vs 1,234.56€) won by 6% for European visitors
Kill switch on a flaky review widget recovered 4% of lost add-to-carts in under 60 seconds

I ship Shopify storefronts on Vercel and use Edge Config for every A/B test now. No rebuilds, sub-15ms reads at the edge, and toggles propagate in under a second worldwide. Here are the five test patterns I actually run, with the Middleware snippets I use and the lift each one produced.

If you want the full overview of why I picked this stack, see 5 Vercel Edge Config Patterns I Use For Shopify A/B Tests. This article goes one layer deeper into the actual experiments.

1. Hero Copy Split (lifted clicks 18%)

The first test you should ever run on a Shopify storefront via Edge Config is a hero copy split. Two headlines, one randomized cookie, zero rebuilds.

Edge Config schema:


{
  "hero_copy_test": {
    "enabled": true,
    "variants": {
      "A": "Build calmer Shopify stores.",
      "B": "Ship Shopify stores that load in 800ms."
    }
  }
}

Middleware (middleware.ts):


import { get } from '@vercel/edge-config'
import { NextResponse } from 'next/server'

export async function middleware(req) {
  const test = await get('hero_copy_test')
  if (!test?.enabled) return NextResponse.next()
  const bucket = req.cookies.get('hero_ab')?.value
    || (Math.random() < 0.5 ? 'A' : 'B')
  const res = NextResponse.next()
  res.cookies.set('hero_ab', bucket, { maxAge: 60 * 60 * 24 * 30 })
  res.headers.set('x-hero-variant', bucket)
  return res
}

The page reads x-hero-variant from the request headers and renders the right copy. I tag the variant on every PostHog event and let it run for 7 days.

In my run, variant B (the specific 800ms claim) beat the calm headline by 18% on click-through to /collections/all. Outcome over vibes wins almost every time.

Two notes on this pattern. First, the bucket lives in a cookie so the same visitor sees the same variant across navigations. Second, propagation time matters: when I flip enabled to false in the dashboard, every edge POP picks it up in under a second. That is the part client-side flag libraries cannot match because they ship a JS payload and run after hydration.

2. Geo-Aware Free Shipping Flag (9% checkout intent)

Free shipping converts, but global free shipping kills your shipping P&L. Edge Config plus the x-vercel-ip-country header gives you a per-country flag with one read.

Schema:


{
  "free_shipping_geo": {
    "DE": { "active": true, "threshold_eur": 0 },
    "AT": { "active": true, "threshold_eur": 0 },
    "CH": { "active": true, "threshold_eur": 80 },
    "US": { "active": false, "threshold_eur": 0 }
  }
}

Middleware:


const country = req.geo?.country || req.headers.get('x-vercel-ip-country')
const cfg = await get('free_shipping_geo')
const flag = cfg?.[country]
if (flag?.active) {
  res.headers.set('x-free-ship', '1')
  res.headers.set('x-free-ship-threshold', String(flag.threshold_eur))
}

The Shopify theme reads those headers via a Next.js route handler that proxies to the storefront, and the banner only renders for visitors in DE, AT, and CH. Checkout intent (proceed-to-checkout clicks) lifted 9% in those three markets while US and rest-of-world stayed flat. Edge Config let me kill the experiment for any country in one second if returns started climbing.

I also covered the broader pattern in 5 Cloudflare Workers Patterns I Use for Shopify Edge Logic if you're on Cloudflare instead of Vercel.

One thing to watch: req.geo is populated on the Edge runtime, but the x-vercel-ip-country header is the safer fallback in case you ever swap runtimes. Keep both lines. I also write the resolved country to a cookie so the page can render the banner immediately on the next navigation without re-reading headers.

3. Sticky CTA Variant (14% on mobile)

Mobile is where the money is and where the CTA gets lost. I tested a sticky bottom-bar Add to Cart against the static in-card button.

Schema:


{
  "sticky_cta": {
    "enabled": true,
    "split": 0.5,
    "label": "Add to bag",
    "min_viewport_px": 0,
    "max_viewport_px": 768
  }
}

Middleware sets the bucket and a viewport-gated flag. The theme injects a 56px tall fixed bar that animates in after 400px of scroll. No layout shift because I reserve the height with padding-bottom: env(safe-area-inset-bottom, 56px) on `` only when the variant is active.

`javascript

const sticky = await get('sticky_cta')
if (sticky?.enabled) {
const bucket = Math.random() < sticky.split ? 'sticky' : 'static'
res.cookies.set('cta_ab', bucket, { maxAge: 86400 * 14 })
res.headers.set('x-cta-variant', bucket)
}

Lift: 14% more add-to-bag clicks on viewports under 768px, with no measurable hit to Largest Contentful Paint. I keep the sticky variant on for mobile and serve the static one to desktop where it already wins.

The reason I gate by viewport in Edge Config (instead of CSS media queries) is so I can ramp the experiment. Day one, I set split: 0.1 to see 10% of mobile visitors. Day three, if the numbers look healthy, I bump it to 0.5. Day seven, I either keep it at 0.5 or roll forward. No deploy needed, just a JSON edit.

4. Price Format Experiment (6% for EU visitors)

European number formatting matters more than people think. I tested 1.234,56€ (EU) against 1,234.56€ (US-with-Euro) for visitors from DE, AT, CH, NL, BE, and FR.

Schema:

`json

{
"price_format": {
"eu_visitors": "eu",
"default": "us",
"currencies": ["EUR"]
}
}

Middleware:

`javascript

const EU = new Set(['DE','AT','CH','NL','BE','FR'])
const fmt = await get('price_format')
const country = req.geo?.country || ''
const variant = EU.has(country) ? fmt.eu_visitors : fmt.default
res.headers.set('x-price-format', variant)

The product page formats prices server-side from the header. The EU format won by 6% on the add-to-bag click for EU traffic. Trust signal, plain and simple. The number looks native, the brain doesn't pause, the click follows.

Note: this is purely a display test. The cart and checkout always use Shopify's stored format, so accounting and tax stay clean.

One trap I hit early: I forgot to pass the format through to the cart drawer, which still showed the US-style number. The mismatch confused EU buyers and one of them emailed me about it. Fix was a single prop drilling pass, but it shows why you want a single source of truth for the variant header and let every component read from it.

5. Kill Switch on a Flaky Third-Party Widget (recovered 4% add-to-carts)

The most underrated A/B test is the one where B is "off". Third-party widgets (review apps, chat, popups) break in production. Edge Config gives you a kill switch you can flip from the dashboard without touching code.

Schema:

`json

{
"widgets": {
"reviews": { "enabled": true, "fallback": "static" },
"chat": { "enabled": true },
"popup": { "enabled": false }
}
}

The Shopify theme conditionally injects each widget's script tag based on a header set by the Middleware:

`javascript

const w = await get('widgets')
res.headers.set('x-widgets', JSON.stringify({
reviews: w?.reviews?.enabled ? 1 : 0,
chat: w?.chat?.enabled ? 1 : 0,
popup: w?.popup?.enabled ? 1 : 0,
}))

When the review widget started failing in production (third-party CDN had a bad day), I flipped reviews.enabled to false in Edge Config. The change hit every edge POP in under a second. The static fallback (server-rendered last 3 reviews) took over, and add-to-cart rate recovered 4% within minutes.

I now treat every third-party script as an experiment with a flag. If the script breaks, the flag goes off. No deploys, no panic. Edge Config is the closest thing to a real circuit breaker on a Shopify storefront.

Pair this with a tiny health-check route (/api/health/widgets) that hits each third-party endpoint every few minutes and flips the flag automatically if any of them return a non-200 for 3 checks in a row. I run this on a Vercel Cron. Self-healing storefronts are not a fantasy anymore. They take maybe 50 lines of code per widget.

Bottom Line

Edge Config replaced a 50 EUR/month LaunchDarkly bill and a slower client-side flag library on my Shopify projects. The five patterns above run all the time on a single store and cost roughly 5 EUR/month in Vercel bandwidth.

Pick one to start. Hero copy split is the lowest risk and highest learning per day. The kill switch is the highest insurance per minute. Once you have the Middleware wired, every new test is 10 lines of JSON and a deploy preview.

A few things I learned the hard way running these patterns side by side. Always namespace your keys (hero_copy_test, not hero), so two experiments don't fight for the same field when you delete or rename. Always log the variant on every analytics event so you can slice later. And never read more than 2 keys per request in Middleware: Edge Config is fast, but every read still adds 2-5ms. Group related flags into one object.

If you want the broader stack context, The 5 Vercel Cron Jobs That Keep My Studio Running pairs nicely. Crons for the writes, Edge Config for the reads. Together they cover most of what a solo Shopify operator needs from Vercel.

More patterns and write-ups in the RAXXO Lab if you want to keep going.

Why I Standardized on Phosphor Icons Across 15 Repos (And Cut 60% of Icon Bundle Size)

RAXXO Studios — Fri, 22 May 2026 00:04:23 +0000

Five icon systems across 15 repos created visual drift and 84KB bundles in the worst Next.js app.
Phosphor ships six weights from one designer, so the whole studio reads as one product.
Liquid themes use Fill weight, React apps use Regular, never mixed in the same surface.
A 40-icon migration across 15 repos took one afternoon with ripgrep and a small codemod.
Tree-shaken Phosphor lands at 18KB, a 78% cut on the worst case and roughly 60% on average.

I caught the problem on a Tuesday. I had two RAXXO tabs open side by side. One was a Next.js dashboard, the other a Shopify product page. Both had a small rocket icon near the primary CTA. They were the same idea, the same size, the same color. They did not look related.

The dashboard icon was a thin stroked Lucide rocket. The Shopify icon was a chunky Heroicons solid. Next to each other they read as two different brands. I had been telling people RAXXO was one studio, one system, one feeling. The icons were calling me a liar.

That afternoon I started counting how many icon systems were actually live across the studio. The answer was five. The fix was one. This is the story of how I collapsed five into one, why Phosphor won, and the bundle math that turned a vanity migration into a measurable performance win.

The Five Icon Systems I Had Before Phosphor

Here is what was actually shipping across the 15 repos.

Heroicons was the original choice in three Next.js apps. I had used both @heroicons/react/24/solid and @heroicons/react/24/outline because some screens needed solid and some needed outline. That meant two icon packs imported in the same app. Tree-shaking helps, but I had a habit of importing the whole module in a few places, and the worst app was pulling 84KB of icon code into the client bundle.

Lucide had crept into two newer Next.js apps because I liked the stroke weight. It tree-shook better, landing at 31KB for similar icon counts. The visual rhythm was fine inside those apps. The problem was that Lucide strokes and Heroicons solids look nothing alike.

Emoji as icons was the dirty secret of three vanilla HTML landing pages. A rocket emoji next to a CTA reads fine on macOS Safari. It reads like a different font on Windows Chrome. It reads like a small typographic accident on Android. I had told myself it was fine because the pages were temporary. Several of those pages had been live for a year.

Custom inline SVGs were scattered across four Shopify themes. Some were ripped from old Figma exports. Some I had drawn myself at 2 a.m. They had no consistent stroke width, no consistent corner radius, no consistent viewport size. A few were 24x24, a few were 32x32, one mystery icon was 20x20 with a 1.5px stroke that looked thinner than everything around it.

Font Awesome stragglers lived in two Shopify themes I had inherited from earlier work. Loading the full Font Awesome CSS to render four icons is the kind of decision you make once and then ignore for two years. I was ignoring it.

Five systems, no shared visual logic, four different stroke weights on any given Tuesday. That was the problem.

Why Phosphor Won: Six Weights, One Visual System

I evaluated three replacements. Heroicons was the incumbent and lost on weight count. Lucide was a strong contender, especially for tree-shaking and React ergonomics. Phosphor (https://phosphoricons.com) won on the dimension that mattered most for a studio that ships across Liquid, React, and vanilla HTML: weight options inside one family.

Phosphor ships six weights of the same icon set: Thin, Light, Regular, Bold, Fill, and Duotone. Every icon is drawn by the same hand at every weight. That means I can pick a heavier weight for one platform and a lighter weight for another and still have them read as one system.

That sounds like a small thing. It is the entire reason this works.

Dark themes eat thin strokes. On raxxo.shop, the background is #1f1f21 and the text is #F5F5F7. A 1.5px stroke icon at 20px size disappears into the background noise. A filled icon at the same size has presence. The Shopify theme needed Fill weight.

The React apps have lighter backgrounds in places, denser layouts, and more icons per screen. A Fill weight there would feel shouty. Regular weight, with its 1.5px stroke, sits cleanly in dense UI.

With Heroicons I could pick solid or outline, two options. With Lucide I had one weight and a stroke-width prop, which is not the same as a hand-drawn weight variant. With Phosphor I had six weights drawn by the same designer, and I only needed two of them.

The decision was made by Friday.

The Liquid vs React Split: Fill in Themes, Regular in Apps

The rule I locked in across the studio is simple. Liquid themes get Phosphor Fill. React and Next.js apps get Phosphor Regular. No surface mixes weights.

In Shopify themes I do not import a package. I drop the SVG path data inline. That keeps the theme dependency-free and lets the icon render before any JavaScript loads. Here is the convention I use in every Liquid snippet.


{% comment %} Phosphor Fill weight, inline SVG, no JS dependency {% endcomment %}

The ph-fill and ph-rocket-launch classes are mine, not Phosphor's. They give me a CSS hook for hover states and color overrides without touching the SVG attributes. I grab the raw path data from the Phosphor site and paste it once into a Liquid snippet. From then on the icon is just {% render 'icon-rocket-launch' %}.

In React apps I import from @phosphor-icons/react, which is the official package. It tree-shakes correctly when you import individual components. Here is the pattern I use everywhere.


import { RocketLaunch } from '@phosphor-icons/react';

export function CTA() {
  return (

      Launch project


  );
}

The weight="regular" prop is explicit, even though Regular is the default. I want the convention visible in the code so the next person (or the next me) does not casually drop a Fill icon into a React app.

The Shopify (https://shopify.pxf.io/5k5rj9) theme repos and the Next.js app repos now share a vocabulary. A rocket means the same thing in both places. It just wears different clothes for the room.

This is the same logic I used when I built the 4-tier dark mode color system for these projects. Different surfaces, shared rules.

The Migration: 40 Icons, 15 Repos, One Afternoon

The studio uses about 40 unique icons across all 15 repos. I counted by grepping for icon imports across the workspace.

Step one was inventory. Ripgrep made this fast.


rg "from '@heroicons" -l
rg "from 'lucide-react'" -l
rg "fa-(rocket|cart|user)" -l

I dumped every match into a spreadsheet with the file path, the old icon name, and the intended Phosphor equivalent. Forty rows, sorted by repo. That spreadsheet became the migration plan.

Step two was the codemod for React apps. Heroicons and Lucide have different import paths and different component names, so a single regex was not enough. I wrote a small Node script that walked each repo, parsed import statements, and rewrote them. The Heroicons RocketLaunchIcon became Phosphor RocketLaunch. The Lucide Rocket became Phosphor RocketLaunch. Naming differences were handled by a hand-written map in the script. Sixty lines of code, including the map.

Step three was the Liquid themes. No codemod here. I copied 40 Phosphor Fill paths into a snippet folder, one file per icon, named like icon-rocket-launch.liquid. Then I did a find-and-replace across each theme: old inline SVG out, {% render 'icon-rocket-launch' %} in. This was the slowest part, maybe two hours, because I had to eyeball each old icon to figure out which Phosphor name matched it.

Step four was the emoji-as-icons cleanup on the vanilla HTML pages. I replaced each emoji with the same inline SVG pattern as the Liquid themes. Same paths, same class names. One copy-paste per icon.

By 6 p.m. the workspace was on one icon system. Fifteen repos, one weight per platform, zero mismatches between any two RAXXO tabs.

I committed each repo separately with a message that explained what changed and why. That commit log is now my reference if I forget which icons existed before. Future me will thank present me.

Bundle Math: 84KB to 18KB on the Worst Case

The headline number is real. The worst-case Next.js app was importing 84KB of icon code before the migration. Heroicons solid plus Heroicons outline, both pulled into client bundles, with a few lazy imports that defeated tree-shaking. Lighthouse was flagging it on slower connections.

After the migration, that same app imports 18KB of Phosphor icon code. Tree-shaken, individual component imports, no barrel files. That is a 78% reduction on the worst case.

The other Next.js apps were already on Lucide at 31KB. They dropped to 18KB. About a 42% reduction.

Average across all the JS-bundle-relevant repos, the cut is roughly 60%. That is the number I put in the title because it is the honest studio-wide figure.

The Shopify themes do not have a bundle cost in the same way. Inline SVG paths add a small amount of HTML weight per page, but no JS, no font file, no extra HTTP request. The Font Awesome removal alone saved 76KB of CSS from two themes. That weight is gone from the critical render path.

A few specifics on how to actually hit 18KB. Import each Phosphor icon as a named import from the root package, not from a deep path. The package's ESM build is set up so named imports tree-shake correctly. Do not import the whole module with a wildcard. Do not import from @phosphor-icons/react/dist/... directly. The clean path is the boring path.

For very heavy pages with rarely used icons, dynamic import works fine.


const Settings = dynamic(() =>
  import('@phosphor-icons/react').then(m => m.Settings)
);

I use this on dashboard surfaces where a settings panel is mounted lazily. It saves another 0.4KB per icon kept out of the initial bundle. Small, but it adds up across a dense app. The same approach is described in my notes on Tailwind v4 tokens, where lazy imports keep the critical CSS lean.

Bottom Line

One icon family, two weights, fifteen repos. That is the whole system. A rocket icon in a Shopify checkout and a rocket icon in a Next.js dashboard now feel like siblings. They wear different weights because their environments are different. They come from the same hand because the studio is one studio.

The bundle savings were the side effect that justified the migration to the part of my brain that needs measurable wins. Cutting 84KB to 18KB on the worst app, dropping 60% on average, removing Font Awesome from two themes. Those numbers are real and they ship to every visitor.

The deeper win is the one I cannot put in a Lighthouse report. Visual consistency across surfaces is what makes a studio feel like a studio instead of a folder of side projects. Phosphor (https://phosphoricons.com) gave me one family with enough weights to handle every platform I touch. I picked two of the six weights and locked the rule in. The hard part was deciding. The migration was an afternoon.

30 Days With the Magnific Image Pipeline: What Stuck and What Got Killed

RAXXO Studios — Thu, 21 May 2026 13:10:00 +0000

Spaces replaced three separate tools in my image pipeline and cut context switching to near zero.
Relight turned phone-shot product photos into store-ready images without a studio setup.
Generative Expand failed on 7 out of 10 blog OG images and got cut from the pipeline.
Style Transfer drifted character likeness too far for Lexxa and got benched for brand work.
The single ZIP-fingerprint fix saved 8 hours a week of manual file renaming.

Last Tuesday I needed an OG image for a Lab article on AI tool pricing. Thirty seconds in Spaces, a relight pass, a Photoshop trim, a Shopify API push. Done in under four minutes. Six months ago that same OG would have eaten 90 minutes across Midjourney, Photoshop, manual upload, and a coffee break I did not need.

That four-minute number is why I want to write this. 30 days into running Magnific as the spine of my image pipeline, some things stuck hard and some things got quietly killed off. This is not a feature tour. It is the honest audit of what survived the month and what did not, from a solo studio that ships blog OG images, Shopify product shots, and AI character work every single day.

Magnific used to be Freepik. They rebranded on 2026-04-28, same company, same product surfaces, new name. The affiliate code stayed the same too (mQMIvsh), so if you switched away during the rebrand confusion, your old link still works.

What Stuck: Spaces Workspace Replaced Three Tools

Spaces is Magnific's workspace concept. One canvas, multiple generations, drag and drop, version history. Before Spaces I was running Midjourney in a Discord tab, Topaz Gigapixel for upscales, and Photoshop for compositing. Three apps, three exports, three filename conventions, three places to lose work.

In 30 days I generated 247 images across 18 Spaces. The Spaces canvas held generation, upscale, relight, and fill in one view. I never opened Discord for image work once. I opened Photoshop 31 times instead of 200+, and almost always for final cleanup, not for combining tools.

The concrete moment that sold me: I was building a 6-image carousel for the Statusline Builder product page. Old workflow would have been 6 Midjourney prompts, 6 Topaz upscales, 6 Photoshop crops, 6 manual uploads. In Spaces I did it as one session, one history, one ZIP export, 22 minutes start to Shopify. I closed the canvas and had nothing left to clean up because everything lived in the Space.

The version history is the part nobody talks about. Every generation, upscale, and relight stays addressable inside the Space. I can pull version 4 of an image I made 18 days ago without digging through a Downloads folder of 700 files named output_final_v2_real.png. For a solo studio that ships daily, that single feature kills more chaos than any prompt improvement ever did.

What Stuck: Relight Made Product Photography Optional

I do not own a softbox. I never will. I shoot product on my desk with whatever light is in the room and it always looks like that, which is the wrong kind of authentic for a Shopify store.

Relight takes a flat phone photo and re-renders the lighting as if it came from a studio. Real shadows, real reflections, real direction. I ran 14 product shots through it this month. Eleven shipped to the store as-is after a Photoshop background swap. The other three needed a second pass with a different light direction, which Relight handles by dragging an arrow on the source image.

The number that matters here: 14 product shots in 30 days versus 4 in the previous 30. I am shipping 3.5x more product imagery because the photography step stopped being a project. My desk is the studio now. The before/after on the Pulse Dashboard hero image is the cleanest example. Phone shot at 11pm, relit at 11:04pm, on the storefront at 11:18pm.

The failure mode worth flagging: Relight does not invent geometry it cannot see. If the source photo lost a shadow side to clipping, Relight cannot recover it cleanly and will sometimes paint a flat gray patch where a real shadow should fall. Shoot the source slightly flatter than you think you need, then let Relight do the dramatic lighting. The reverse order does not work.

What Got Killed: Generative Expand for OG Images

Generative Expand fills outside the original frame. In theory it is perfect for OG images, since Spaces generates at square and OG is 1200x630. Expand the square outward, get the OG ratio, ship it.

In practice it failed on 7 out of 10 attempts. The expanded edges generated faces that drifted, hands that grew extra fingers, gradient halos that did not match the brand, and once a chair leg that turned into a snake. I tried it across three different prompt styles and four image categories. The success rate never crossed 30 percent.

What killed it was the time math. I was spending 15 minutes per OG generating, expanding, regenerating the bad edges, then giving up and Photoshop-extending manually anyway. Photoshop's Generative Fill is built on better edge logic for this specific job. After 12 days I cut Expand from the OG flow entirely and went back to generating at the right aspect ratio from the start with a wider Spaces prompt. The 18 OGs I shipped after that change took 4 minutes each. The 8 I shipped before averaged 19. Math wins.

What Got Killed: Style Transfer for Brand Consistency

Style Transfer takes the look of one image and applies it to another. For brand consistency this should be the holy grail. Generate Lexxa in pose A with style X, then Style Transfer to give pose B the same style X. Consistent character, different scene, no retraining.

It does not work for character likeness. Style transfers nicely. Face does not. After 22 attempts across Lexxa's blog avatar, video stills, and a podcast cover concept, the face drifted on every single one. Eye spacing changed, jawline softened, hair color shifted half a shade warmer. Each one looked like a cousin of Lexxa, not Lexxa.

What kept Lexxa consistent was a different workflow entirely: locked seed plus locked prompt plus manual face reference in Photoshop. Style Transfer is fine if your subject is a building, a product, or an abstract scene. For a recurring AI character you need to ship 50 times this year, it is not the tool. I still use it for environment passes (a desk scene needing the same color grading as a previous one) but it left the character workflow on day 9 and never came back.

The deeper issue is that Style Transfer optimizes for vibe, not for identity. Lighting, palette, texture, mood, all transfer beautifully. The 47 micro-decisions that make a face recognizable as one specific person do not. If your brand depends on a face people remember, build the locking workflow first and treat Style Transfer as a polish step at the end, not a consistency tool at the start.

The One Workflow Change That Saved 8 Hours a Week

Magnific's Spaces ZIP export is reverse-creation-order. Not paste-queue order, not alphabetical, not by tag. Reverse-creation. If you generated 30 images in a Space and export the ZIP, image 30 is first and image 1 is last. This is documented nowhere I could find.

For two weeks I was manually renaming files by opening each one, checking the prompt, and matching it to my batch list. That was 90 minutes per content drop, and I do roughly three content drops a week.

The fix was a transcript-fingerprint step. Before exporting I copy the Space's prompt history into a text file in creation order. After export I run a tiny script that reads the EXIF prompt from each ZIP file and matches it back to my fingerprint list. The renaming is now automatic. 90 minutes became 4. Three content drops a week. That is 8 hours and 18 minutes saved every week, which over 30 days is roughly 35 hours of pure execution time back.

This is the change I would do first if I were setting up the pipeline from scratch. Everything else in Magnific is great. The ZIP export ordering is the one place where a 60-second scripting fix replaces hours of manual file work, and it is not something the docs prepare you for.

Bottom Line

After 30 days Magnific is the spine of my image pipeline for blog OG images, Shopify product shots, and character environments. Spaces, Relight, Upscale, and prompt-based generation all earned permanent spots. Combined cost (Premium plan at 39€/month) versus the four tools they replaced is a clean 60 percent reduction in monthly software spend with more output, not less.

What Magnific is not: a one-click brand consistency tool, a generative-fill replacement for Photoshop's edge work, or a substitute for a real character locking workflow. Style Transfer is benched for characters. Generative Expand is benched for OG images. Both have their uses elsewhere and I still keep them in rotation for environment and product passes.

The honest 30-day verdict is that the pipeline now ships 3.5x more imagery at 60 percent of the previous cost, with 35 hours a month freed up because of one scripting fix and one workflow consolidation. If you want the longer comparison across image tools, I covered five of them head-to-head in this Lab piece. Tools that ship work survive. Tools that promise and then drift get killed off. Magnific stayed.

View Transitions API: 5 Patterns I Use Across RAXXO Sites in 2026

RAXXO Studios — Thu, 21 May 2026 12:45:05 +0000

Same-document transitions wrap state changes like filter chips and tab switches in a single startViewTransition call.
Shared-element morphs use view-transition-name to animate a product card into a detail page on Shopify themes.
Cross-document transitions on MPAs ship with the @view-transition rule, supported in Chrome 126+, Safari 17.4, and Firefox 131.
Theme-toggle flash gets replaced by a clip-path circle wipe expanding from the click coordinates of the toggle button.
Some interactions should skip view transitions entirely, and view-transition-class is the per-element scoping primitive that helps.

Last week I was watching a filter chip on the RAXXO shop snap from "All" to "Tools" and the entire product grid blinked. Same DOM, same data, same scroll position. It just looked cheap. Ten minutes later I wrapped the state update in document.startViewTransition and the grid cross-faded in 200ms. Nothing else changed. The shop felt twice as expensive.

That is the whole pitch for the View Transitions API. You write the state change you were already going to write, and the browser handles the in-between frames. As of May 2026, caniuse reports around 92% global support. Chrome, Edge, and Safari 17.4 all ship same-document transitions. Firefox 131 added them. Cross-document transitions need Chrome 126 or newer, which is fine because they degrade silently on older browsers.

Five patterns earned a spot on every RAXXO site this year. Here is how I use them, with the code I actually ship.

Pattern 1: Same-document transitions for state changes

This is the gateway drug. Any time you swap visible DOM in response to a click (filter chips, tab switches, sort dropdowns, "show more" toggles), you wrap the mutation in startViewTransition. The browser captures a snapshot before and after, then cross-fades between them.

The catch most people miss: the callback runs synchronously inside the transition. If you await a network request inside, the snapshot freezes the loading state. Fetch first, then start the transition with the data already in hand.


async function setFilter(tag) {
  const products = await fetchProducts(tag);
  if (!document.startViewTransition) {
    renderGrid(products);
    return;
  }
  document.startViewTransition(() => renderGrid(products));
}

That is 8 lines. The progressive enhancement check on line 3 is non-optional because the API is still missing on roughly 8% of sessions. Per-transition cost on a mid-range Android device sits under 16ms in my profiling, which is one frame at 60Hz. No JS animation library can match that because the compositor is doing the work directly.

A small note on accessibility. The browser honors prefers-reduced-motion automatically for the default cross-fade, but if you write custom ::view-transition-* animations you need to gate them yourself with a media query. I forgot this on the first build and a user flagged the wipe on Pattern 4 as nauseating. Three lines of CSS fixed it.

Pattern 2: Shared-element morphs between product cards and detail pages

This is where you earn the premium feel. When a customer clicks a product card, the card image stretches into the hero image of the product page. No fade, no cut. The same pixels appear to fly across the viewport.

You tag the source element and the destination element with the same view-transition-name. Each name must be unique per page (two elements with the same name in the same snapshot will throw). I generate the name from the product ID so the source card and the destination hero stay paired.


.product-card[data-id="abc123"] .card-image {
  view-transition-name: product-abc123;
}
.product-detail .hero-image {
  view-transition-name: product-abc123;
}

On Next.js this pairs with router.push wrapped in a transition. On Shopify themes (I run the RAXXO shop on Shopify, signed up via shopify.pxf.io/5k5rj9), you use the cross-document version covered in Pattern 3. Either way, the morph runs around 250ms by default, which is the sweet spot. Faster feels glitchy, slower feels sluggish.

One real gotcha. If your card image is object-fit: cover and the hero is object-fit: contain, the browser interpolates the box shape, not the crop. You get a brief letterbox flash. Match the object-fit on both ends or accept the artifact.

The other thing worth saying out loud: a morph like this costs nothing extra to ship. The image is already in cache from the card. The destination DOM was going to render anyway. You are paying for one snapshot and one compositor animation. Compare that to a JS-based FLIP animation (First Last Invert Play) which has to read layout, write transforms, and clean up listeners. I removed about 40 lines of FLIP code per page when I moved to view transitions.

Pattern 3: Cross-document transitions on MPAs and Shopify themes

Same-document transitions assume you control the DOM swap. On a classic multi-page site, the browser unloads the old document and parses a new one. Until 2024, that meant no view transitions across navigations. Then Chrome 126 shipped the @view-transition rule, and Safari 17.4 followed. Firefox 131 caught up in late 2025.

The setup is two CSS lines on both the source page and the destination page. No JavaScript at all.


@view-transition {
  navigation: auto;
}

That is it. The browser opts the navigation into a transition. Add view-transition-name on the elements you want to morph and you have the same Pattern 2 effect, except it now works across full page loads on a Shopify theme, an Astro static site, or a Rails MPA. The two pages must be same-origin and both opted in.

I ship this on every RAXXO Shopify theme now. Collection page to product page, blog index to blog post, cart drawer to checkout. The transitions degrade to instant navigation on older browsers, so there is no risk to the 8% who do not have support. If you already moved your tokens to a clean system (I wrote about that in tailwind-v4-tokens-that-actually-scale), the transitions inherit your design language for free.

One sharp edge. The browser only runs the transition if the user navigates via a real link click or history.pushState. A meta refresh or a window.location.replace skips the API entirely. If your theme uses any of those for redirects, you will not see the morph. Swap to a real anchor or accept the cut.

Pattern 4: Theme-toggle flash elimination

Dark mode toggles have a tell. The whole screen flashes. Even with a prefers-color-scheme listener and a color-scheme meta tag, the moment of repaint catches the eye. View transitions plus a clip-path wipe fix this in a way that feels almost theatrical.

The trick: when the user clicks the toggle, you grab the click coordinates. Then you animate a circular clip-path from radius 0 at those coordinates outward to the diagonal of the viewport. The new theme appears to ripple out from the button itself.


toggle.addEventListener("click", async (e) => {
  const x = e.clientX, y = e.clientY;
  const r = Math.hypot(
    Math.max(x, innerWidth - x),
    Math.max(y, innerHeight - y)
  );
  document.documentElement.style.setProperty("--cx", x + "px");
  document.documentElement.style.setProperty("--cy", y + "px");
  document.documentElement.style.setProperty("--cr", r + "px");
  await document.startViewTransition(() => toggleTheme()).ready;
});


::view-transition-new(root) {
  clip-path: circle(var(--cr) at var(--cx) var(--cy));
  animation: rx-wipe 420ms ease-out forwards;
}
@keyframes rx-wipe {
  from { clip-path: circle(0 at var(--cx) var(--cy)); }
}

12 lines of CSS and 9 lines of JS. The animation runs on the compositor thread. I have measured it on a 2019 MacBook Air and it holds 60fps. If you want the technique without view transitions you would need a full-screen overlay element and a lot of coordination. The reason this matters is the same reason I obsess over the small things in dark UIs (8-css-properties-that-make-dark-uis-feel-premium). The toggle is the most-clicked control on a portfolio. Make it feel like the rest of the design.

Pattern 5: Knowing when NOT to use view transitions

Three places I do not reach for the API.

Continuous streams. A live log, a chat message list, a stock ticker. View transitions add a snapshot cost per change. At 10 updates per second the snapshot work piles up and the main thread chokes. Use plain CSS transitions on the new items instead.

Virtualized lists. If you render only the visible rows and recycle DOM nodes on scroll, view transitions will treat node recycling as element removal plus insertion. Items appear to teleport. Tag virtualized rows with view-transition-name: none to opt out.

Drag interactions. The user is already controlling the position. A second animation layer fights them.

For everything else, view-transition-class gives you per-element scoping without naming every node uniquely. It shipped alongside the cross-document syntax and now has 92% support per caniuse.


.product-card { view-transition-class: card; }
::view-transition-group(.card) {
  animation-duration: 180ms;
}

That tunes every card transition to 180ms without forcing me to write a view-transition-name per product. The naming requirement (one name per snapshot) is what makes lists painful. Classes solve that.

Bottom Line

View Transitions are the rare browser feature that pays back the time you spend learning them within a single afternoon. Same-document transitions for state changes are a one-line win on every interactive surface. Cross-document transitions are the cheapest way to make a multi-page site feel like a single-page app. The theme-toggle wipe is a 21-line flourish that no client has failed to notice.

The traps are real but few. Network calls belong outside the transition callback. Unique names per snapshot, or use classes. Some interactions (streams, virtualized lists, drag) should opt out via view-transition-name: none. Older browsers fall back to instant change with no broken layouts, so the feature detection in Pattern 1 is the only defensive code you actually need.

I started 2026 with view transitions on three sites. They are now on every shop, every landing page, and every theme I ship. The grid no longer blinks when I switch filters. That alone was worth the afternoon.