DEV Community: Saad Ahmad

I built a chat app that forgets 🔥

Saad Ahmad — Mon, 14 Sep 2026 15:15:29 +0000

There's a kind of conversation that doesn't belong in WhatsApp. 💬

You need to send someone a document. Or say something that shouldn't sit in a thread forever. Or talk to a person you'd rather not add to your contacts. Every option feels wrong — message them somewhere that keeps a copy of everything, email them and leave a permanent paper trail, or dig out a file-sharing site that looks like it hasn't been touched since 2009.

So I built CipherDrop. Open a room, share the ID, talk, delete. 🗑️

Nobody signs up. Nobody hands over a phone number or an email. And when the room goes, it takes everything with it.

🔗 Try it: https://cipherdrop.saadbhatti888.workers.dev

🤔 Who is this actually for?

Not everyone needs this. But if any of these sound familiar, it was built for you:

📄 Sending a document to someone you barely know. A contract, an invoice, a CV. You need it to arrive — you don't need it living in a chat thread for the next five years.
🧑‍💻 Freelancers and clients. A quick channel for one project, closed the day it ships.
🛒 Buying or selling something online. Talk to a stranger without giving them a way to reach you afterwards.
🏥 Anything sensitive but ordinary. A medical result, a bank detail, a password. Things you'd rather not leave sitting in someone's message history.
🎓 Group work with people you'll never speak to again. One room, everyone in, delete when done.
🚪 Just wanting a door you can close. Sometimes that's the whole reason.

⚡ How it works

Create a room and you get an ID. Send it to one person or a whole group — text it, WhatsApp it, read it down the phone. However you like.

Rooms come in two shapes:

👥 Just the two of us — you approve one person, and the room is then closed. A third person who somehow gets hold of the ID is simply told the room is full. No waiting list, no peeking in.

🌐 Group — anyone holding the ID walks straight in.

When someone knocks on a private room, a card appears over your chat with their name and two buttons: let them in, or don't. They're inside a second later, no refreshing on either end. ✨

🎁 What's inside

💬 Everything arrives instantly — text, photos, video, documents and voice notes, with no refreshing and no waiting.

✅ Read receipts you can trust — one tick when it's sent, two when it's delivered, two blue when it's actually been read.

😂 Reactions — tap a message, pick an emoji, tap again to take it back.

🎙️ Voice notes done properly — tap the mic and you get a real recorder with a timer and bars that move with your voice. Bin it or send it. Playback is a waveform you can scrub through, not a grey browser box.

📎 Attachments that don't bury the conversation — a photo arrives as a neat chip rather than a wall of image. Tap to open it full screen, with download and close right there. Videos open in a player. Documents show you the name, type and size, with one button to save them.

📤 Uploads you can watch happen — the message appears the moment you pick a file, with a live percentage, then settles into the real thing.

🔒 A lock, when you want one — flip it on, choose a key, and your message is scrambled in your own browser before it's sent anywhere. The other person sees "Locked" until they tap it and enter the same key. Share that key any way you like — out loud is fine.

🧹 Delete, and mean it — one press removes the room, every message in it, and every file anyone uploaded. Anyone still inside is sent home immediately.

📱 It installs like an app — open it on your phone, tap install, and it lives on your home screen with its own icon and no address bar in sight.

🛡️ How safe is it, really?

Fair question, and I'd rather answer it plainly than hide behind buzzwords.

Rooms are genuinely closed. 🚪 Knowing a room's address isn't enough to get into it. If you weren't let in, you see a locked door — not the conversation.

Nobody can pretend to be someone else. 🎭 Your name in a room is fixed the moment you're approved, and two people can't use the same name in one room.

Nothing is broadcast to the open internet. 📡 Live messages travel on a private channel that has to be unlocked for each person individually.

You can scramble a message before it leaves your device. 🔐 Use the lock and only someone with your key can read it — including in the unlikely event anyone ever got to the storage behind the app.

Deleted means deleted. 🗑️ Not hidden, not archived. The messages and the files both go.

No account means nothing to leak. 👤 There's no email, no password, no phone number, because there's nothing to sign up for.

And now the honest part 🙂

I'd rather undersell this than have someone trust it too far.

CipherDrop is not Signal. It's built with care, but it's a young app made by one person, and it hasn't been reviewed by a security team. Messages you don't lock are stored normally on the way through. And anyone who gets your room ID can ask to join — so treat that ID like a password and only send it to the person you mean.

For a document you'd rather not leave lying around, a conversation you want to end cleanly, or a chat with someone you'd prefer not to keep in your contacts — it does that job well. ✅

If your physical safety depends on a conversation staying private, use a tool that's been audited by people whose full-time job that is. 🙏

