DEV Community: Supreet Pradhan

Your App Is Open in 5 Tabs Right Now. Does It Know That?

Supreet Pradhan — Fri, 14 Aug 2026 14:30:08 +0000

A few months ago I was working on an app where users manage playlists, the kind of thing where people naturally end up with three or four tabs open without thinking about it.

A user added a track to a playlist in one tab, switched to another tab with that same playlist open, and it just wasn't there. Refresh, and it shows up. No refresh, and that tab has no idea anything happened.

It wasn't really a bug. The code did exactly what I told it to. I'd just built the app assuming there was only ever one tab. The moment there were two, neither knew the other existed.

That sent me down a rabbit hole: how do tabs of the same app actually talk to each other? Turns out the playlist thing was just one symptom of a bigger pattern. A cart that doesn't update in another tab. A user logged out in one tab but not another. A background job running five times instead of once.

Here's what I found.

Tabs are more isolated than you'd think

Each one is its own separate JavaScript world. They share cookies and localStorage, but nothing pushes a change from one tab to another automatically. If you want two tabs of the same app to know about each other, you have to build that connection on purpose.

The tool that ended up solving this for me was something called BroadcastChannel. It's a small, quietly powerful browser API that lets any tab shout a message that every other open tab of the same app can hear. No server involved, no polling, nothing fancy on the backend.

const channel = new BroadcastChannel('playlist-updates');

// In the tab where the track was added
channel.postMessage({ type: 'track-added', playlistId, track });

// In every other open tab
channel.onmessage = (event) => {
  if (event.data.type === 'track-added') {
    addTrackToLocalState(event.data.playlistId, event.data.track);
  }
};

That's genuinely most of it. The moment I added this, the second tab started picking up changes the instant they happened in the first one. No refresh, no waiting.

The other place this showed up: logging out

Once I understood the pattern, I noticed a second, more serious version of the same problem. Logging out. A user logs out in one tab, but the others don't know, and they just keep sitting there looking logged in.

The fix was the same idea, just for a different event.

// When the user logs out in this tab
authChannel.postMessage({ type: 'logout' });

// Every other tab
authChannel.onmessage = (event) => {
  if (event.data.type === 'logout') {
    clearLocalSession();
    redirectToLogin();
  }
};

Same channel concept, same "tell the others what just happened" idea.

What else I found along the way

Digging into this opened up a couple of other things I hadn't come across before, even though I'd been writing frontend code for a while.

One was the Web Locks API. It solves a slightly different problem: instead of telling every tab about something, it lets you make sure only one tab does something at a time. Say your app keeps a single live connection open for updates. You don't want six tabs each opening their own. Web Locks lets tabs "compete" for a lock, one of them wins and does the job, and if that tab closes, another one just picks it up automatically. No manual bookkeeping, no polling to check who's still alive.

The other was realizing BroadcastChannel isn't the only option, just the one that fit my case best. There's also the older storage event, which fires on other tabs when localStorage changes, useful if you want something that's more of a side effect than a deliberate message. And SharedWorker, which is a whole separate background script that every tab connects to, handy when you want one shared brain instead of duplicated logic per tab.

What stuck with me most, though, wasn't any specific API. It was realizing how much of the code I write quietly assumes it's the only tab in the room, when in practice, users never really work that way😂

Elevate Your Code Quality with Husky

Supreet Pradhan — Sat, 28 Feb 2026 19:01:44 +0000

In modern software development, maintaining code quality isn't just a nice to have it's a essential. As teams grow and codebases expand, ensuring consistent code standards, preventing bugs, and maintaining a clean commit history becomes increasingly challenging. Enter Husky, a powerful tool that acts as your project's quality gatekeeper by leveraging Git hooks.

Setting Up Husky

Installation

First, let's install Husky in your project:

npm install --save-dev husky
npx husky init

This creates a .husky directory in your project root with a sample pre-commit hook. Unlike the old .git/hooks directory, this folder is version-controlled and shared with your team.

Basic Configuration

After initialization, you'll have a structure like this:

your-project/
├── .husky/
│   ├── pre-commit
│   ├── pre-push
│   └── commit-msg
├── package.json
└── ...

Each file in .husky corresponds to a Git hook.

Building Your Quality Automation Stack

1. Prettier: Consistent Code Formatting

Prettier is an opinionated code formatter that enforces consistent style across your codebase. No more debates about tabs vs. spaces or where to place semicolons.

Installation:

npm install --save-dev prettier

Configuration (.prettierrc):

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}

Integrate with Husky:

Create or update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx prettier --write --ignore-unknown "**/*"

Now every commit will be automatically formatted!

2. ESLint: Catch Bugs Before They Happen

ESLint analyzes your JavaScript/TypeScript code for potential errors, bad practices, and style violations.

Installation:

npm install --save-dev eslint
npx eslint --init

Sample Configuration (.eslintrc.json):

{
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {
    "no-console": "warn",
    "no-unused-vars": "error",
    "prefer-const": "error"
  }
}

Integrate with Husky:

Update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# Run ESLint on staged files
npx eslint . --ext .js,.jsx,.ts,.tsx --fix

# Run Prettier
npx prettier --write --ignore-unknown "**/*"

# Stage any fixes
git add -A

3. lint-staged: Optimize Your Workflow

Running linters on your entire codebase before every commit is slow and unnecessary. lint-staged runs linters only on staged files, dramatically improving performance.

Installation:

npm install --save-dev lint-staged

Configuration (in package.json):

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,css,scss,md}": [
      "prettier --write"
    ]
  }
}

Update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged

This is the sweet spot: fast, efficient, and only touches relevant files.

4. TypeScript Type Checking

For TypeScript projects, add type checking to your pre-commit hook:

{
  "lint-staged": {
    "*.{ts,tsx}": [
      "tsc --noEmit",
      "eslint --fix",
      "prettier --write"
    ]
  }
}

Conclusion

Husky and automated quality checks aren't about being pedantic, they're about making your team more efficient, your code more reliable, and your releases more confident. By catching issues early, you shift quality left in your development process, reducing bugs, improving collaboration, and ultimately shipping better software.

The initial setup might seem like extra work, but the return on investment is immediate. Your team will spend less time in code review bike-shedding about formatting, less time debugging preventable issues, and more time building features that matter.

Start small, add tools incrementally, and watch your code quality and team productivity soar.

Why Custom Icon Fonts are the Ultimate Lightweight Icon Strategy

Supreet Pradhan — Fri, 27 Feb 2026 19:20:06 +0000

Modern best practice leans heavily toward SVG. They’re flexible, accessible, powerful and in many cases they’re absolutely the right choice.

But here’s the thing.

Sometimes you don’t need power.

You need simplicity.

You don’t need:

A full icon library
A component abstraction
A build-time SVG loader
Dozens (or hundreds) of unused icons in your bundle

You just need:

<span class="icon-search"></span>

When Icon Fonts Are Actually the Simpler Choice

For small UI icon sets especially in server-rendered or static projects, a single .woff2 file + one CSS file can be simpler and smaller than pulling in an SVG library.

Fonts are:

Aggressively cached by browsers
Pure CSS (no JavaScript required)
Naturally scalable
Text-like by default (inherit size and color automatically)

Instead of importing a large icon package, a minimal SVG → font pipeline can be set up using Node.js.

No frameworks.
No bundlers.
Just a small build script and a folder of SVGs.

Let’s break it down.

The Stack

Node.js (ESM, "type": "module")
svgtofont — the library that does the heavy lifting

npm install svgtofont --save-dev

Project Structure

icons/             ← drop your SVGs here
dist/              ← generated font + CSS lands here
scripts/
  build-icons.mjs  ← the build script
package.json

The Build Script

This is the entirety of scripts/build-icons.mjs:

import svgtofont from 'svgtofont';
import path from 'path';
import fs from 'fs';

const rootDir = process.cwd();

const ICONS_DIR = path.resolve(rootDir, 'icons');
const DIST_DIR = path.resolve(rootDir, 'dist');
const FONT_NAME = 'icons';

async function build() {
  await svgtofont({
    src: ICONS_DIR,
    dist: DIST_DIR,
    fontName: FONT_NAME,
    classNamePrefix: 'icon',   // ← generates .icon-search, .icon-cart, etc.
    css: true,                  // ← auto-generate the CSS file
    outSVGPath: false,
    generateInfoData: false,
    website: null,
    emptyDist: true,            // ← clear dist before each build
    startUnicode: 0xe001,       // ← start in the Private Use Area (PUA)
  });

  // svgtofont outputs some extra files we don't need — clean them up
  const allowed = ['.ttf', '.woff', '.woff2', '.css'];
  fs.readdirSync(DIST_DIR).forEach((file) => {
    if (!allowed.some((ext) => file.endsWith(ext))) {
      fs.unlinkSync(path.join(DIST_DIR, file));
    }
  });

  console.log('✅ Icons built successfully.');
}

build().catch(console.error);

Wire it up in package.json:

{
  "type": "module",
  "scripts": {
    "build:icons": "node scripts/build-icons.mjs"
  }
}

Run it:

npm run build:icons

Output in dist/:

dist/
  icons.css
  icons.ttf
  icons.woff
  icons.woff2

What Gets Generated

The icons.css looks like this:

@font-face {
  font-family: "icons";
  src: url('icons.woff2') format('woff2'),
       url('icons.woff')  format('woff'),
       url('icons.ttf')   format('truetype');
}

