Forem: Thea

Modern Web Guidance: Teaching AI Agents to Stop Coding Like It's 2019

Thea — Thu, 21 May 2026 10:05:14 +0000

This is a submission for the Google I/O Writing Challenge

There’s a slightly embarrassing problem that almost everyone using AI coding agents has run into: your agent still codes like it’s 2019.

Ask it to build a modal, and it reaches for a <div> with JavaScript click handlers and messy z-index hacks. Ask it to build a tooltip, and it creates a whole positioning system from scratch. Ask it to add passkey login, and it starts rebuilding things the browser already handles on its own.

This isn't really the agent's fault. It was trained on the entire history of the web: millions of StackOverflow answers, GitHub repos, and old tutorials from a time when <dialog> didn't exist, the Popover API wasn't even a thing, and container queries sounded like science fiction. AI models don't automatically know what's current. They know what's common.

That gap between what's "common" and what's "current" is exactly what Modern Web Guidance, announced at Google I/O 2026, is trying to fix.

What Is Modern Web Guidance?

Modern Web Guidance is basically a set of skills you add to your AI coding agent. Think of it as a rulebook that helps steer the agent away from outdated patterns and toward features browsers can already handle today.

It's not a linter or another docs site. It works inside your AI agent and helps guide the code it generates.

It launched in early preview on May 19 with over 100 use cases focused on accessibility, performance, and security. It already works with tools like Antigravity, Claude Code, GitHub Copilot CLI, Gemini CLI, and more, with WebStorm support announced for the near future. Setup is simple:

npx modern-web-guidance@latest install

One command, and your agent starts using more modern web patterns by default.

The Problem It's Actually Solving

Before getting into how it works, it's worth talking about why this even matters.

The web platform has changed a lot over the last few years. We got:

The <dialog> element (and the ability to animate it with native CSS)
The Popover API: simple, accessible overlays without extra JavaScript
CSS Anchor Positioning: UI that stays attached to elements without JS math
Container Queries: components that react to their own size, not the whole page
View Transitions API: smooth page and UI transitions in just a few lines
Passkeys / WebAuthn: secure login that the browser handles for you

These aren’t obscure experimental features. They’re widely available, well supported, and better than the patterns they replace. But AI agents still default to the old ones because that’s what they’ve seen the most.

The result? Codebases built with AI assistance often carry five-year-old technical debt, shipped at today’s speed.

Modern Web Guidance tries to fix this. It tells the agent: when the user asks for a modal, use <dialog>. When they ask for a tooltip, use the Popover API and CSS Anchor Positioning. When they ask for a login form, think about passkeys.

Trying It Out

I installed Modern Web Guidance via the CLI and tried a few prompts to see how much it actually changes the output.

Before (without guidance): asking an agent to "build a modal with smooth open/close animations" usually gives you something like this: a <div class="modal-overlay">, display: none toggled with JavaScript, opacity transitions on a z-index: 9999 container, and a document.addEventListener('keydown') for Escape handling.

It works. It’s also the kind of code a senior web developer would flag in a code review and replace.

After (with guidance): the same prompt produces a <dialog> element, animated with @starting-style and allow-discrete. Accessibility? Handled by the browser.

The output is not just cleaner, it's less code doing more things correctly.

I ran a similar test with tooltip/popover UI, and the guidance pushed the agent toward the Popover API with CSS Anchor Positioning. That removes a whole class of JavaScript that used to be needed just to keep tooltips attached to their triggers while scrolling.

The Baseline Integration Is the Clever Part

What makes Modern Web Guidance more interesting than just a list of best practices is its integration with Baseline.

Baseline is a web platform initiative that defines clear tiers of browser support: Newly Available (supported in all major browsers in the last ~30 months) and Widely Available. It gives developers a simple way to know if a feature is safe to use.

Modern Web Guidance ties into this directly. When it suggests a feature, it’s tagged with a Baseline level. If your app needs to support older browsers, it includes the right fallbacks automatically. If you’re building for modern browsers only, it just uses the latest features without hesitation.

This means the guidance isn’t static. As the web platform changes and features move from Newly Available to Widely Available, the skills get updated. You’re not managing rules, you’re just subscribing to them.

An Honest Critique

Modern Web Guidance is genuinely good, but it's worth being clear-eyed about what it is and what it isn't.

It’s still early. It ships with over 100 use cases. The web platform has thousands of patterns and APIs, so this will feel limited pretty quickly if you go into less common areas like advanced WebGL, complex Service Worker setups, or niche CSS layouts. The team is accepting GitHub contributions, which makes sense, but it also means the real value of this tool will depend on community input over the next few months, not just what is shipped at I/O.

It assumes your agent actually follows it. Modern Web Guidance works by adding context to your agent’s session, such as skills, CLAUDE.md files, or similar setups. But how well an agent follows that context vs. ignoring it and falling back to what it learned before can vary a lot. It’s not a strict rule; it’s more like a strong suggestion.

The web standards community is becoming the arbiter of what “modern” means, and that’s more complicated than it sounds. To be fair, this isn’t just a Google project. The repo lists the Google Chrome team, Microsoft Edge team, and the wider web community as co-maintainers. That matters, as it’s closer to a shared platform effort than a single company product.

But that also makes things more interesting, not less. When a cross-browser group defines what “modern web best practices” look like and bakes that into guidance used inside AI tools, it quietly shapes how millions of developers write code.

The guidance is well-intentioned and aligned with standards. But it’s still a curated view of the web, created by a specific set of organizations. It shouldn’t be treated as neutral; it should be understood and questioned like any other opinionated layer.

Should You Install It?

Yes, no hesitation, if you're building anything that runs in the browser with an AI coding agent.

The bigger picture is more interesting, though: Modern Web Guidance is an early sign of what happens when the people who build the web platform also shape how AI writes web code. That feedback loop, from spec authors to agent guidance to shipped code, could help the web actually catch up to what it already supports.

For too long, great web platform features have gone unused because the ecosystem, including AI, keeps reaching for older solutions out of habit. If Modern Web Guidance works as intended, that gap will start closing faster.

And that’s a meaningful thing to ship.

Getting Started

You can install it at developer.chrome.com/docs/modern-web-guidance

# Recommended (auto-updates)
npx modern-web-guidance@latest install

# Claude Code
/plugin marketplace add GoogleChrome/modern-web-guidance
/plugin install modern-web-guidance@googlechrome
/reload-plugins

# Gemini CLI
gemini extensions install https://github.com/GoogleChrome/modern-web-guidance --auto-update

# Antigravity CLI
agy plugin install https://github.com/GoogleChrome/modern-web-guidance

# GitHub CLI
gh skill install GoogleChrome/modern-web-guidance

The source is open on GitHub at github.com/GoogleChrome/modern-web-guidance-src, contributions and feedback are welcome while it's in early preview.

Announced at Google I/O 2026 on May 19, 2026, and currently in early preview.

Idempotency Keys: What Most Tutorials Don't Tell You

Thea — Wed, 29 Apr 2026 11:19:26 +0000

Every payment flow has a silent enemy: the network. Requests time out, connections drop, users panic, and click twice. What happens to your system when the same charge arrives more than once?
I used to think idempotency keys were one of those "nice-to-have backend things."
You know the kind you tell yourself you'll fix later. That thinking is dangerous.
When it comes to payments, idempotency isn't a feature; it's what prevents duplicate charges and inconsistent state.

The Problem: "The Double Tap"

Imagine this:

A user clicks "Pay"
The network is slow, or their Wi-Fi drops
They click "Pay" again
Your API receives two identical requests

If you're not handling this correctly:

The user gets charged twice
Your database ends up in a weird state
You lose user trust instantly

This doesn't require a bug. It's normal behavior in distributed systems.

What Is Idempotency?

In simple terms:

You can send the same request multiple times, but it will be processed only once.

Every retry with the same key should return the same result as the first successful request.

Important edge case: idempotency ≠ caching

It's tempting to think:

"If something fails, just return the same failure."

But it's not that simple.

If the request never reached your server logic, a retry should proceed normally
If the request may have started processing, you must rely on stored state, not assumptions
If an external system (like a payment provider) already processed the charge, a retry must not trigger it again

Idempotency protects against duplicate processing, not against retrying genuinely unprocessed requests.

The Key: `Idempotency-Key`

To make this work, every payment intent needs a unique identifier.
This key must be generated once per intent (not per click) and reused across retries.

// ❌ WRONG: New key on every click
// const handlePay = () => {
//   const key = crypto.randomUUID();
// }

// ✅ RIGHT: One key per payment intent
const idempotencyKey = crypto.randomUUID(); // generate when checkout loads

fetch('/api/payments/charge', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Idempotency-Key': idempotencyKey
  },
  body: JSON.stringify(payload)
});

Where does the key live on the client?

"Generated once" means you need to persist it across retries.
Good options:

React state or a ref (single-page flow)
sessionStorage (if reloads are possible)
A server-generated key passed into the checkout session

The key should be tied to the intent, not the button click.

🔒 Security note: Idempotency keys can reveal payment patterns (e.g., same key on retry = something went wrong). Always send them over HTTPS, and avoid logging full keys in plaintext in production logs; hash or truncate if needed.

The Server Side: Where the Real Work Happens

Sending the header does nothing unless your backend actually uses it.
Here's the core logic:

async function handleChargeRequest(req, res) {
  const key = req.headers['idempotency-key'];

  if (!key) {
    return res.status(400).json({ error: 'Idempotency-Key header is required' });
  }
  const existing = await keyStore.get(key);

  // 🚨 Same key must always mean the same intent
  if (existing) {
    const currentSignature = extractBusinessSignature(req.body);
    const storedSignature = existing.businessSignature;

    if (currentSignature !== storedSignature) {
      return res.status(409).json({
        error: 'Idempotency key reused with different payment details'
      });
    }
    return res.status(existing.statusCode).json(existing.body);
  }

  // Process the payment
  const result = await paymentProvider.charge(req.body);
  const statusCode = result.success ? 200 : 400;

  // Store every deterministic response (success or known failure)
  await keyStore.set(key, {
    statusCode,
    body: result,
    businessSignature: extractBusinessSignature(req.body)
  });
  return res.status(statusCode).json(result);
}

// Only include immutable business fields - never timestamps, request IDs, or metadata
function extractBusinessSignature(payload) {
  return JSON.stringify({
    amount: payload.amount,
    currency: payload.currency,
    customerId: payload.customerId,
  });
}

If the payment provider returns a failure (e.g., 402 or 500), you should store that response just like a success. Otherwise, a retry might reprocess the same key and produce a different result, breaking idempotency.

The only exception is when the result is unknown (e.g., network timeout or provider unavailable). In those cases, the client should retry with the same key, and your system should check the provider state before deciding what to return.

The Real Danger: Concurrency

Here's where most implementations break.
Two identical requests can arrive at the same time:

both check "key not found"
both proceed
both charge the user

Game over.

The fix

You need a database-level unique constraint on the idempotency key.
This is what actually makes sure only one request wins.

CREATE TABLE idempotency_keys (
  key TEXT PRIMARY KEY,
  response JSONB,
  status_code INT,
  business_signature TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);

In production, the key should be inserted with a unique constraint before processing the payment to avoid race conditions.

If two requests try to insert the same key:

one succeeds
the other fails → and must fetch the stored result

Without this, your idempotency is not reliable.

Don't use SQL?

The unique constraint is ideal, but here are alternatives:

Redis: SET key value NX EX ttl (atomic create-if-not-exists)
MongoDB: unique index on idempotencyKey
DynamoDB: conditional write with attribute_not_exists(idempotencyKey)

Whatever you use, the operation must be atomic. A check-then-insert pattern will always have a race condition.

Fake Idempotency (Very Common)

A lot of systems look correct, but aren't.
Examples:

checking the key but not storing the response
storing the key but not handling concurrency
using in-memory storage in a distributed system

This creates a false sense of safety, which is worse than having none.

Key Expiration: The Gotcha Nobody Mentions

Idempotency keys shouldn't live forever.
A typical approach:

keep them for ~24 hours
clean up old entries

Why?

prevents unlimited storage growth
gives you a safe retry window

After expiration, the same key can be treated as new. This is fine only if the original session has ended (for example, the user abandoned checkout).

⚠️ Be careful: if a key expires while a payment is still processing (rare, but possible), a retry could create a duplicate. Set expiration long enough to cover your processing time and retry window. 24 hours is usually safe for most payment flows.

The Full Flow

CHECKOUT LOADS
      ↓
Generate idempotency key (once)
      ↓
User clicks "Pay"
      ↓
POST /charge (Idempotency-Key)
      ↓
SERVER: Key exists? ── YES → return stored response ✓
      │
      NO
      ↓
Try to insert key (unique constraint)
      │
      ├─ success → process payment → store result
      │
      └─ fail → fetch existing result
      ↓
Return response

A Quick Note on HTTP Methods

GET requests are intended to be idempotent; calling them multiple times should not change server state.
Idempotency keys are mainly for POST and PATCH - basically, anything that changes state.

Idempotency Beyond Payments

This isn't just about payments. The same idea applies to:

email sending (avoid duplicates)
webhook handling (providers retry delivery)
message queues (at-least-once delivery)
database writes (deduplication)

Anywhere you need exactly-once behavior on unreliable networks, idempotency is your tool.

How to Test It (Because Trust, But Verify)

💡 Pro tip: Don't just hope it works, prove it.
In your tests, send the same idempotency key twice:

test('idempotent charge: second request returns cached result', async () => {
  const key = 'test_order_123';
  const payload = { amount: 2000, currency: 'USD', customerId: 'cus_abc' };

  // First request — processes payment
  const res1 = await request(app).post('/charge')
    .set('Idempotency-Key', key)
    .send(payload);

  // Second request — should return cached result, NOT call payment provider again
  const res2 = await request(app).post('/charge')
    .set('Idempotency-Key', key)
    .send(payload);
  expect(res2.body).toEqual(res1.body);
  expect(paymentProviderMock.charge).toHaveBeenCalledTimes(1); // 🔑 critical check
});

If your mock gets called twice, your idempotency is leaking. Fix it before prod.

Quick Checklist

Before shipping a payment flow:

[ ] Key generated once per intent
[ ] Key persisted across retries
[ ] Backend checks key before processing
[ ] Response is stored and reused
[ ] Payload consistency is validated
[ ] Database enforces a unique constraint
[ ] Key store is shared across instances
[ ] Expiration policy is defined

If one of these is missing, it's not done.

TL;DR

Client sends the same key. The server enforces a unique constraint. Store every result (success or failure). Return stored result on retry.
Miss any of these? You don't have idempotency. You have hope.
The double tap is coming. Be ready for it.

Future Museum of Extinct Things - A Glimpse from 2100

Thea — Sun, 19 Apr 2026 10:18:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