🚀 What's next

Rooms currently sit there until someone deletes them. Automatic clean-up is next — rooms that quietly disappear after a day, or after a couple of hours of silence, files included. Then a Play Store version. 📲

If you try it and something feels off, I'd genuinely like to hear about it. 💭

Built by Saad Ahmad — isaadahmad.com

🔗 Try CipherDrop: https://cipherdrop.saadbhatti888.workers.dev

Scroll animations in React that never touch the main thread

Saad Ahmad — Fri, 04 Sep 2026 08:12:31 +0000

Every scroll animation library I have reached for over the last few years does the same thing: it listens to the scroll event, reads the element's position, and writes a new transform. Sixty times a second, on the main thread, next to your hydration and your data fetching and your own click handlers.

The browser has had a better way to do this since Chrome 115 shipped in July 2023. ScrollTimeline and ViewTimeline let you hand your keyframes to the browser's own animation engine and say "this animation's playhead is the scroll position". For transform, opacity and filter, the compositor takes it from there. No JavaScript runs per frame. None.

Almost nobody uses it. Not because it is obscure — because it is awkward:

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

.card {
  animation: reveal linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 40%;
}

That is fine in a stylesheet. Inside a component, where the distance is a prop and the range depends on the layout, it means generating CSS strings or writing a <style> tag by hand. And you still need to answer the question "what happens in Firefox?" — which, as of today, still has scroll-driven animations behind a flag in stable.

Those two problems are exactly what a hook should hide. So I built one.

use-scroll-timeline

npm i use-scroll-timeline

"use client";
import { useScrollReveal } from "use-scroll-timeline";

export function Card() {
  const ref = useScrollReveal<HTMLDivElement>({ variant: "fade-up" });
  return <div ref={ref}>I reveal myself as I scroll into view</div>;
}

3.7 kB min+gzip. Zero dependencies. Six hooks. No provider, no context, no CSS import.

Live demo — every hook, with live read-outs →

Anything more specific goes through the core hook, which takes plain Web Animations keyframes — the same object you would pass to element.animate():

const ref = useScrollTimeline<HTMLElement>({
  keyframes: {
    opacity: [0, 1],
    scale: ["0.8", "1"],
    filter: ["blur(8px)", "blur(0px)"],
  },
  range: ["entry 0%", "cover 40%"],
});

The part I like most: progress as a CSS variable

Most scroll libraries hand you a number and let you put it in state. That number arrives every frame, so your component re-renders every frame, and now you have a JavaScript scroll animation again with extra steps.

useScrollProgress writes progress into a CSS custom property instead and re-renders nothing:

const ref = useScrollProgress<HTMLDivElement>({ timeline: "scroll" });

<div ref={ref} className="reading-bar" />;

.reading-bar {
  transform-origin: left;
  scale: var(--progress, 0) 1;
}

Where the native API exists, the hook registers that property with CSS.registerProperty and lets the browser animate it. So the reading progress bar at the top of a page — the thing every blog implements with a scroll listener — costs zero main-thread work.

useScrollProgressValue still exists for when you genuinely need the number in React. It is throttled by a precision option, defaulting to about 100 renders across the whole range instead of one per frame.

The fallback is the interesting bit

This is the part I expected to be ugly and turned out clean.

The naive fallback is to reimplement keyframe interpolation in JavaScript — parse the values, lerp them, write styles. That is a lot of code and a lot of ways to be subtly wrong about translate versus transform versus filter.

Instead: build the exact same WAAPI animation, pause it, and scrub it.

const animation = element.animate(keyframes, { duration: 1000, fill: "both" });
animation.pause();

// later, from the scroll driver:
animation.currentTime = progress * 1000;

The browser is already an excellent keyframe interpolator. The fallback borrows it and only replaces the clock. Same keyframes, same easing, same fill behaviour, no interpolation code of my own — and the difference between the native path and the fallback becomes where the playhead comes from, nothing else.

The driver itself is one IntersectionObserver per element to gate the work, and one shared requestAnimationFrame loop plus one capture-phase scroll listener for the entire page. Ten animated elements cost one frame callback, not ten.

Named ranges, which are the actual API

The variants are the marketing; the ranges are the feature. This is the vocabulary from the CSS spec, and the hooks take it verbatim as strings:

Range	Starts when	Ends when
`cover`	subject's leading edge touches the scrollport	subject has completely left
`entry`	subject starts entering	subject is fully in
`exit`	subject starts leaving	subject has completely left
`contain`	subject is fully inside	subject starts leaving

range: ["entry 25%", "contain 50%"]

