Forem: Thea

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.✨

Deploy Your FastAPI App on Vercel: The Complete Guide

Thea — Mon, 30 Jun 2025 12:09:14 +0000

So I was working on this FastAPI project last week and needed to deploy it somewhere. I tried a few different platforms, but Vercel turned out to be simple, much easier than I expected!

What You Need

Just basic stuff:

Your FastAPI app(obviously)
GitHub account
Vercel account

That's it. No need for complicated server setup or Docker stuff.

Getting Your App Ready

First, make sure your FastAPI app is working. Here's my simple example:

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Look Ma, I'm deployed!"}

@app.get("/api/health")
def health_check():
    return {"status": "healthy"}

Pretty straightforward, right?

Requirements File

You need a requirements.txt file so Vercel knows what packages to install:

fastapi==0.104.1
uvicorn==0.24.0

Important: Always pin your versions! Trust me, I learned this the hard way when my app broke because of package updates.

Vercel configuration

This part is a bit tricky, but not too bad. Create a vercel.json file in your project root:

{
  "version": 2,
  "builds": [
    {
      "src": "main.py",
      "use": "@vercel/python"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "main.py"
    }
  ]
}

This tells Vercel, "hey, this is a Python app, run it like this".

Small change needed

Vercel works with ASGI apps (FastAPI is ASGI), but you need to add this:

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello World from FastAPI on Vercel!"}

@app.get("/api/health")
def health_check():
    return {"status": "healthy"}

# This is important for Vercel
if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Push to GitHub

Get your code on GitHub:

git init
git add .
git commit -m "Initial FastAPI app"
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

Deploy time!

Now the fun part:

Go to the Vercel dashboard
Click "New Project"
Connect your GitHub repo
Vercel detects it's Python automatically
Click "Deploy"

And... that's it! No server configuration, no SSL certificates, nothing complicated.

Using CLI instead

If you prefer the command line (like me):

# Install Vercel CLI
npm install -g vercel

# Log in via CLI
vercel login

# Deploy
vercel

Three commands and you're done!

Auto-deployment with GitHub Actions

Want to deploy automatically when you push code? Here's the workflow file:

# .github/workflows/deploy.yml
name: Deploy to Vercel

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: amondnet/vercel-action@v3
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}

Testing your deployment

After deployment, check these URLs:

https://your-app.vercel.app/ - Main page
https://your-app.vercel.app/api/health - Health check
https://your-app.vercel.app/docs - FastAPI docs (this is a cool feature!)

Things I learned (the hard way)

Vercel gives you HTTPS automatically - no need to worry about certificates
Environment variables are easy to add in the Vercel dashboard
Every push to main branch = new deployment
Use /api prefix for your routes. Vercel likes it better, especially when you have frontend + backend together

When something breaks

Don't worry, it happens to everyone:

Check build logs in the Vercel dashboard - they usually show what's wrong
Look at your requirements.txt, missing packages cause most problems
Verify your vercel.json configuration
Test locally first. If it doesn't work on your computer, it won't work on Vercel

Final thoughts