By 2100, most of what you’re about to see is already gone.
This is my Earth Day project - a museum built from that absence, an archive of what humanity lost during the Anthropocene.

The premise is simple: curators from the future built this collection, looking back at us.
Every exhibit documents a real environmental loss. Not invented species, but things already gone, or measurably disappearing right now. The Great Barrier Reef. The monarch migration. The vaquita porpoise.

Visitors can do two things:
Nominate an exhibit - type a word, a phrase, anything.
"Fireflies." "The sound of a forest."
The AI archivist grounds that in real, documented science, turning it into a permanent museum card.
No fiction. Every exhibit is real data, real species, real loss.

Ask the Curator - a floating button opens a conversation with the museum's archivist.
It is 2100. Everything is already gone.
The curator speaks entirely in the past tense and answers from that weight.
You’re not chatting with an assistant.
You’re talking to someone who has already watched it disappear.

Demo

anthropocene-archive.vercel.app
Try nominating something you're afraid we'll lose. Then ask the Curator what happened to it.

Code

highflyer910 / future-museum

Future Museum of Extinct Things

It is the year 2100. You are standing in a digital archive built by those who remembered. This is what they chose to preserve.

→ Visit the Museum

Built for the DEV Earth Day Challenge 2026 - a contemplative digital museum set in the year 2100, where the exhibits are the species, places, sounds, and sensations that humanity lost during the Anthropocene. Visitors can nominate what they are afraid we will lose, and an AI curator - powered by Google Gemini - writes a scientifically-grounded permanent exhibit for each one.

What It Is

The premise: a museum from the future, looking back at us. Every exhibit documents a real environmental loss, not invented, not speculative fiction, but things already gone or measurably disappearing. The Great Barrier Reef. The monarch migration. The sound of a full dawn chorus. Truly dark skies.

The Gemini integration isn't decorative…

View on GitHub

How I Built It

Stack: vanilla HTML, CSS, and JavaScript — no frameworks, no build step. GSAP for animation. Two Gemini-powered Vercel serverless functions.
I deliberately kept the stack minimal. This project isn’t about complexity - it’s about control over tone, pacing, and interaction.

The nomination feature sends user input to /api/gemini.js, where Gemini is prompted to translate a vague or emotional phrase into a real, documented environmental phenomenon.
The challenge wasn’t generating text - it was constraining it.

Without strict instructions, the model drifted into fiction. With too many constraints, it became sterile. The prompt had to balance both: enforce real species, real data, real locations - while still sounding like a human curator, not a report.

The Curator chat lives in /api/curator.js and is treated as a separate system entirely.
It’s not just a chatbot, it’s a character with rules:

year 2100
speaks only in the past tense
offers no solutions, only memory

It’s also context-aware. If a user opens an exhibit and asks a question, the Curator responds from within that specific loss rather than generically.
Both functions run server-side, keeping the API key completely off the client.

Design-wise, everything supports the same idea: quiet loss.
Soil, bark, amber, parchment - materials that age and decay.

A subtle grain overlay, concentric rings that echo tree rings, ripples, or sonar, something searching, or remembering.
The goal wasn’t just to show information.
It was to make it feel like something already gone.

Prize Categories

Best use of Google Gemini: two integrations, both central to the concept:

generating scientifically grounded exhibits from visitor input
maintaining a consistent character voice from the year 2100

git blame --emotions: No Solutions. Just Vibes.

Thea — Sat, 04 Apr 2026 12:04:22 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built a tool that does absolutely nothing useful.

git blame --emotions is a Shakespearean error therapy app. You paste your error message. It gives you a sonnet. No solutions. No Stack Overflow links. No rubber duck. Just iambic pentameter and the gentle acknowledgment that your undefined is not a function is grieving.

The app lives at the intersection of two deeply important things: the emotional intelligence of Elizabethan poetry, and the complete uselessness of a tool that refuses to help you debug anything. It will not fix your code.

It also looks like a 1999 Geocities fan site - Comic Sans, pastel chaos, and a visitor counter stuck at 000418.

Demo

🔗 Live site: git-blame--emotions

Here's what happens when you use it:
Paste an error. Click the button.
You get a Shakespearean sonnet about your suffering.
Your code remains broken.

Bonus: If you paste anything containing 418 or teapot, you get a special Easter egg. I won't spoil it.

Code

highflyer910 / git-blame--emotions

git blame --emotions 💔

No solutions. Just vibes.

A Shakespearean error therapy app powered by Google Gemini AI and a complete disregard for productivity.

You paste your error message. It writes you a sonnet. The error remains. You feel seen.

Live site: git-blame--emotions

What It Does

You paste an error message, or stack trace
Google Gemini AI reads it and writes a Shakespearean sonnet - 14 lines, ABAB CDCD EFEF GG rhyme scheme, iambic pentameter
Confetti fires
You feel emotionally validated
Your code is still broken

This tool will not fix your bugs. It will not suggest a solution. It will not link you to Stack Overflow. It will, however, tell you that your NullPointerException is "a void where love should be" - and sometimes that's enough.

⚠️ Bonus: Paste anything containing 418 or teapot for a special surprise. RFC 2324 compliant.

Tech Stack

Vanilla HTML, CSS, JavaScript - zero…

View on GitHub

Tech stack is intentionally minimal:

Pure vanilla HTML, CSS, JavaScript - zero frameworks, zero build tools
One serverless function api/poem.js on Vercel
Google Gemini API for the sonnet generation
canvas-confetti for emotional release
Google Fonts: UnifrakturMaguntia + Patrick Hand

How I Built It

Honestly, this started as a joke. It stayed a joke. I read "build something completely useless," and thought: what if instead of fixing errors, we just... felt them.

The frontend is a single index.html + style.css + script.js. The Geocities aesthetic isn't laziness; it's a commitment.

The API lives in api/poem.js, a Vercel serverless function that calls Gemini and keeps the API key server-side.

Most of the work went into the prompt. I force Gemini to:

write a proper Shakespearean sonnet (ABAB CDCD EFEF GG)
use iambic pentameter
treat the error as a character with feelings
and absolutely refuse to help in any technical way

The 418 Easter egg was non-negotiable. HTTP 418 "I'm a Teapot" gets special treatment: confetti, a wobbling teapot overlay, and a dramatic sonnet that treats the RFC like high tragedy.

On mobile, the site politely asks you to rotate your CRT monitor. There is also a vertical label that says EMPTY SPACE FOR YOUR TEARS. These are features.

Prize Category

☕ Best Ode to Larry Masinter

The visitor counter stops at 000418. The site claims RFC 2324 compliance. The teapot Easter egg turns the most absurd HTTP status code into a Shakespearean tragedy. It felt only right.

🤖 Best Google AI Usage

Google Gemini powers every poem. It reads raw error messages and turns them into structured Shakespearean sonnets with dramatic tone and zero usefulness. The 418 path uses a separate prompt to elevate the RFC into full tragedy.

🌟 Community Favorite

We’ve all been there at 2am, staring at a stack trace and questioning everything. Sometimes you don’t need a fix. You need someone to say: "thy memory, shattered like my heart."
That’s this app.

No bugs were fixed during the making of this website.

DevStretch: The Antiburnout Protocol for Devs Who Forgot They Have Bodies

Thea — Sun, 01 Mar 2026 21:03:41 +0000

The Community

Let’s be honest: most of us treat our physical bodies like a deprecated legacy dependency. It’s still running, it’s technically functional, but it hasn't had an update in years, and we’ve been ignoring the STIFF_NECK_WARNING in the logs for six hours.