Here is the thing that cost me an afternoon and is worth knowing whether or not you use this package: the entry range is exactly as long as the element's own height. A 150px card finishes its entire reveal in 150px of scrolling. It technically works, it is spec-correct, and it looks like nothing happened.

End the range later and the same animation becomes something you can actually see:

useScrollReveal({ range: ["entry 0%", "cover 40%"] }); // ~400px of travel

I only understood this properly after building a panel that watches one element through entry, contain and exit simultaneously and prints all three numbers. Watching them hand over to each other is the fastest way to internalise the model — it is the first section of the demo.

Reduced motion, and why your page might look broken

prefers-reduced-motion: reduce is respected by default: the hook skips the animation and lands the element on its final keyframe.

This is correct behaviour that looks exactly like a bug. If you have "Animation effects" turned off in Windows or "Reduce motion" on in macOS, every reveal on the page appears already revealed, parallax layers sit still, and changing a prop seems to do nothing. I lost a good twenty minutes to this on my own library. Both demos now detect it and say so in a banner, and you can opt out per hook with respectReducedMotion: false.

Where it runs natively

Browser	Path
Chrome / Edge 115+	Native `ViewTimeline` / `ScrollTimeline`
Safari 26+	Native, threaded since 26.4
Firefox	Fallback — still behind a flag in stable
Anything older	Fallback

Roughly 80% of users get the compositor path today, and the number only goes up. The remainder get an animation that is visually identical and still cheaper than a typical scroll-listener implementation, because the whole page shares one loop.

Three things shipping it taught me

tsup silently ate my "use client" directive. The banner was configured correctly, but tsup's rollup treeshaking pass strips module-level directives from the bundle — so the built file had no directive and the package would have broken in the App Router. Fixed with a tiny post-build script that re-attaches it on the same line as the first statement, which keeps source-map line numbers accurate.

publint found a real bug in my exports map. I had a single types field, which means TypeScript resolves the ESM .d.ts even when the consumer uses require(). CJS users would have had types that only work under dynamic import(). Split into import and require conditions pointing at .d.ts and .d.cts. Run publint --strict and attw --pack . before your first publish — always.

"provenance": true in publishConfig breaks a manual publish. Provenance can only be generated on a supported CI runner, so that flag makes npm publish from your laptop fail outright. Leave it out of the manifest and pass --provenance in the release workflow instead.

Links

Demo — https://use-scroll-timeline-demo.vercel.app/
npm — use-scroll-timeline
Source — github.com/saadahmad888/use-scroll-timeline
Related — stack-on-scroll, the sticky stacking-card version of the same idea

It is 0.1.0, so the API can still move. If you use it and something is awkward, an issue is genuinely welcome — that is the most useful thing anyone can send me right now.

Built by Saad Ahmad. I build small, focused front-end libraries and the sites that show them off — TypeScript, React, Next.js, and a slightly unreasonable interest in what the platform can already do without a dependency.

More of my work at isaadahmad.com.

If your team is fighting a janky scroll page, carrying 70 kB of animation library for four effects, or needs a component library packaged properly — that is the kind of work I take on, and my inbox is open.

I shipped a dark mode hook. Then I found four bugs my own demo never hit.

Saad Ahmad — Mon, 31 Aug 2026 15:36:05 +0000

Four months ago I published use-theme-mode, a small React hook for light/dark theming. It did what I wanted: managed the state, persisted the choice, read the system preference, and stayed out of my CSS.

It worked perfectly in my demo.

Then people started using it in apps that weren't mine, and I found four bugs that my demo had never once triggered. Not edge cases — the kind of thing that breaks a real page on a real Tuesday.

This is what was wrong, why my testing missed it, and what 2.0 does about it.

Bug 1: every call site had its own state

Here's the v1 hook, trimmed:

function useTheme() {
  const [theme, setTheme] = useState(getInitialTheme);

  useEffect(() => {
    document.documentElement.setAttribute("data-theme", theme);
    localStorage.setItem(THEME_KEY, theme);
  }, [theme]);

  return { theme, toggleTheme, setLight, setDark };
}

Spot it? useState lives inside the hook. Call useTheme() in two components and you get two independent pieces of state.

function Header() {
  const { toggleTheme } = useTheme();   // state copy A
  return <button onClick={toggleTheme}>Toggle</button>;
}

function Sidebar() {
  const { theme } = useTheme();         // state copy B
  return <Icon name={theme === "dark" ? "moon" : "sun"} />;
}

Click the button. The attribute on <html> flips, so the page turns dark. But Sidebar never re-renders, because its copy of the state never changed. The icon keeps saying "light".

My demo had one component. Of course it worked.

The fix is to move the state out of React entirely. v2 keeps a single module-level store and every hook instance subscribes to it:

const listeners = new Set<() => void>();

export function subscribe(listener: () => void) {
  listeners.add(listener);
  return () => listeners.delete(listener);
}

function commit(next: ThemeState) {
  state = next;
  applyToDom(next.resolvedTheme);
  for (const listener of listeners) listener();
}

The hook becomes a thin subscription. Twenty components, one source of truth.

I hand-rolled the subscription rather than reaching for useSyncExternalStore, because that's React 18+ and I wanted to keep the 16.8 peer range. It's about fifteen lines.

Bug 2: system mode that stopped listening

v1 read prefers-color-scheme exactly once, inside the useState initialiser:

const prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
return prefersDark ? "dark" : "light";

That's a snapshot, not a subscription. Change your OS appearance while the tab is open — which macOS does automatically at sunset — and the page ignores you until you reload.

Worse, v1 immediately wrote that snapshot to localStorage. So the very first visit permanently pinned you to whatever your OS happened to prefer at that moment. There was no way to say "just follow the system" and mean it.

v2 treats "system" as a real, storable value that resolves at read time:

function resolve(theme: string, systemTheme: ColorScheme | undefined) {
  if (theme !== "system") return theme;
  return systemTheme;
}

and attaches a listener so the resolution stays live:

mediaQueryList.addEventListener("change", (event) => {
  const systemTheme = event.matches ? "dark" : "light";
  commit({ ...state, systemTheme, resolvedTheme: resolve(activeTheme(), systemTheme) });
});

This is why the hook now returns three values instead of one:

	means
`theme`	what the user chose — may be `"system"`
`resolvedTheme`	what's actually on screen
`systemTheme`	what the OS prefers, regardless of the choice

If you were branching on theme === "dark", switch to resolvedTheme or the new isDark flag.

Bug 3: localStorage can throw

This line looks harmless:

const storedTheme = localStorage.getItem(THEME_KEY);

It isn't. Accessing localStorage throws a SecurityError in several ordinary situations:

Safari in private browsing, historically
inside a sandboxed <iframe> without allow-same-origin
when a user has blocked all cookies and site data
some enterprise-managed browser policies

And because v1 called it during the useState initialiser, the throw happened during render. Not a broken theme — a blank page.

v2 wraps every storage access:

function readStored(): string | null {
  try {
    return getStore()?.getItem(config.storageKey) ?? null;
  } catch {
    return null;
  }
}

When storage is unavailable the theme still works for the session; it just doesn't survive a reload. Degraded, not dead.

There's a related fix: v1 applied whatever string it found in storage straight to the DOM. v2 validates it against the configured theme list first, so a stale or tampered value falls back to the default instead of putting data-theme="<script>" on your <html>.

Bug 4: the flash

The one everybody notices and nobody reports as a bug, because it feels like the cost of doing business.

In v1 the DOM update lived in an effect:

useEffect(() => {
  document.documentElement.setAttribute("data-theme", theme);
}, [theme]);

Effects run after paint. So the sequence is: browser paints your default (light), React hydrates, effect fires, page snaps to dark. On a fast connection it's a blink. On a slow one it's a second of white.

You cannot fix this from inside React. The correct theme has to be on the element before the browser's first frame, which means a synchronous script in <head>.

v2 ships one. <ThemeScript /> renders a ~0.8 kB blocking IIFE that reads storage, resolves system preference, and writes the attribute — before anything paints.

// app/layout.tsx
import { ThemeScript } from "use-theme-mode";

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <head>
        <ThemeScript />
      </head>
      <body>{children}</body>
    </html>
  );
}

For Vite there's themeScript(), which returns the raw string so you can inline it at build time:

// vite.config.js
import { themeScript } from "use-theme-mode";
import { themeOptions } from "./src/theme-options.js";

function noFlashTheme() {
  return {
    name: "no-flash",
    transformIndexHtml: (html) =>
      html.replace("</head>", `<script>${themeScript(themeOptions)}</script></head>`),
  };
}

The demo site uses exactly this. Both the plugin and <ThemeProvider> read the same options object, so the pre-paint pass and the React runtime can't drift apart.

Here's the test I like: block the JavaScript bundle entirely and reload. React never mounts — and the page still comes up in the right theme, because the only thing that ran was the inline script.

What else 2.0 adds

Fixing the four bugs was the reason for a rewrite. Once I was in there, three things were worth adding.

Unlimited themes

Light and dark was always an artificial limit. The hook writes a string to an attribute; it has no opinion about which strings are legal.

<ThemeProvider
  themes={["light", "dark", "sepia", "nord"]}
  colorSchemes={{ sepia: "light", nord: "dark" }}
>
  <App />
</ThemeProvider>