That's it! Your FastAPI app is now running on Vercel's servers worldwide. No need to manage servers or worry about hosting costs (unless you become popular, but that's a good problem to have 😄).
The whole process takes maybe 10-15 minutes once you know what you're doing. Pretty good for getting your API online, I think!

'No Awkward Breakups'? Why I Migrated From Appwrite to Supabase After a Broken Promise

Thea — Tue, 29 Apr 2025 11:39:46 +0000

I’m not one to write takedown blog posts. I love exploring new dev tools and I genuinely support open-source platforms. But when a company, especially its CEO, makes a clear promise and breaks it without explanation, I think the dev community deserves transparency.

Here’s what happened with Appwrite.

The Offer

On February 28, I received an email from Appwrite’s CEO, Eldad Fux, offering what sounded like a simple gift:

“Here's a free month of Appwrite Pro… no awkward breakups needed.”

I had been working on KitchenPal, a personal AI-powered recipe project. I thought this was the perfect opportunity to try out Appwrite’s paid features during development.

What I Did

Date	Action	Proof
Feb 28	Received CEO’s email offering free Pro features
March 2	Activated the $15 credit exactly as instructed
March 31	Downgraded my plan before renewal

I expected that if I downgraded within the credit window, I wouldn’t be charged and would simply return to the free tier.

What Happened Instead

One week after downgrading, on April 7, my Appwrite account was restricted, and I was asked to pay $15 to unlock access to my database.
This was confusing for a few reasons:

-The platform said I had Pro features “until April 30.”
-I had no users or activity to “run out” the credits.
-The CEO promised “no awkward breakups.”

The Fine Print Argument

Support later said the credits were gone and that the upgrade page included a message:

“You’ll pay $0.00 now. Once credits run out, you’ll be charged $15 every 30 days.”

But there was no activity to “run out” the credits.
And I never saw that. And even if it was there, it contradicted the CEO’s message and the downgrade confirmation I received.

My Timeline and Attempt to Resolve It

I tried multiple channels to get this resolved:

Direct email to the CEO on March 31,
Support ticket after the restriction on April 7
Follow-up emails to support on April 9 with screenshots
Follow-up email to both support and the CEO on April 14

As of April 29, there was no reply.

The Invoice Tells the Real Story

Appwrite’s invoice shows I was billed for March 1–31, yet I activated Pro on March 2.
Their own docs state billing starts when you upgrade, but they charged me for March 1 despite activating March 2.
That means:

I was charged for a day I didn’t even use.
I got 29 days of “30-day” credits.
My access was blocked 7 days after downgrading, not at the end of the cycle.

This isn’t about $15.

Let me be clear: this isn’t about the money.
It’s about trust. And transparency.

I didn’t mind paying for a tool that works. I just didn’t expect to be billed after downgrading early, especially when the offer was framed as “no awkward breakups.”

The Outcome: I Moved to Supabase

After two weeks of silence, I decided to stop waiting.

I migrated my project KitchenPal to Supabase and rebuilt everything to restore access to my data.

Honestly? I’m glad I did. Supabase is working well so far, and my app is now live in beta:
👉KitchenPal
Feel free to try it out!

Surprisingly, this became a valuable learning experience. Forcing myself to migrate to a new backend:

Pushed me to explore Supabase's features more deeply than I might have otherwise
Improved my database architecture skills through the rebuild
Proved the importance of vendor flexibility in personal projects

What I’d Like to See

I still want Appwrite to succeed. But here’s what would make a difference:

Honor the full 30 days of credit.
Don’t restrict downgraded accounts mid-cycle.
Make billing terms and time limits clearer.
Respond to users, especially when things go wrong.

Let’s Talk

Have you run into similar issues with Appwrite or other platforms?
I’m sharing this after three weeks of silence, not to attack, but to give developers a heads-up and to celebrate how challenges can spark growth.
Let’s keep dev tools honest and dev-first 💙

Lost Without Tech: How Our Brains Are Changing

Thea — Wed, 26 Mar 2025 11:54:05 +0000

Hello, my friends and family!

Have you noticed how quickly technology is changing our world? It seems like every day brings something new that transforms how we live, work, and even think.

Let me give you a simple example: navigation. In the past, people used paper maps to find their way, which wasn't always easy. Now, apps guide us everywhere. But it's more than just getting from one place to another - technology is changing how we experience the world.

My little niece recently made me laugh. When I showed her an old paper map, she looked confused. "Why would anyone use something that doesn't show exactly where you are?" she asked. And she was right.

Back in the day, we used to build mental maps. We noticed landmarks. We remembered routes. We developed a sense of direction. Now, we just follow the blue line on our phones and trust the app completely. What if our phone battery dies? We're lost.

But this is about more than just finding our way. It's about how technology is reshaping our thinking.

Remember when people worried calculators would make kids bad at math? Now, our phones do even more. They remember birthdays, save passwords, and even finish our sentences. We've become experts at finding information, but we might be losing our ability to remember it.

Is this bad? Not really. It's just different. Think about how people felt when writing was first invented. They thought people would stop remembering stories. In a way, they were right. But look at everything we've gained.

The key is choosing what to keep in our minds. Some skills are important to remember:

How to show care for someone we love
How to think critically about online information
How to solve problems without technology

As AI starts writing emails and virtual reality becomes more common, we need to be smart about which mental skills we keep sharp.

Here's a challenge: Next time you go somewhere new, try turning off navigation for part of the trip. Look around. Notice things. Let your brain create its map.

Because the most amazing technology we'll ever have is still the one between our ears.

Forem: Thea

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)

Step 1: Add One Button

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

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

Common Mistakes to Avoid

Advanced Considerations

Service Reliability & Vendor Lock-in

User Management Features

Why You Should Add Passkeys Now

Your Playbook for Adding Passkeys

The Bottom Line

The Multi-Tab Logout Problem Nobody Warned You About

Why This Problem Happens

Real-Life Example

How Developers Fix It

Things to Remember

The Bottom Line

Creating Text Shadows in CSS: Simple to Advanced Techniques

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

When You Need Fancy Shadows: The data-text Technique

The Problem With Duplicating Text

A Cleaner Way: Using data-text

How It Works

Adding a Second Shadow Layer

Important Things to Know

Alternative Methods

When to Use Each Method

Try It Yourself

SphereConnect: Creating Team Vibes for Axero's Intranet Challenge

What I Built

Demo

Screenshots

My Development Adventure

The name

Process

What This Taught Me

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

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

A Cleaner Way: Using `data-text`