I built this for the community of developers, specifically the ones who:

Sit at a 45-degree angle until they merge with their chair.
Make a "crunchy" sound when they finally stand up at 3 AM.
Treat "Hydration" as just another cup of coffee. Burnout isn't just a mental state; it’s a physical bug report. DevStretch is the patch.

What I Built

DevStretch is a terminal-themed PWA designed to interrupt your "flow state" before it permanently wrecks your posture.

It’s an 11-step maintenance protocol. We’re not "stretching"; we’re refactoring our spines. I gave every movement a proper developer rebrand because let’s face it - you’re more likely to "Clear Cache" than "Rest your eyes."

#	Protocol Name	System Action
1	Review That Code	Neck Stretch
2	Roll Back	Shoulder Rolls
3	Prevent Carpal Tunnel PR	Wrist Stretches
4	Deploy to Standing Position	Sit to Stand
5	Clear Cache	Eye Break
6	Refactor Your Spine	Seated Back Twist
7	Offline Mode	Walk Away
8	Memory Garbage Collection	Box Breathing
9	Extend Your Reach	Overhead Arm Stretch
10	Lint Your Posture	Posture Check
11	git commit --water	Hydration Reminder

The UI is a dark mode terminal aesthetic - phosphor green on near-black, JetBrains Mono font, scanlines, a flickering timer with a blinking cursor, and a startup boot sequence that makes you feel like you’re initializing a mainframe.

Demo

devstretch.vercel.app
Open it on your phone and "Add to Home Screen." It’s a PWA, so it works offline when your Wi-Fi goes down.

Code

The project is entirely dependency-free. No React, no Vite, no node_modules folder larger than the project itself. Just clean, modular Vanilla JS.

GitHub repository

How I Built It

I chose a deliberately "boring" stack in the best way.

Web Speech API: Provides hands-free voice guidance. No need to look at the screen while you're "Refactoring your spine."
Screen Wake Lock API: This was crucial. It prevents the phone screen from dimming or locking mid-stretch, ensuring the timer doesn't throttle while you're away from the keyboard.
Web Notifications API: Background stand-up reminders that stay active even if you close the tab.
Service Worker:Full offline support. If your internet dies, your health protocol shouldn't.

The "Bug" Log: Notification Hell

Browser notifications were humbling. I learned the hard way that new Notification() called from the main thread is often silently blocked; the "Senior" move is rerouting everything through the Service Worker via registration.showNotification().

Even then, OS-level notification layers (Focus Assist on Windows, battery optimization on Android) can swallow notifications entirely. Permission shows as granted, the Service Worker fires without errors... and nothing appears. Still actively debugging. Sometimes shipping means shipping with a 'Known Issue' 🙃

What's next:

Deeper platform integration for background notifications
Custom exercise editor - add your own stretches
Configurable rest time
Dedicated wrist and eye exercise sets

git commit -m "took care of myself today"
// It's a feature, not a bug.

Smooth Page Transitions with Zero Libraries: The View Transitions API

Thea — Tue, 11 Nov 2025 13:04:58 +0000

I recently started using the View Transitions API in one of my projects, and honestly, it felt like unlocking a hidden superpower for the web. I had to share it.

Not long ago, this API was just a Chrome experiment. But as of 2025, it’s officially everywhere, supported in Chrome, Edge, Safari, and Firefox, covering over 85% of browsers. It’s now powering everything from e-commerce sites to dashboards and blogs, making transitions feel native and seamless.

Here’s what I’ve learned using it, and why you’ll probably want to add it to your toolkit too.

What Is the View Transitions API?

The View Transitions API animates between two page states, toggling a UI mode, opening a modal, or moving between pages. It works whether you're updating part of a page or navigating between entirely different pages.

The trick: give an element the same view-transition-name before and after the update. The browser retains the element’s identity and morphs it, automatically handling position, size, and content blending.

No libraries. No keyframes. Just native transitions that are easy to use.

The Core Pattern (Only 3 Steps!)

To apply a transition to an in-page element (like a card changing from a grid to a list view):

1. Name your element in CSS

.content.active {
  view-transition-name: main-content;
}

2. Keep your element in the DOM (toggle its state)

<div class="content card-view active">Card content</div>

3. Wrap your state change in startViewTransition()

document.startViewTransition(() => {
  // Toggle state - the element keeps the same view-transition-name
  content.classList.toggle('card-view');
  content.classList.toggle('grid-view');
});

That's it! The browser handles the animation.
💡 Tip: Avoid using element.innerHTML = '...' or re-rendering components that replace the DOM completely, which breaks the element’s identity and stops the smooth transition.
Instead, just toggle classes or, if you’re using a framework like React, make sure elements keep stable keys so the DOM node stays the same.

See It in Action

I built a small SPA demo to test how smooth the View Transitions API can be. It uses directional animations and custom effects, and honestly, it feels surprisingly close to a native app.

Pages slide left and right, hero sections move up and down, and the back button even reverses the animation automatically.

👉 View Live Demo on CodePen

Try it yourself:

Click between pages to see forward animations (slides right-to-left)
Use the back button to see reverse animations (slide left to right)
Watch the hero section move up and down on its own
Open DevTools and inspect the ::view-transition-* pseudo-elements to see how the browser does it!

Advanced Technique #1: Directional Back Navigation

Want your back button to slide the other way? Here’s how to make your SPA navigation feel more like a native app:

The JavaScript
We listen for the popstate event (which fires on back/forward navigation) and briefly add a class to the root element to trigger reverse animations.

function handlePopState(e) {
  const page = e.state?.page || 'home';

  if (document.startViewTransition) {
    // Add class to trigger reverse animations
    document.documentElement.classList.add('back-transition');

    document.startViewTransition(() => {
      renderPage(page, false);
    }).finished.then(() => {
      // Clean up after animation completes
      document.documentElement.classList.remove('back-transition');
    });
  } else {
    renderPage(page, false);
  }
}

window.addEventListener('popstate', handlePopState);

The CSS
We target the global transition, which is automatically assigned the name root.

/* Forward navigation (default) */
::view-transition-old(root) {
  animation: 0.3s ease-in both slide-to-left;
}

::view-transition-new(root) {
  animation: 0.3s ease-out both slide-from-right;
}

/* Reverse navigation (back button) */
.back-transition ::view-transition-old(root) {
  animation: 0.3s ease-in both slide-to-right; 
}

.back-transition ::view-transition-new(root) {
  animation: 0.3s ease-out both slide-from-left;
}

This creates that iOS/Android feeling where navigation direction matches user intent!

Advanced Technique #2: Custom Animations for Specific Elements

You can animate different parts of the page independently using named transitions.
For example, while your main content slides horizontally, a hero section can move vertically or fade, and the browser syncs it all perfectly for you.

Hero Section with Vertical Slide

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

::view-transition-old(hero) {
  animation: 0.3s ease-in both slide-down-out;
}

::view-transition-new(hero) {
  animation: 0.3s 0.1s ease-out both slide-up-in; 
}

@keyframes slide-down-out {
  to { opacity: 0; transform: translateY(40px); }
}

@keyframes slide-up-in {
  from { opacity: 0; transform: translateY(40px); }
}

The result? A smooth motion where each element moves on its own but still feels perfectly connected, just like a well-crafted native app.

When to Use It (and When Not To)

Great for:

Toggling states (like dark mode or list ↔ grid views)
Page navigation in SPAs
Opening modals or dialogs
Simple UI transitions that need a touch of polish Skip it for:
Complex, multi-step animations (GSAP or Framer Motion are better here)
Situations that need precise timing across many elements
Critical interactions where you need guaranteed fallback behavior Accessibility Tip: Always respect prefers-reduced-motion, as some users are sensitive to motion, and fast transitions can make them uncomfortable.

@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    /* Instantly complete the animation */
    animation-duration: 0.01ms; 
    animation: none !important;
  }
}

Minimal Fallback (Just in Case)
While browser support is excellent, a tiny fallback never hurts:

if (document.startViewTransition) {
  document.startViewTransition(updateDOM);
} else {
  updateDOM(); // instant update
}

You can also use CSS @supports to provide a subtle transition fallback for older browsers:

@supports not (view-transition-name: test) {
  .content { 
    transition: opacity 0.2s; 
  }
}

Final Thoughts

The View Transitions API is a surprisingly powerful tool that can turn clunky page changes into smooth, polished experiences, with minimal code.

Directional transitions and custom element animations let your web app feel closer to a native app, all with just vanilla CSS and JS.

So next time you update a view, just give it a view-transition-name.
It’s that simple, and the page instantly feels smoother.

Single-tenant vs Multi-tenant: What I Wish I Knew When I Started

Thea — Thu, 16 Oct 2025 10:45:52 +0000

I should be coding right now, but instead, I went down the single-tenant vs multi-tenant rabbit hole. Then I got lost in videos, articles, and posts that all said different things.

One person says multi-tenant is the only way to scale. Another says single-tenant is the only way to be secure. And someone always warns: “If you choose wrong, your SaaS will fail.”

It’s really not that serious. I just wanted a simple explanation without all the technical words and drama. So here’s the version I wish I had read earlier.

TL;DR

Multi-Tenant (Apartments): Cheaper, easier to update, and perfect when you’re starting.
Single-Tenant (Houses): Private, secure, and flexible, but expensive and hard to maintain.
Hybrid (Schema-per-Tenant): Each tenant has its own schema in the same database. It’s more complex but gives better separation.
Security: Multi-tenant apps must have strong data separation. One missing WHERE clause can leak data.

If you’re building your first SaaS, multi-tenant is usually the better choice.

The Analogy (Houses vs. Apartments)

Single-Tenant = Everyone Has Their Own House

Each customer has a private house, their own driveway, kitchen, and mailbox. In SaaS, that means a separate app and database for each one.

Advantages:

Very secure: If one house is broken into, others are safe.
Easy to customize: You can change things for one client without affecting others.
No noisy neighbors: No performance issues between users.

Disadvantages:

Expensive: More infrastructure means higher costs (servers, databases, monitoring)
Hard to update: You must update each app separately.
More maintenance: fixing one problem often means fixing it many times.

When to use it:

When you work with enterprise clients who specifically ask for it.
If you’re in a highly regulated industry (healthcare, finance, etc.) that needs strong compliance (HIPAA, SOC 2, and so on).
When your users want custom deployments or on-premise hosting.
If you actually have funding or a big budget to handle the extra infrastructure.

Multi-Tenant = One Big Apartment Building

Everyone lives in the same building, but each apartment has a lock. In SaaS, it means one app and one database, but data is separated by tenant IDs.

Advantages:

Much cheaper: Resources are shared.
Easier to update: One update affects all tenants.
Simple to add new tenants: New signups are just new rows in your database.

Disadvantages:

Security must be perfect: one small mistake can expose another tenant’s data.
The "noisy neighbor" problem:: A heavy user can slow down others.
Harder to customize: Individual tenant customizations are more complex
More complex queries: Every query needs tenant filtering logic

When to use it:

You're bootstrapping or indie hacking
You want to launch and iterate fast
Your users have similar needs (same features, pricing tiers)
You're using modern frameworks with built-in tenant isolation

Schema-per-Tenant = Separate Floors in the Same Building

One database server, but each tenant gets their own schema (namespace).

How it works:

Each tenant has tables like tenant_123.users, tenant_123.orders
Your app switches schemas based on who's logged in
Better separation than row-level filtering, cheaper than separate databases

Advantages:

Better isolation than pure multi-tenant
Easier to backup/restore individual tenants
Still cheaper than full single-tenant
Can migrate specific tenants to their own database later

Disadvantages:

More complex than simple multi-tenant
Some ORMs don't handle this well
Database connection pooling gets trickier
Migration scripts need to run on all schemas

Popular tools:

Django: django-tenants (formerly django-tenant-schemas)
Node.js: Knex.js with schema switching, or Prisma with multi-schema support
Ruby on Rails: Apartment gem

- Postgres: Built-in schema support

Security (The Scary Part)

Multi-tenant security means more than just adding a tenant_id column.

Three Levels of Protection:

Database: Use row-level security or tenant views.
Application: Always filter queries by tenant.
API: Make sure tokens connect users to the right tenant.

Common mistakes:

Forgetting WHERE tenant_id = ? → Instant data leak
Wrong JWT token → Can access another tenant's data
Admin panels that bypass tenant filters → Privacy nightmare
Sharing caches across tenants → Information disclosure

Tools That Help:

Supabase: Built-in RLS, auth hooks, and tenant isolation patterns
Prisma: Row-level security middleware and tenant filtering
PostgREST: API that enforces Postgres RLS automatically
Django Tenants: Mature library for schema-per-tenant in Django
PlanetScale: Database branching makes tenant testing easier

Security Best Practices:

Use Postgres RLS as your backup layer
Choose an ORM that enforces tenant filtering by default
Include tenant_id in all JWT tokens
Create separate admin roles with explicit permissions
Test with multiple tenants in every environment
Log all cross-tenant access attempts
Use database-level constraints where possible

Why I chose multi-tenant

I'm bootstrapping. Single-tenant would be too expensive
My users don't need custom setups.
I want to move fast. One update for all tenants
I can always switch later Big clients could get single-tenant setups.

What Should You Do?

Go multi-tenant if:

You're bootstrapping or self-funded.
You want to launch fast.
Your users have similar needs.
You don’t deal with heavy security rules.
Infrastructure costs matter

Go Schema-per-Tenant If:

You want better isolation than pure multi-tenant
You plan to offer data export/backup per tenant
You might need to migrate large clients later
Your users have moderately different needs
You're okay with more complex migrations

Go single-tenant if:

You work with enterprise clients.
You have funding for infrastructure.
You need strict data separation.
You offer custom setups.
Clients demand it (and pay for it)

Final Thoughts

I spent too much time reading about this when I should have been coding.

Big SaaS companies like Notion, Vercel, Shopify, and Zoom also started simple and are still multi-tenant. Slack started multi-tenant, now hybrid.

The real problem isn’t “choosing wrong”, it’s never launching at all.

Many companies eventually use both: multi-tenant for most users and single-tenant for large clients like Stripe or GitHub.

If you’re still deciding, start simple. Build, launch, and learn. You can always improve later.

I Thought My Backups Were Safe - Until I Tried Restoring One

Thea — Mon, 06 Oct 2025 13:27:40 +0000

Imagine this: you wake up one morning, open your app, and something's wrong. Your database is gone. Your files are corrupted. Or a simple bug deleted everything clean.

You breathe a little easier because you have backups, right? Except… when you try to restore them, they don't work.
They're empty. Or the format is broken. Or restoring takes forever.

That's the painful truth I learned recently:
A backup is worthless until you've restored it.

My Wake-Up Call

Last month, I was refactoring my side project's database schema.
Something went wrong during migration, and I corrupted my SQLite database.