colorSchemes is the part that's easy to miss. It sets the CSS color-scheme property so native UI — scrollbars, checkboxes, the text caret, date pickers — matches your custom theme. Without it, a beautiful dark "nord" page gets a bright white scrollbar.

toggleTheme() now cycles the whole list and wraps around. With the default two themes, that's still a plain toggle.

`class` or any attribute

v1 hardcoded data-theme. Tailwind's dark: variant wants a class, so Tailwind users had to reconfigure their build to match my library — backwards.

<ThemeProvider attribute="class">

Tailwind v4 then needs one line of CSS:

@import "tailwindcss";
@custom-variant dark (&:where(.dark, .dark *));

You can also pass an array — attribute={["class", "data-theme"]} — if part of your stack wants one and part wants the other.

A configurable storage key

v1 hardcoded "app-theme". If you had another library using the same key, or wanted a per-tenant key, you were out of luck.

<ThemeProvider storageKey="my-app-theme" storage="session" />

storage accepts "local", "session" or "none".

The size question

The whole point of this package is being small, so:

you import	gzipped
`useTheme` only	1.84 kB
`useTheme` + `ThemeProvider`	2.64 kB
`themeScript` only	0.84 kB
everything	2.66 kB

Zero runtime dependencies. sideEffects: false and dual ESM/CJS output, so bundlers can drop what you don't import. TypeScript declarations ship with the package.

Migrating

Nothing was removed. useTheme, theme, toggleTheme, setLight and setDark all behave the same.

Two things to check:

1. The default storage key changed from app-theme to theme. If you have users with a saved preference, keep it:

<ThemeProvider storageKey="app-theme">

2. theme can now be "system". If you branch on it:

- const { theme } = useTheme();
- const isDark = theme === "dark";
+ const { isDark } = useTheme();

That's the whole migration.

What I actually learned

The bugs weren't subtle. useState inside a hook creating per-instance state is something I'd explain to someone else in an interview. Reading a media query once instead of subscribing is a well-known trap. I still shipped both.

What let them through wasn't ignorance, it was the shape of my testing. One component, one browser, one tab, storage enabled, OS theme never changing, always on localhost with a warm cache. Every one of the four bugs lives outside that box.

The demo I've built for v2 is deliberately harder on itself: four themes, several components reading the hook at once, a live readout of what the hook returns, and a second-tab test. Every bug above would be visible on that page within about ten seconds.

If you maintain a small package: the day someone opens an issue is the day it starts getting good.

Try it: use-theme-mode-demo.vercel.app — four themes, a live view of the hook's return value, and the OS-change test.

npm: npm install use-theme-mode
GitHub: saadahmad888/use-theme-mode

Issues and PRs welcome. If v2 breaks something for you, that's the useful kind of feedback — tell me.

My 4KB React package was installing 116 dependencies. Here's what I found when I audited it.

Saad Ahmad — Mon, 24 Aug 2026 12:34:59 +0000

I published a small React component to npm. Four kilobytes. One job: stack cards as you scroll.

Then I sat down and actually audited it — the way you'd audit someone else's package before adding it to production.

It was installing 116 packages onto every machine that ran npm install.

Here's everything that was wrong, why each one mattered, and how to check your own packages tonight. 🔍

🚨 Bug 1: I was shipping a bundler to my users

This was in my package.json:

"dependencies": {
  "rollup": "^4.40.1",
  "rollup-plugin-postcss": "^4.0.2",
  "@types/react": "^19.1.2"
}

Those are build tools. They belong in devDependencies. Sitting in dependencies, npm faithfully installed all three — plus their transitive deps — into every consuming project.

I measured it. Installing that dependency set pulls 116 packages. My actual library is one file.

The fix is a two-second edit. The lesson is that nobody ever looks:

npm view your-package dependencies

Run that on your own packages right now. If a build tool comes back, that's a bundler on someone else's laptop. 😬

💥 Bug 2: React's JSX runtime was baked into my bundle

My rollup.config.js had this:

external: ["react", "react-dom"]

Looks right. It isn't.

My tsconfig.json used "jsx": "react-jsx", so every component compiled to an import from react/jsx-runtime — a different specifier than react. It wasn't in external, so Rollup happily inlined it.

Worse: it inlined the development build, which contains this:

process.env.NODE_ENV

process doesn't exist in a browser. Anyone importing my package through plain ESM or certain Vite configs got a hard crash: process is not defined.

I had rollup-plugin-peer-deps-external installed to prevent exactly this. But I'd never declared any peerDependencies — so it read an empty list and did nothing. A safety net bolted to the ceiling. 🪤

// what it should have been
external: ["react", "react-dom", "react/jsx-runtime", "react/jsx-dev-runtime"]