[class^="icon-"], [class*=" icon-"] {
  font-family: 'icons' !important;
  font-style: normal;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

.icon-cart-shopping::before { content: "\e001"; }
.icon-eye::before           { content: "\e002"; }
.icon-facebook::before      { content: "\e003"; }
.icon-house::before         { content: "\e004"; }
.icon-plus::before          { content: "\e005"; }
.icon-volume::before        { content: "\e006"; }

Each icon name maps directly to the SVG filename (without extension). The ::before pseudo-element injects the glyph via a Unicode codepoint in the Private Use Area — same technique Font Awesome uses.

Using It in HTML

<link rel="stylesheet" href="./dist/icons.css" />

<span class="icon-search"></span>
<span class="icon-cart-shopping"></span>

Sizing and coloring works exactly like text:

.icon-search {
  font-size: 24px;
  color: #6152e8;
}

Used correctly, an SVG icon and a generated font icon can look visually identical in the UI. The difference is not in appearance, but in delivery — a single cached font file can sometimes be simpler and lighter than managing multiple inline SVGs.

Wrapping Up

The whole thing is about 35 lines of JavaScript.

It’s also important to use clean SVG files with a proper viewBox, simple path elements, and no embedded images. If you’re working with outline-style icons, convert strokes into filled outlines before generating the font.

Custom icon fonts are not a replacement for SVG in every situation. But for small, controlled icon sets in static or server-rendered projects, they can be a very lightweight, cache-friendly, and dependency-free solution.

The full source code GitHub

References -
Icons sourced from Font Awesome
icon-font vs svg Blog
The Developer's Guide to Icons: Icon Fonts vs. SVGs Blog

How to Use Markdown Files to Orchestrate Multi-File Changes in GitHub Copilot

Supreet Pradhan — Mon, 16 Feb 2026 19:37:24 +0000

AI-assisted coding is everywhere. Tools are fast, accessible, and can turn a simple prompt into working code in seconds.

But anyone using AI seriously for development knows the pattern:

You ask for code
You clarify intent
You fix structure

Back and forth. Each iteration consumes time. And time is a finite resource.

If AI usage becomes more metered in the future, per prompt, per token, per request, then clarity becomes critical. Every vague instruction has a cost.

This is where structured prompting inside the codebase, especially with GitHub Copilot, becomes a serious productivity multiplier.

The Problem: Repetitive Multi-File Changes

In real-world projects, features rarely touch just one file.

Adding something small like a new filter or API integration often requires:

Updating types
Modifying API services
Updating hooks
Changing state management
Adjusting UI components
Possibly updating pages
Maybe touching tests

That is easily 6–8 files for a "minor" feature. Doing this manually is repetitive; doing it via casual chat is fragmented. The issue isn’t AI capability; it’s a lack of structure and context.

The Solution: Structured Markdown Prompting

Instead of typing ad-hoc instructions into the chat sidebar, define your requirements inside the repository using Markdown files. This creates a "blueprint" that Copilot can use to orchestrate changes across the workspace.

Step 1 — Define the Project Source of Truth

Create a Project DNA file to serve as the source of truth for your codebase. By explicitly defining your tech stack, folder hierarchy, and architectural boundaries, you eliminate 'AI guesswork' and ensure Copilot respects your specific design patterns from the very first line

Locations : docs/PROJECT_CONFIGS.md

Example:

Step 2 — Create Workflow Blueprints

For specific, repetitive tasks, create targeted instruction files.

Example: docs/workflows/API_SERVICE.md
Describe exactly how a service should be built: where it lives, how it handles errors, and what the import order should be.

Step 3 — Orchestrating with the Coding Agent

This Is Where the Magic Happens. Instead of using the standard chat, switch to the GitHub Copilot Coding Agent and select a high-reasoning model like Claude 3.5 Sonnet or Claude 4.5 (if available in your tier).

Don’t waste time with long paragraphs. Since you’ve already defined your “Blueprints” in Step 2, your interaction becomes a clean, command-style instruction.

Attach Context

Add your project-config.md and relevant source files to the chat context.
Issue the Command

Use a concise prompt that references your workflow file:

/new service LoginService - Follow rules in docs/workflows/service.md

Step 4 — Controlled, Multi-File Output

While standard chat provides snippets you have to manually copy-paste, the Agentic Workflow handles the heavy lifting by natively generating and placing files directly into your codebase.

A new types file
A new service file
Correct imports
Strict typing
Proper folder placement
No UI logic leakage
Everything aligned with the existing project conventions defined in Markdown

Conclusion

GitHub Copilot performs significantly better when:

Context is explicit
Conventions are documented
Scope is clearly defined
Architecture rules are enforced

Markdown becomes a lightweight contract between the developer and the AI.

My GitHub Repo for the Project

External Links :