No problem, I thought, I will just restore my weekly backup.
But when I tried, the backup file was also corrupted.
Later I found out I had been copying the database while the app was still running, catching it middle of writing.
So my “backup system” was creating broken files for weeks, and I didn’t know because I never tested restoring one.

I was lucky it was only dev data, but it scared me.
If that had been production?
If that had been production, I could have lost real users’ data, their work, and my project’s reputation.

What I Learned About Backups While Building Side Projects

Before this, I thought backups were just a checklist: make a copy, sleep peacefully.
But a backup is not magic protection.
It’s just a copy of important things:

🧠 Your codebase - GitHub or GitLab usually handle this
🗄️ Your database - Postgres, MySQL, Supabase, Firebase, SQLite…
🖼️ User files - images, uploads, documents
🔐 Configs & secrets - the .env file, API keys, deployment settings

The real problem:
You don't know if those backups are good until you test restoring them.
Otherwise, it’s like having an emergency plan locked in a drawer.

How Bigger Teams Handle It

I checked how bigger companies do backups.
GitLab, for example, runs restore tests every day and tracks success rates.
Basecamp even does “disaster tests,” pretending their main datacenter disappears.

Usually, their process looks like this:

Make backups automatically (nightly dumps, snapshots, etc)
Restore them into a test environment (not production)
Check if everything works: database starts, files open, users can log in
Get alerts when something fails
Simulate disasters to see how fast they can recover Then I realized: I don't need a datacenter, just a smaller version that fits my side project setup.

And actually, many platforms like Supabase, Neon, and Vercel Postgres now have point-in-time recovery (PITR) built in. Sometimes even free. So before you create your own backup scripts, check your dashboard first.

🧠 What to Back Up

Type	Backup Method	Test Method
Code	Push to GitHub/GitLab (with 2FA!)	Clone repo to a fresh folder: `git clone <repo> test-restore && cd test-restore && npm install && npm run dev`
Database	• SQLite: `sqlite3 mydb.db ".backup backup.db"` • Postgres: `pg_dump mydb > backup.sql` • Managed DBs: Use built-in exports or PITR	Restore to test DB: `sqlite3 test.db < backup.sql` then run a query to verify data. For Supabase/Neon, use their one-click export + local restore.
User Files	Store in Backblaze B2, S3, or Google Cloud Storage (all offer free tiers). Avoid consumer Dropbox for production data.	Download 3–5 random files monthly and verify they open. Bonus: enable object lock or versioning to prevent accidental deletion.
Configs & Secrets	Store in a password manager (1Password, Bitwarden) or encrypted offline vault (VeraCrypt). Never in Git—even private repos!	Run project locally using only saved configs. Use GitHub Secrets or `.env.vault` for CI/CD, not raw `.env` files.

⚠️ Important SQLite Tip:
** Copying a live .db file can damage it. Use .backup or VACUUM INTO:

 sqlite3 mydb.db "VACUUM INTO backup.db"

This creates a clean, safe copy even while your app is running.
💡 Pro tip: Automate your test restore with a small script:
For example:

#!/bin/bash
   set -e  # Exit on any error
   rm -f test.db
   sqlite3 test.db ".read latest_backup.sql"
   sqlite3 test.db "SELECT count(*) FROM users;"
   echo "✅ Restore test passed!"

You can even run it weekly on GitHub Actions, if it fails, you’ll get an alert.

⏰ When to Test

Monthly (15–30 minutes)

Restore one random backup locally
Download a few random user files
Write down anything strange or failed

Quarterly (1–2 hours)

Full local restore: DB + files + app
Time it - how long does recovery take?
Update your notes

Yearly (half day)

Pretend your laptop died
Can you restore everything from your backups and docs?
It’s a great test for your memory and process.

⚠️ Privacy reminder:
If your app stores user data, make sure backups are encrypted at rest. Most cloud providers do this by default. And never keep plain emails or passwords in backups.

Why It Matters

It’s easy to think backups are only for big companies.
But if you're building side projects or working solo, losing data can kill your project one day. Users won’t wait while you say, “Oops, I thought I had backups.”
Now, backups aren’t about peace of mind when I make them;
They’re about peace of mind when I restore them.
Because backups aren’t about paranoia, they’re about love for your future self. ❤️

Passkeys Without the Pain: A Frontend Dev’s Guide

Thea — Thu, 25 Sep 2025 11:08:56 +0000

I was building my SaaS side project when I realized I needed to add passkeys. Everyone talks about better security and user experience, but I had no idea where to start. Would I need to rebuild my entire auth system? How complicated is this stuff?

Turns out, it’s way simpler than I thought. You don’t need to break your existing login flow to add passkeys. Let me walk you through how I added them in a single weekend, kept everything working smoothly, and got ready for when users start signing up.

What Are Passkeys, Anyway?

Passkeys are a secure, passwordless login method using biometrics (like your fingerprint or face scan) or device-based authentication. They’re basically the user-friendly names for the FIDO2 and WebAuthn standards.

Here’s the gist: when you create a passkey, your device makes a unique cryptographic key pair. The private key stays locked on your device (protected by your fingerprint or PIN), while the public key goes to the server. During login, your device signs a challenge with the private key, and the server checks it with the public key.

No passwords. No phishing. No credential stuffing (that’s when attackers reuse leaked passwords across multiple sites, hoping one works).

Think of them as a futuristic “Login with Google” button, minus the third-party dependency and with top-notch security. Plus, they can sync across devices through providers like Apple iCloud Keychain, Google Password Manager, and 1Password. Cross-device sync is a game-changer.
Important note: the PIN or biometric you use doesn’t sync. That’s just the local way your device unlocks its stored keys. The actual passkey itself is what gets synced through your Apple/Google/1Password account.

The Simplest Way to Add Passkeys (That Actually Works)

Step 1: Add One Button

I added a single passkey button to my login form—no database chaos, no 3 a.m. panic sessions.

{/* Only show if browser supports passkeys */}
{supportsPasskeys() && (
  <button
    type="button"
    onClick={handlePasskeyLogin}
    className="w-full border-2 border-dashed border-gray-300 p-3 rounded-lg hover:border-gray-500"
  >
    🔐 Try Passkey Login
  </button>
)}

Step 2: Let Users Opt In (But Encourage It)

I don’t force passkeys on signup, but I nudge users after a few password logins: "Use a passkey. Skip the password."