⚛️ Bug 3: No `"use client"`, so Next.js rejected it

My components use hooks. Under the Next.js App Router, that makes them client components — and they must say so.

Mine didn't. Anyone on modern Next.js hit an error immediately.

The fix is one line at the top of the built bundle. But here's the part that nearly bit me twice: esbuild strips module-level directives when it bundles, and tsup's banner option doesn't survive minification.

I only caught it because I checked the built file instead of trusting the config:

head -c 20 dist/index.js

Now a post-build script adds the directive, and a test asserts it's there. Which brings me to the thing I'd most want you to take away. 👇

🧪 The real lesson: test the artifact, not the source

Every bug above lived in dist/, not src/. My source code was fine. Unit tests passing means nothing if the thing you ship is broken.

So I wrote tests that read the built output:

it('never references process.env', () => {
  expect(esm).not.toContain('process.env');
});

it('leaves the JSX runtime external', () => {
  expect(esm).toMatch(/from\s*["']react\/jsx-runtime["']/);
});

it('opens with the use client directive', () => {
  expect(esm.startsWith('"use client";')).toBe(true);
});

Every one of those exists because the previous release shipped that exact mistake. They're regression tests for bugs I'd already inflicted on people.

Two tools do most of this for you, and both take under a minute:

npx publint          # catches malformed exports, wrong entry points
npx @arethetypeswrong/cli --pack .   # catches broken TypeScript resolution

If you maintain a package and have never run these, go run them. 🎯

🔎 Bug 4: Zero keywords, zero downloads

My npm page said Keywords: none.

npm search is largely keyword-driven. No keywords means you are effectively unlisted. My weekly downloads were zero, and I'd assumed the idea was unpopular. It was just invisible.

My description also read "Reuseable Stack on scroll librabry" — two typos in the single line that shows up in search results. 🙈

🐛 Bug 5: The one my tests couldn't catch

After shipping v2, I rebuilt my demo site on it — and the build failed with a TypeScript error.

My hook returned RefObject<T | null>. React 19's types accept that. React 18's don't, because React 18 treats RefObject as covariant.

My package claimed "react": ">=18". For every TypeScript user on React 18, it didn't compile.

My CI had a React 18 job. It ran the test suite. But tests don't typecheck against React 18 — Vitest ran against whatever types were installed. The job was theater.

The fix was a compile-only fixture:

// test/types/consumer.tsx — never runs, just has to compile
export function PassesHookRefToCard() {
  const ref = useStackProgress<HTMLElement>({ onProgress: (p) => p.toFixed(2) });
  return <StackCard ref={ref}>first</StackCard>;
}

Plus CI that installs the matching @types/react for each React major and runs tsc. I verified it works by reverting the fix — the error came right back.

If you support a version range, prove it. Don't just declare it. ✅

✅ The 10-minute audit for your own packages

npm view your-package dependencies   # build tools in here? move them
npm view your-package keywords       # empty? nobody can find you
npm publish --dry-run                # see exactly what ships
npx publint                          # manifest correctness
npx @arethetypeswrong/cli --pack .   # TypeScript resolution
head -c 20 dist/index.js             # is "use client" actually there?

That's it. Six commands. They'd have caught all five of my bugs.

📦 Where the package landed

stack-on-scroll is now:

Zero dependencies. 4 packages install total, versus 116 before
Zero config — no stylesheet to import, styles are inline
Zero JavaScript on the default path — the stacking is pure position: sticky
Opt-in scale, fade, and tilt, all sharing one animation frame
Full TypeScript types, verified against React 18 and 19
58 tests, including ones that read the built artifact

npm install stack-on-scroll

<StackContainer offset={32} scaleStep={0.07} fadeStep={0.35}>
  {chapters.map((c) => (
    <StackCard key={c.id}>{c.title}</StackCard>
  ))}
</StackContainer>

No index prop — the container counts its own children.

🔗 Live demo with sliders for every prop
🐙 Source on GitHub

👋 About me

I'm Saad Ahmad, a freelance frontend developer. I build React and Next.js interfaces, and — as you can probably tell — I enjoy the unglamorous part: the packaging, the build config, the reason your bundle is 400KB when it should be 40.

If your team is shipping a component library, fighting a slow build, or has an npm package nobody can find, that's the kind of work I like. I'm currently open to freelance projects.

📮 isaadahmad.com

Found a bug in your own package after reading this? I'd genuinely love to hear about it in the comments — misery loves company. 😄

Building a Lightweight Dark/Light Mode System in React with use-theme-mode

Saad Ahmad — Tue, 14 Apr 2026 13:44:50 +0000

Dark mode has become a standard expectation in modern web applications. But implementing it correctly—with persistence, system preference detection, and clean separation of logic and styles—is often more complicated than it should be.

That’s exactly why I built use-theme-mode, a lightweight React hook that handles theme state for you—without enforcing any styling system.

✨ Why Another Theme Hook?

Most theme solutions today fall into one of two categories:

Too opinionated (UI framework–specific)
Too heavy for simple use cases

I wanted something that:

✅ Works with any CSS solution
✅ Persists user preference
✅ Respects system theme
✅ Is SSR‑safe
✅ Has zero runtime dependencies

That became use-theme-mode.

📦 Installation

npm install use-theme-mode

🚀 Basic Usage

import { useTheme } from "use-theme-mode";

function App() {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

That’s it. Behind the scenes, the hook:

Detects system preference
Saves the theme to localStorage
Updates the <html data-theme="..."> attribute
Syncs changes across tabs

🎨 Styling Is 100% in Your Control

use-theme-mode does not inject styles. Instead, it gives you a single source of truth via data-theme.

CSS Implementation

:root[data-theme="light"] {
  --bg-color: #ffffff;
  --text-color: #000000;
}

:root[data-theme="dark"] {
  --bg-color: #121212;
  --text-color: #ffffff;
}

body {
  background-color: var(--bg-color);
  color: var(--text-color);
  transition: background 0.3s ease, color 0.3s ease;
}

This approach works beautifully with:

Tailwind
CSS variables
Styled-components
MUI / Chakra
Vanilla CSS

🔄 Works Great with Tailwind Too

JavaScript Configuration:

// tailwind.config.js
module.exports = {
  darkMode: ["attribute", "data-theme"],
};

JSX Usage:

<div className="bg-white text-black dark:bg-black dark:text-white">
  Hello world
</div>

🌍 Live Demo

I’ve deployed a live demo showcasing:

Real theme switching
Persistent state
Code examples synced with UI

👉 View Live Demo

🧩 API Reference

const { theme, toggleTheme, setLight, setDark } = useTheme();

theme → "light" | "dark"
toggleTheme() → switch modes
setLight() → force light mode
setDark() → force dark mode

🛡️ SSR Safe & Production Ready

The hook:

Avoids direct window access during render.
Works in Next.js and other SSR frameworks.
Synchronizes changes across tabs automatically.

🔮 What’s Coming Next?

Plans for future versions:

✅ TypeScript-first API
✅ Optional context provider
✅ ESM build support
✅ Custom storage keys

🔗 Links

npm: use-theme-mode
GitHub: saadahmad888/use-theme-mode
Live Demo: Vercel Demo

If you find this useful, I’d love feedback or contributions!

Digging Deep into the Core of Frontend Development

Saad Ahmad — Sat, 08 Mar 2025 14:35:15 +0000

Frontend development is more than just writing HTML, CSS, and JavaScript. It’s about creating seamless user experiences, ensuring performance, and writing maintainable code. If you truly want to master frontend development, you need to dig deep into its core concepts.

1. HTML - The Backbone

HTML (HyperText Markup Language) structures the web. Understanding semantic HTML is crucial for accessibility and SEO. Don't just use <div> for everything; use <article>, <section>, <header>, and <footer> where appropriate.

2. CSS - The Art of Styling

CSS (Cascading Style Sheets) is what makes the web beautiful. Mastering:

Flexbox & Grid for layout
Variables for maintainability
Transitions & animations for better UX
Responsive design techniques

will help you create pixel-perfect designs.

3. JavaScript - The Brain

JavaScript brings life to your UI. Core concepts to master:

ES6+ features (let, const, arrow functions, destructuring)
DOM Manipulation
Event Handling
Fetch API & Async/Await
Functional Programming principles

4. Frameworks & Libraries

While JavaScript is powerful, frameworks like React, Vue, or Angular make development faster and more scalable. For React.js enthusiasts, understanding Hooks, Context API, and performance optimizations is key.

5. State Management

State management is the heart of modern web apps. Whether you use React’s Context API, Redux, Zustand, or Recoil, understanding state flow and performance optimization will set you apart.

6. Performance Optimization

A fast website means a better user experience. Optimize:

Image loading (WebP, lazy loading)
Code splitting & tree shaking
Server-side rendering (SSR) & Static Site Generation (SSG)
Caching strategies

7. Version Control (Git/GitHub)

A good frontend developer knows Git. You should be comfortable with branching, merging, rebasing, and handling pull requests. Speaking of GitHub, let’s connect! 😃

📌 Follow me on GitHub: saadahmad888

8. Testing & Debugging

Don’t just write code—test it! Get familiar with:

Console debugging
Unit testing (Jest, React Testing Library)
End-to-end testing (Cypress, Playwright)

9. Understanding APIs

Frontend isn't just UI. Learning how to consume RESTful and GraphQL APIs will help you build dynamic applications.

10. Soft Skills & Community Contribution

Being a great frontend developer is not just about coding. It’s about collaboration, problem-solving, and sharing knowledge.

🖥️ Want to see my work? Visit my portfolio: isaadahmad.com

🔥 If you're passionate about frontend and want to stay updated, let’s connect on GitHub and build something awesome together! 🚀

Drop a comment below—what's your favorite frontend concept? 😊

🚀 How AI is Revolutionizing Frontend Development 🤖

Saad Ahmad — Thu, 06 Mar 2025 10:55:19 +0000

Artificial Intelligence (AI) is transforming every industry, and frontend development is no exception. With AI-powered tools and frameworks, developers can now create faster, more efficient, and highly personalized user experiences. Let’s dive into how AI is reshaping frontend development and what it means for developers. 🛠️

1️⃣ AI-Powered Code Generation ✨

Tools like GitHub Copilot, Tabnine, and Codeium are helping developers write code faster and with fewer errors. These AI-powered assistants suggest code snippets, complete functions, and even generate entire components based on context. This not only speeds up development but also reduces cognitive load. ⚡

2️⃣ Automated UI/UX Design 🎨

AI is making UI/UX design more intuitive with tools like Figma AI and Adobe Sensei. These tools analyze user behavior and suggest design improvements, color palettes, and layouts, making it easier for developers to create visually appealing interfaces. 🖌️

3️⃣ AI for Accessibility and Responsiveness 📱

AI-driven tools can analyze websites and ensure accessibility compliance with standards like WCAG. They also help in making layouts responsive by predicting how elements should adjust for different screen sizes and devices. 🔍

4️⃣ AI-Based Testing and Debugging 🛠️

AI-powered testing frameworks like Selenium AI, TestCraft, and Applitools can automate UI testing, detect anomalies, and provide insights on how to fix them. This saves time in debugging and ensures a smooth user experience. ✅

5️⃣ Personalized User Experiences 🎯

AI enables real-time personalization based on user behavior, preferences, and interactions. Recommendation engines, dynamic content rendering, and chatbot integrations are all powered by AI to enhance user engagement. 🤝

🔮 What’s Next?

As AI continues to evolve, we can expect more intelligent automation in frontend development. From AI-generated animations to real-time code optimizations, the possibilities are endless. While AI won't replace frontend developers, it will certainly enhance their capabilities and streamline workflows. 💡

What are your thoughts on AI in frontend development? Are you using any AI-powered tools in your projects? Let’s discuss in the comments! 🚀

🚀 My Journey in Frontend Development & Building with the Community

Saad Ahmad — Thu, 13 Feb 2025 06:10:55 +0000

Hey Dev.to! 👋 I'm excited to share my journey as a frontend developer and how I keep up with the ever-evolving world of web development. From building innovative tools to engaging with the dev community, here’s my story.

🛠 Who Am I?

I'm a frontend developer passionate about crafting high-performance user interfaces with React, Next.js, and modern web technologies. I love solving problems, optimizing performance, and exploring new trends in frontend development. My journey has been fueled by curiosity, continuous learning, and a deep love for coding.

💡 Things I’m Working On:

Open-Source Projects → I maintain npm packages like stack-on-scroll, helping developers create better UI experiences.
Frontend Innovation → I’m building a Skeleton Screen Generator, making it easier for developers to create seamless loading states.
Speech-to-Text & Text-to-Speech in Urdu → I’m working on implementing this feature to enhance accessibility in apps.

🔥 Staying Updated with Frontend Trends

Frontend development is always changing! Here’s how I stay ahead:

✅ Exploring New Features → React Server Components (RSC), Next.js advancements, and modern UI patterns.

✅ Experimenting with Tech → Trying new tools and frameworks to build better web apps.

✅ Engaging in the Dev Community → Writing blogs, sharing knowledge, and connecting with like-minded developers.

🏗 How I Build & Share

One of my goals is to share my knowledge with others. Writing blogs, building open-source tools, and contributing to the dev community help me grow as a developer.

✍️ Topics I Write About:

Modern Frontend Trends → React, Next.js, and emerging frameworks.
Performance Optimization → Making apps faster and more efficient.
Developer Tools & Productivity → Tips and tricks for better frontend development.

🚀 Let’s Connect & Grow Together!

I’d love to hear from you! Whether it's discussing frontend trends, performance hacks, or open-source projects, let’s build together. Drop a comment, share your thoughts, or connect with me on isaadahmad.com.