Step 3: Use a Service (You've Got Features to Ship)

I could’ve spent months wrestling with WebAuthn docs, but I’m pre-revenue and need to ship. After some research, I picked Clerk; their Next.js integration is smooth, and the passkey setup is painless.

Other solid options:

Stytch: Great for startups, generous free tier.
Auth0: The enterprise choice, now with much better passkey UX.
Corbado: Super fast setup, great for MVPs.
Descope: Most flexible for custom flows, has a visual workflow builder.
Supabase Auth: Passkeys now supported if you’re already on Supabase. Integration took me ~2 hours.

Common Mistakes to Avoid

❌ Forcing passkeys on everyone: Don't. Make it optional but encouraged.
❌ Overhauling the database: Just add a table for passkey data (public key, credential ID, device info). Existing users won't notice.
❌ Learning WebAuthn from scratch: Use a service and ship faster.
❌ Ignoring backup scenarios: Plan for when users lose devices.
⚠️ Keep in mind: Passkeys require HTTPS (localhost works for testing). Custom local domains need proper HTTPS, or WebAuthn will throw errors.

Advanced Considerations

Service Reliability & Vendor Lock-in

If your passkey provider goes down, most have 99.9% uptime, but keep email/password as a backup. Export user data regularly so you can switch providers if needed.

User Management Features

Users should manage passkeys like passwords. I added:

View registered devices: "iPhone 17, MacBook Pro, Windows Desktop"
Remove old passkeys: For lost/replaced devices
Passkey naming: "Work Laptop" vs "Personal Phone"
Usage analytics: Show last login times per device

Why You Should Add Passkeys Now

User expectation: Feels modern, missing it feels outdated.
Competitive edge: Still ahead of many apps, but not for long.
Security story: Great for investors and enterprise clients.
Support costs: Less password reset chaos.
Better conversion: Easy login = better retention.
Future compliance: Some industries will require strong authentication.

Your Playbook for Adding Passkeys

Start small: Add the login button and basic flow.
Pick a service: Stytch for startups, Clerk for full-stack, Auth0 for enterprise, Corbado for speed. Don’t reinvent the wheel.
Make it optional but encourage it: Nudges > forcing.
Test everywhere: Mobile, desktop, cross-device sync.
Plan for problems: Lost devices, account recovery.
Track adoption: See what works.
Ship it fast: This isn’t just a nice-to-have anymore.

The Bottom Line

It took me one weekend to add passkeys, and now my app is ready for users. Better security, smoother UX, and fewer support headaches.

Building something cool? I’d love to hear what you’re working on. If you’ve added passkeys to your project, drop a comment with your experience. I’m always learning too.

The Multi-Tab Logout Problem Nobody Warned You About

Thea — Mon, 25 Aug 2025 11:14:42 +0000

Picture this: you’re using your favorite web app. You have three tabs open — one with reports, one editing a document, and one checking settings.

In the settings tab, you click Logout.
You think you’re done… but when you switch back to the other tabs, surprise! They still look logged in. You can click buttons, type in forms, and maybe even see private data.

This is the multi-tab session problem. And it’s more common than you think.

Why This Problem Happens

Browsers don't automatically tell every tab that you've logged out in another one.
Yes, cookies are shared across tabs, but your app’s JavaScript in each tab doesn’t know what happened until it talks to the server again.

So you end with:

- Tab A -> You're officially logged out (server knows, UI knows)
- Tab B -> Your UI doesn't know what happened and hasn't updated yet

Result: a weird, broken state that can confuse users or even expose private data.

Real-Life Example

Imagine a design tool with a subscription:

- Tab 1: You’re using a premium feature.
- Tab 2: You cancel your subscription in settings.
- What happens? Tab 1 still lets you use the premium feature until refresh.

Bad for business (free features) and bad for the user (sudden “Access Denied” when saving). Everyone loses.

How Developers Fix It

The trick is simple: make your tabs talk to each other.
Step 1: When something important changes (like logging out), store that change in localStorage.
Step 2: Add a listener in every tab that watches for these changes:

window.addEventListener('storage', (event) => {
    // Check for our specific key and that it was set to 'loggedOut'
    if (event.key === 'authStatus' && event.newValue === 'loggedOut') {
        // Could reload, redirect, or update state
        window.location.reload();
    }
});

Now, if one tab logs out and sets authStatus = 'loggedOut', the other tabs instantly know.

Better approach: instead of always reloading (which can be annoying), you can show a message like: "You’ve been logged out" → redirect to login page.

Things to Remember

This only works for the same domain (yourapp.com).
The storage event fires only in other tabs, not the one that made the change.
For some apps, you may also want to sync session data between tabs, but that’s extra work.

The Bottom Line

If you’re building a web app with accounts, don’t forget the multi-tab case. Users won’t thank you when it works… but they’ll notice when it doesn’t.

Because the only thing worse than a broken logout is working inside a ghost session that died 20 minutes ago. 👻

Creating Text Shadows in CSS: Simple to Advanced Techniques

Thea — Fri, 15 Aug 2025 13:55:06 +0000

Ever wanted to add beautiful shadows to your text? CSS offers different methods depending on how complex you want your shadows to be. Let's explore both simple and advanced techniques!

The Simple Way: `text-shadow` (Best for Most Cases)

For basic shadows, use the built-in text-shadow property:

h1 {
  text-shadow: 2px 2px 4px rgba(0,0,0,0.3);
}

Why this is awesome:

Super easy to write
Works in all modern browsers
Best performance
Perfect for standard shadows
Supports multiple shadows in one rule (e.g., add a glow with -2px -2px 4px rgba(255,255,255,0.3))

When You Need Fancy Shadows: The `data-text` Technique

Sometimes you want special effects like:

Gradient shadows that match gradient text
Multiple shadow layers for depth
Advanced visual effects

The Problem With Duplicating Text

When creating complex shadows, you might duplicate text in HTML:

<h1>
  I ♥ coding
  <span class="shadow">I ♥ coding</span>
</h1>

This works but creates messy code that's hard to maintain.

A Cleaner Way: Using `data-text`

Here's a better way using a custom HTML attribute:

<h1 data-text="I ♥ coding">I ♥ coding</h1>

Then in your CSS:

h1 {
  position: relative;
  background: linear-gradient(135deg, #667eea, #764ba2);
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
  color: transparent; /* If -webkit-text-fill-color fails */
}

h1::before {
  content: attr(data-text);
  position: absolute;
  top: 0;
  left: 0;
  z-index: -1;
  background: linear-gradient(135deg, 
             rgba(102, 126, 234, 0.3), 
             rgba(118, 75, 162, 0.3));
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
  transform: translate(2px, 3px);
  filter: blur(1px);
}

Using attr(data-text) means you only write the text once in HTML. If you later change the text, you don’t have to edit multiple places.

How It Works

data-text attribute: Stores your text in HTML
attr(data-text): CSS grabs the text from the attribute
::before: Creates a shadow layer behind the real text
transform: Moves the shadow slightly
filter: blur(): Makes the shadow soft

Pro Tip: Use filter: blur() sparingly. It’s rendered on the GPU but can cause jank on lower-end devices. Avoid animating elements with blur or backdrop-filter.
Also, backdrop-filter has limited support in some older browsers, especially Firefox on Android.

Adding a Second Shadow Layer

For extra depth, add another layer with ::after:

h1::after {
  content: attr(data-text);
  position: absolute;
  top: 0;
  left: 0;
  z-index: -2;
  background: linear-gradient(135deg, 
             rgba(102, 126, 234, 0.2), 
             rgba(118, 75, 162, 0.2));
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
  transform: translate(4px, 5px);
  filter: blur(2px);
  opacity: 0.6;
}

Note: Stacking pseudo-elements like this adds a bit of rendering complexity, so reserve it for cases where text-shadow isn’t enough.

Important Things to Know

Browser Support

Works in Chrome, Firefox, Edge, and Safari
-webkit- prefixes (like -webkit-background-clip) are mainly for older browsers
Always test your designs in different browsers

Performance Tips

Avoid animating these effects (can slow down your page)
Too many filter: blur effects may lag on low-end devices
For simple shadows, text-shadow is always faster

Accessibility

These effects are visual only and won't affect screen readers
Make sure your text has enough contrast with the background

Alternative Methods

Using drop-shadow Filter

For some effects, you can try:

.filter-shadow {
  filter: drop-shadow(2px 2px 4px rgba(0,0,0,0.3));
}

drop-shadow works better than text-shadow for see-through text or images, because it keeps the shadow looking clean around transparent parts.

Multiple text-shadow Layers

For simple gradient-like effects:

.multi-shadow {
  text-shadow: 
    1px 1px 0 rgba(102, 126, 234, 0.4),
    2px 2px 0 rgba(118, 75, 162, 0.3);
}

When to Use Each Method

Situation	Best Technique	Why
Simple shadows	`text-shadow`	Easy to write, best performance
Multiple solid layers	`Multiple text-shadow`	Good balance of simplicity and effect
Gradient shadows	`data-text` method	Only way to achieve gradient shadows behind gradient text
Performance critical	`text-shadow`	No pseudo-elements or complex rendering
Complex animations	`filter: drop-shadow`	Can be GPU accelerated; works well with transforms
Accessibility	All methods	Ensure high contrast (4.5:1)

Try It Yourself

Check out all these shadow techniques with working examples and copy-paste code:

Demo on CodePen →

Text shadows can take your design from plain to wow. Start with the simple text-shadow for most cases, and level up to the data-text technique when you need those fancy gradient effects.
Happy coding!

SphereConnect: Creating Team Vibes for Axero's Intranet Challenge

Thea — Tue, 22 Jul 2025 12:16:36 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

What I Built

Meet SphereConnect! It's an intranet dashboard I created for Axero's "Holistic Webdev: Office Space" challenge, and honestly, I had way too much fun building it. Think of it as your team's digital meeting place where working together feels natural instead of forced.

Why SphereConnect? Because I wanted something that showed how it brings people together in one connected space, like a digital circle where ideas flow freely and everyone stays connected. Perfect match for what Axero had in mind!

Demo

Explore SphereConnect live!

🌐 Live Demo: SphereConnect

📂 GitHub Repo: github.com/highflyer910/sphereconnect

Screenshots

Dark Theme:

Light Theme:

Mobile View: A responsive 1-column layout, ensuring usability on the go.

My Development Adventure

Building SphereConnect was like putting together a fun puzzle - each piece had to work perfectly with the others while making teams' lives easier. Let me walk you through how it all came together!

The name

Choosing SphereConnect was pretty fun. I kept thinking about how the best workspaces feel like this connected space where everyone understands each other and ideas flow naturally. Plus, it sounds modern and friendly, exactly what I was going for!

Process

The Big Picture: I read Axero's requirements and got excited about creating something that would make people want to use their intranet. I planned out widgets for Announcements, Events, Team Spotlight, New Hires, Quick Resources, Tasks, and even a dual-mode Chat system. Oh, and that Welcome section with live weather? That was my "let's make this personal" moment.
My Toolkit:
- Vite-React (because life's too short for slow builds:))
- Material-UI (MUI) (consistent and beautiful)
- Lucide-React (clean icons)
- WeatherAPI.com
- Vercel Analytics (gotta know if people use this thing!)
Making It Pretty:
- Theme toggle was a must-have since some people prefer light mode, others prefer dark mode
- Added small hover effects and smooth animations because details matter
- Used a widget-based layout that feels familiar but not boring
Development:
- Welcome Section: Greets you with real weather and time (with a simple "allow location" button for privacy-conscious users)
- Chat Widget: Team chat for those "quick question" moments, plus an AI Assistant (though it's fake AI for now)
- Quick Resources: One-click access to all the tools you use - Time Tracker, Launch Pad, you name it
- Personal Touch: Resources that change based on who's logged in, including some of my dev.to posts
- Tasks Section: Create, track, and remember your tasks (thanks, localStorage!)
- Team Spotlight: A slideshow that makes everyone feel special
- New Hire Welcome: Because starting somewhere new shouldn't feel scary
Accessibility:
- Made sure it works well with screen readers and keyboard navigation
- Added alt text for avatars and icons.
Responsiveness:
- Responsive grid that goes from 3 columns to 2 to 1 as screens get smaller
- Tested on my phone, tablet, laptop, and it works everywhere!
Testing: Clicked every button, tried every feature, and tested it on many different browsers.

What This Taught Me

Vite is amazing: The development speed is so much faster
MUI Theming is Powerful: Once you learn it, you can make everything look exactly how you want
Accessibility Matters: Making sure everyone can use your site is important
Responsive Design takes time: Getting those screen size changes just right took longer than expected, but it was worth it

Future Plans

Real Navigation: Those navbar links need React Router to work
Actual AI: Time to replace the fake responses with a real language model
Multiple Languages: Adding language options because good design shouldn't be limited by language

Thanks to Axero

Huge thanks to Axero for creating such an inspiring challenge! It made me think beyond just "another dashboard" and consider what makes teams work well together. Plus, I got to build something I'm genuinely proud of, which is always great.

The Legal Stuff: MIT License for the open-source community, and Axero gets to showcase this work while I keep ownership. Fair deal all around!

Thanks for taking the time to check out SphereConnect! Building it was fun, and I hope exploring it brings a little joy to your day.✨

Forem: Thea

Modern Web Guidance: Teaching AI Agents to Stop Coding Like It's 2019

What Is Modern Web Guidance?

The Problem It's Actually Solving

Trying It Out

The Baseline Integration Is the Clever Part

An Honest Critique

Should You Install It?

Getting Started

Idempotency Keys: What Most Tutorials Don't Tell You

The Problem: "The Double Tap"

What Is Idempotency?

Important edge case: idempotency ≠ caching

The Key: Idempotency-Key

Where does the key live on the client?

The Server Side: Where the Real Work Happens

The Real Danger: Concurrency

The fix

Don't use SQL?

Fake Idempotency (Very Common)

Key Expiration: The Gotcha Nobody Mentions

The Full Flow

A Quick Note on HTTP Methods

Idempotency Beyond Payments

How to Test It (Because Trust, But Verify)

Quick Checklist

TL;DR

Future Museum of Extinct Things - A Glimpse from 2100

What I Built

Demo

Code

highflyer910 / future-museum

Future Museum of Extinct Things

What It Is

How I Built It

Prize Categories

git blame --emotions: No Solutions. Just Vibes.

What I Built

Demo

Code

highflyer910 / git-blame--emotions

git blame --emotions 💔

What It Does

Tech Stack

How I Built It

Prize Category

☕ Best Ode to Larry Masinter

🤖 Best Google AI Usage

🌟 Community Favorite

DevStretch: The Antiburnout Protocol for Devs Who Forgot They Have Bodies

The Community

What I Built

Demo

Code

How I Built It

Smooth Page Transitions with Zero Libraries: The View Transitions API

What Is the View Transitions API?

The Core Pattern (Only 3 Steps!)

See It in Action

Advanced Technique #1: Directional Back Navigation

Advanced Technique #2: Custom Animations for Specific Elements

When to Use It (and When Not To)

Final Thoughts

Single-tenant vs Multi-tenant: What I Wish I Knew When I Started

The Analogy (Houses vs. Apartments)

- Postgres: Built-in schema support

Security (The Scary Part)

Why I chose multi-tenant

What Should You Do?

Final Thoughts

I Thought My Backups Were Safe - Until I Tried Restoring One

My Wake-Up Call

What I Learned About Backups While Building Side Projects

How Bigger Teams Handle It

🧠 What to Back Up

⏰ When to Test

Why It Matters

Passkeys Without the Pain: A Frontend Dev’s Guide

What Are Passkeys, Anyway?

The Simplest Way to Add Passkeys (That Actually Works)

The Key: `Idempotency-Key`

The Simple Way: `text-shadow` (Best for Most Cases)

When You Need Fancy Shadows: The `data-text` Technique

A Cleaner Way: Using `data-text`