DEV Community: Sachin Kasana

I Stopped Using Online Diff Checkers and JWT Tools Blindly. Here’s Why I Built My Own

Sachin Kasana — Thu, 29 Jan 2026 12:44:40 +0000

At some point, I realized I was pasting sensitive production data into tools I knew nothing about.

Every day, we use online developer tools like:

diff checkers
JWT decoders
JSON formatters

They’re part of normal backend and frontend workflows. You Google one, open the first result, paste your data, get the output, and move on.

But when you slow down and think about it, a lot of these tools deal with sensitive information:

JWTs with user IDs, emails, and roles
production configs and environment values
feature flags and API responses
code snippets during reviews and debugging

Most online dev tools don’t clearly say:

whether your input is processed on the server

whether it’s logged or stored
how long it’s retained
That uncertainty started to bother me.

Diff checkers and JWT decoders are used more than we admit

Two tools really pushed me to rethink this.

Diff Checker
I use diff checkers constantly during code reviews and debugging. It’s common to paste two versions of configs or logic that are close to production. Doing that on a random website never felt great.

JWT Decoder
JWT tokens often contain more personal or internal data than expected. Decoding them using an unknown online service is a quiet risk most of us accept without questioning.

These tools are essential, but trust matters when you’re using them daily.

What I wanted from a developer utility tool

I wasn’t trying to build a product. I just wanted a developer utility site I could trust.

A few non-negotiables:

100% browser-side execution
no backend or API calls
no ads or popups
no accounts or logins

If I paste a JWT or compare two files, that data should never leave my machine.

Why browser-only tools matter
With browser-based dev tools:
your data stays local
nothing is sent to a server
there’s no ambiguity about storage

This is especially important for:

JWT decoding
diff checking configs
formatting API responses
It’s simple, predictable, and safer by default.

So I built a small set of tools for daily use

I ended up building a clean set of privacy-first developer tools that run entirely in the browser. No tracking, no analytics surprises, and no ads.

I now use it daily for:

diff checking
JWT decoding
quick JSON formatting

Eventually, I realized other developers might want the same thing, so I put it online.

I’m curious how others approach this

I’m not saying everyone should stop using existing tools. I’m genuinely curious:

Do you think about privacy when using online dev tools?

Do you prefer browser-only tools or self-hosted ones?

Are there developer utilities you use daily that feel overcomplicated or risky?

I’ve dropped the link in the comments to keep the post clean.

Would love to hear how others handle this.

Production-Grade System Design in Node.js (2025): 20 Concepts Every Developer Should Master

Sachin Kasana — Sat, 01 Nov 2025 07:45:05 +0000

“Scaling isn’t a feature — it’s survival.”

Continue reading on JavaScript in Plain English »

13 Modern Node.js Features That Made Popular npm Packages Obsolete (with Real Use Cases)

Sachin Kasana — Sat, 11 Oct 2025 12:30:46 +0000

The Node.js ecosystem has grown up

Continue reading on JavaScript in Plain English »

️ 10 Node.js Security Best Practices You Shouldn’t Ignore in 2025

Sachin Kasana — Fri, 29 Aug 2025 16:27:18 +0000

Node.js powers everything from hobby projects to mission-critical enterprise apps. But in 2025, the attack surface is bigger than ever —…

Continue reading on JavaScript in Plain English »

Production-Grade Node.js Permission Model: Lock Down Your Runtime

Sachin Kasana — Sun, 27 Jul 2025 03:56:59 +0000

Use Node.js 24’s new permission model to secure your backend apps. Learn to lock down filesystem, environment, and network access — no…

Continue reading on JavaScript in Plain English »

Node.js 24 vs 22 in 2025: What’s New, What Breaks, and How to Upgrade Safely

Sachin Kasana — Sat, 26 Jul 2025 14:05:09 +0000

Node 18 is EOL. Node 22 is stable, but Node 24 has next-gen features. Should you wait or upgrade now? This guide breaks it down for devs…

Continue reading on JavaScript in Plain English »

Retry Logic in Node.js: How to Handle Flaky APIs Without Losing Your Mind

Sachin Kasana — Tue, 24 Jun 2025 17:06:57 +0000

“We’ve all been there. Your Node.js app talks to a payment gateway or third-party API, and everything works… until it doesn’t. One network hiccup, and your app fails hard.”

Real Problem:

External APIs might:
Rate-limit you
Drop connections randomly
Throw 500s under load
A retry mechanism can prevent unnecessary app failures.

💥 Naive Retry Example (Don’t Do This)

function fetchWithRetry(url, attempts = 3) {
  return fetch(url).catch(err => {
    if (attempts <= 1) throw err;
    return fetchWithRetry(url, attempts - 1);
  });
}

What’s wrong here?

No delay between retries.
Immediate hammering worsens server load.
No distinction between fatal vs retryable errors.

🧠 Retry Best Practices

🔧 Using axios-retry (Easiest)

 npm install axios axios-retry

const axios = require('axios');
const axiosRetry = require('axios-retry');

axiosRetry(axios, {
  retries: 3,
  retryDelay: axiosRetry.exponentialDelay,
  retryCondition: (error) => {
    return error.response?.status >= 500 || error.code === 'ECONNABORTED';
  }
});

axios.get('https://flaky.api.com/data')
  .then(res => console.log(res.data))
  .catch(err => console.error('Request failed after retries', err));

🛠 Using p-retry for Custom Logic

npm install p-retry

const pRetry = require('p-retry');
const fetch = require('node-fetch');

const fetchData = async () => {
  const res = await fetch('https://unstable-api.com/data');
  if (!res.ok) throw new Error(`Status: ${res.status}`);
  return res.json();
};

pRetry(fetchData, {
  retries: 5,
  onFailedAttempt: error => {
    console.log(`Attempt ${error.attemptNumber} failed. There are ${error.retriesLeft} retries left.`);
  }
}).then(console.log).catch(console.error);

⚠️ Retry-Aware Design

Always use idempotent methods (GET, PUT) for retries.
POST requests can cause duplicate side effects if retried without safeguards (e.g., charge twice).

💬 Logging and Monitoring

onFailedAttempt: error => {
  log.warn({
    attempt: error.attemptNumber,
    message: error.message
  });
}

Helps in debugging production failures.

📦 Bonus: Retry with Queues (Bull/Agenda)

For longer retry flows:

Use bull (Redis-based job queue) to retry in background.
Useful for payment retries, webhook delivery, etc.

🔚 Conclusion

“Retries are like seatbelts for your API calls. You hope you don’t need them — but when you do, they can save your system from disaster.”

Encourage readers to:

Use libraries, not reinvent the wheel.
Always handle retries thoughtfully , not blindly.

Optional Enhancements

Retry + Circuit Breaker (use opossum)
Retry + Metrics for success/failure tracking
Custom retry decorator function

I’m Sachin Kasana — Principal Engineer, full-stack enthusiast, and open-source contributor. I write practical dev blogs to make backend scaling, performance, and clean code simpler for everyone.

📬 Enjoyed this post?

Follow me on Medium for more hands-on backend, Node.js, and architecture articles every week.

REST vs GraphQL vs OData — Choosing the Right API for the Right Job

Sachin Kasana — Sat, 31 May 2025 08:23:03 +0000

REST vs GraphQL vs OData — Choosing the Right API for the Right Job

“Not every app needs GraphQL. Not every enterprise loves OData. And REST isn’t dying anytime soon.”

When building APIs, we often face a critical decision early on: REST , GraphQL , or OData?

Each shines in different scenarios — and each can become a bottleneck if misused.

In this post, we’ll break down:

✅ What REST, GraphQL, and OData really are
🧠 When to use each with real-world project examples
⚖️ Pros and cons of each style
🛠️ How to migrate between them (if you must)

🔹 1. REST — The Veteran That Still Works

Best when:

You need a simple, resource-oriented API with predictable endpoints and strong HTTP semantics.

📦 Real Project: A Marketplace API (like Etsy or Flipkart)

Imagine you’re building an API for a marketplace:

GET /products  
GET /products/:id  
POST /orders  
PUT /users/:id

This works great for:

Mobile and web clients consuming standard resource collections
Public APIs exposed to third-party developers
Systems with caching requirements

✅ Pros:

Simple to understand and implement
Easy to cache with HTTP headers
Works with any client/tool (browsers, Postman, curl, etc.)
Massive ecosystem support

❌ Cons:

Overfetching/underfetching data
Multiple calls to build complex UI views
Versioning can become messy (/v1/, /v2/)

🔧 Example: Fetching user orders

GET /users/123/orders

But now you also need product thumbnails and delivery status — either you call two more APIs or create a new endpoint. This is where REST becomes rigid.

🔹 2. GraphQL — The Frontend Developer’s Dream

Best when:

You need flexible data fetching, rapid UI iterations, or multiple nested resources in one go.

📱 Real Project: Social Networking App (like Twitter or LinkedIn)

Let’s say you’re building a feed screen that shows:

Post content
User who posted it
Comments (with commenter details)
Like counts

With REST, you’d make 3–4 calls.

With GraphQL, one query does it all:

{
  feed {
    post
    user { name avatar }
    comments {
      text
      user { name }
    }
  }
}

✅ Pros:

Clients fetch exactly what they need
Multiple resources in one request
Great introspection, schema validation, and type safety
Subscriptions for real-time updates

❌ Cons:

Caching is more complex (no native HTTP caching)
Rate limiting and query complexity need to be enforced manually
Harder for teams unfamiliar with schema-first development

⚠️ Real Pain Point:

If your API is public or used by many third-party clients, GraphQL may be overly flexible , increasing attack surface or server load.

🔹 3. OData — The Enterprise Powerhouse

Best when:

You’re building internal or enterprise-grade apps with rich relational data that needs to plug into tools like Excel , Power BI , or SAP.

🏢 Real Project: Employee Analytics Portal (like HR dashboards in Microsoft Dynamics)

Use cases:

Fetch top 10 highest-paid employees over age 40
Export filtered data to Excel or Power BI
Drill down on KPIs without writing backend logic

OData lets you do this directly:

GET /Employees?$filter=Age gt 40&$orderby=Salary desc&$top=10

✅ Pros:

Built-in filtering, sorting, pagination, and projection
Excellent integration with Microsoft/BI tools
Schema metadata is auto-generated
Great for low-code tools and reporting systems

❌ Cons:

Steeper learning curve
Verbose URLs
Less flexible for custom business logic
Not widely adopted outside Microsoft ecosystem

⚔️ Side-by-Side Comparison

🧠 TL;DR — Choose Based on the Job

✍️ Final Thoughts

You don’t have to choose one forever. Many modern platforms use a hybrid approach:

REST for external integrations
GraphQL for frontend customization
OData for reporting dashboards

The key is to pick what’s right for your clients and team — not what’s trending.

💬 Over to You

What API architecture is your team using — and why?

Have you hit performance bottlenecks or scalability walls?

Let’s chat in the comments 👇

I Replaced My Spinner with a Skeleton — And My UX Skyrocketed

Sachin Kasana — Thu, 22 May 2025 17:26:36 +0000

I Replaced My Spinner with a Skeleton — And My UX Skyrocketed 🚀

Let’s be honest. Loading spinners are the default move when your app needs a second to breathe. But here’s the problem:

Spinners tell users something is happening_. Skeletons show users_ what’s coming.

That tiny shift made a huge difference in my app’s user experience — and it took less than 10 minutes to implement.

😩 The Problem: Spinners Are Vague

A spinner feels like an empty elevator. You know you’re supposed to wait, but you have no idea for how long, where you’re going, or if it’s even working.

Case in Point: My Product Page

Here’s what I was doing:

{isLoading ? (
  <div className="spinner">Loading...</div>
) : (
  <ProductList products={data} />
)}

While it technically worked, it offered no clue about what was loading. Users just stared at a circle going in circles. 😵‍💫

💡 The Fix: Skeleton Screens

Skeleton screens are UI placeholders shaped like the content they’re loading. Instead of showing nothing (or worse, a mystery spinner), they hint at what’s coming.

Here’s the improved version:

{isLoading ? (
  <div className="skeleton-grid">
    {Array(6).fill().map((_, i) => (
      <div className="skeleton-card" key={i}></div>
    ))}
  </div>
) : (
  <ProductList products={data} />
)}

Tailwind-Style Skeleton Example:

<div className="bg-gray-200 h-40 w-full rounded-md animate-pulse"></div>

This gave users something familiar to look at — a grid of loading placeholders that resembled product cards.

📈 What Actually Improved

After swapping out spinners for skeletons, we tracked key UX metrics:

Even though the backend/API speed didn’t change, the perception of speed improved dramatically.

🧰 Tools You Can Use

Want to do this fast? Here are some options:

1. React Loading Skeleton

npm install react-loading-skeleton

import Skeleton from 'react-loading-skeleton';
<Skeleton height={40} count={6} />

2. Tailwind CSS Approach

No library needed:

<div className="h-4 w-3/4 bg-gray-300 rounded-md animate-pulse"></div>

3. Custom CSS (if you’re old school)

.skeleton-card {
  background: #ddd;
  border-radius: 6px;
  height: 120px;
  animation: pulse 1.5s infinite;
}

@keyframes pulse {
  0% { opacity: 1; }
  50% { opacity: 0.4; }
  100% { opacity: 1; }
}

🧠 Skeleton-First Design: A Better Default

Instead of loading nothing and waiting for the API to respond, I now design components to show skeletons first by default.

return (
  <div>
    {loading ? <SkeletonCard /> : <RealCard data={data} />}
  </div>
);

It’s faster. More predictable. Less jarring.

🏁 TL;DR

Spinners are vague and frustrating.
Skeletons mimic layout and improve perceived speed.
One small swap = massive UX gains.
Try it in product pages, profile cards, dashboards — anywhere content loads.

“A 500ms spinner feels slow. A 500ms skeleton feels_ fast.”_

That one line of code might just be the UX upgrade your app needs.

🚀 If this post helped you rethink your loading UX, give it a few claps 👏 to help others discover it too!

💬 Got a UI trick or frontend hack that worked wonders for you? Drop it in the comments — I’d love to learn from your experience.

🔔 Follow me here on Medium for more real-world frontend tips, performance wins, and dev insights.

👉 Connect with me on LinkedIn

🌐 Check out my projects at sachinkasana.dev

Stop Using Switch Statements — Use a Lookup Object Instead

Sachin Kasana — Sun, 18 May 2025 11:51:37 +0000

🚫 Stop Using Switch Statements — Use a Lookup Object Instead 🧠

Switch statements have been around forever. They’re familiar, readable (for small blocks), and often the first thing we reach for when branching logic is needed.

But let’s be honest — in real-world projects, they don’t scale.

As soon as your logic grows beyond 3–4 cases, switch-case blocks become:

Verbose
Repetitive
Hard to test
Painful to maintain

Let me show you a better, cleaner pattern that’s not only shorter — but also more flexible, testable, and production-friendly.

🔥 The Problem With Switch Statements

Here’s a common example I’ve seen (and written myself) far too many times:

function getRoleLabel(role) {
  switch (role) {
    case 'admin':
      return 'Administrator';
    case 'editor':
      return 'Editor';
    case 'viewer':
      return 'Viewer';
    default:
      return 'Unknown';
  }
}

Looks harmless, right?

But now imagine your roles change, your labels get translated, or you need to return icon names or color codes too. Suddenly, you’re maintaining multiple switch blocks across different files for the same mapping.

This isn’t just messy — it’s fragile.

✅ A Cleaner Alternative — The Lookup Object Pattern

Let’s rewrite that same function using a simple object map:

const roleLabels = {
  admin: 'Administrator',
  editor: 'Editor',
  viewer: 'Viewer'
};

function getRoleLabel(role) {
  return roleLabels[role] || 'Unknown';
}

That’s it. Done.

✨ Benefits:

Shorter and cleaner
Easy to add or remove values
Supports dynamic logic (load from config or CMS)
Testable in isolation

🛠 Real-World Example From a Dashboard Project

I recently worked on a React-based dashboard for managing user roles.

Instead of this:

switch (user.status) {
  case 'active':
    return '🟢 Active';
  case 'inactive':
    return '⚪ Inactive';
  case 'banned':
    return '🔴 Banned';
  default:
    return '❓ Unknown';
}

We used:

const statusEmoji = {
  active: '🟢 Active',
  inactive: '⚪ Inactive',
  banned: '🔴 Banned'
};

const getStatusLabel = (status) => statusEmoji[status] || '❓ Unknown';

This gave us centralized control , allowed product managers to tweak labels without logic changes, and made it easier to write tests like:

expect(getStatusLabel('active')).toBe('🟢 Active');

Simple. Powerful. Clean.

⚙️ Advanced Pattern: Function Lookup Tables

Let’s say you’re handling user actions on the backend using Express or on the frontend in a reducer-style function.

Instead of:

switch (action) {
  case 'login': return loginUser();
  case 'logout': return logoutUser();
  case 'signup': return signupUser();
  default: return null;
}

Use this pattern:

const actionMap = {
  login: loginUser,
  logout: logoutUser,
  signup: signupUser
};

const runAction = (type) => (actionMap[type] || (() => null))();

This makes it:

Easy to test individual handlers
Scalable for adding/removing actions
Avoids code duplication

⛔ When Not to Use This Pattern

To be clear, switch statements aren’t evil.

If each case involves radically different and unrelated logic , or needs to fall through, a switch may still be more appropriate.

But in 90% of real-world UI/logic scenarios, especially those involving mappings, enums, or configs — this pattern is a no-brainer win.

🔚 Final Thoughts

switch-case blocks served us well… back in 2015.

But in modern JavaScript codebases, they’re often a signal that something could be refactored and cleaned up.

Lookup objects are the functional, testable, and elegant way forward.

They help you:

Centralize logic
Improve maintainability
Write cleaner code with fewer bugs

So next time you’re about to write a switch — ask yourself:

Can this be a map instead?

🙌 Bonus Tip

This pattern pairs beautifully with:

Internationalization (i18n)
Theme-based UI mapping
Role-based access control (RBAC)
Feature toggles

📣 Like This Pattern? Here’s More

I regularly share JavaScript patterns, clean code tricks, and real-world dev insights.

👉 Visit sachinkasana-dev.vercel.app for more.

💬 Or connect with me on LinkedIn for weekly developer tips!

How Node.js Handles High Concurrency Without Threads (And Why It Still Blocks Sometimes)

Sachin Kasana — Thu, 15 May 2025 13:21:18 +0000

“If Node.js is single-threaded, how the heck is it serving millions of users?” That’s one of the first questions senior developers ask in high-level Node.js interviews — and rightly so.

In this post, we’ll break down how Node.js manages concurrency like a pro without native threads, why your app might still get stuck, and how to architect your real projects to avoid bottlenecks.

🧠 TL;DR (For The Busy Devs)

Node.js uses a single-threaded event loop for JavaScript execution.
Behind the scenes, it leverages libuv’s thread pool to handle non-blocking I/O.
It can still block — especially with CPU-heavy or synchronous code like JSON parsing, crypto, image processing.
Use worker threads or queues to stay performant at scale.

🚦 Concurrency in Node.js: Not What You Think

You’ve probably heard:

“Node.js is single-threaded.”

That’s half-true.

✅ JavaScript execution = single-threaded

✅ Underlying I/O work = concurrent

Node uses libuv (a C++ library) to handle:

Event loop management
Async I/O scheduling
A built-in thread pool (default: 4 threads)

🍽 Real-World Analogy: The Restaurant

JavaScript is the waiter — taking one order at a time.
libuv’s thread pool is the kitchen — cooking many dishes in parallel.
Your user is happy — the server’s still taking new orders even when their meal is being prepared.

🧪 Real Project Problem: CSV Uploads Killing Performance

Let’s say you built a simple API to:

Accept a CSV upload
Parse it
Store the data in MongoDB

Here’s the problematic version :

app.post('/upload', async (req, res) => {
  const rows = parseCSV(req.file.buffer); // Synchronous, blocks event loop
  await saveToDB(rows);
  res.send("Upload complete");
});

Now imagine 10 users hit this at once. Your Node server is stuck parsing the first CSV — the rest have to wait.

😱 Result: High latency or even dropped connections.

✅ Fixing It with Worker Threads

The solution: move CPU-heavy tasks like parsing to a worker thread.

// worker.js
const { parentPort, workerData } = require('worker_threads');
const parsed = parseCSV(workerData.buffer); // Your actual parser here
parentPort.postMessage(parsed);

// main.js
const { Worker } = require('worker_threads');

function parseCSVInWorker(buffer) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./worker.js', { workerData: { buffer } });
    worker.on('message', resolve);
    worker.on('error', reject);
  });
}

Now your API becomes:

app.post('/upload', async (req, res) => {
  const rows = await parseCSVInWorker(req.file.buffer); // Non-blocking now!
  await saveToDB(rows);
  res.send("Upload complete");
});

✅ Result: 10 users upload CSVs concurrently without blocking.

Now your main thread stays responsive. 1,000 users can upload CSVs without stepping on each other.

🧨 Common Blocking Traps in Real Node Apps

🧠 Deep Dive: Node’s Thread Pool in Action

Want proof that Node is not entirely single-threaded?

const crypto = require('crypto');
const start = Date.now();

for (let i = 0; i < 5; i++) {
  crypto.pbkdf2('pass', 'salt', 100000, 64, 'sha512', () => {
    console.log(`Done in`, Date.now() - start, 'ms');
  });
}

Output:

First 4 run in parallel (libuv thread pool).

The 5th waits until a thread is free. Concurrency in action.

🛡 Production-Proven Advice for Senior Devs

✅ Use async/await or Promise-based APIs

✅ Move CPU tasks to worker_threads

✅ Don’t trust "it’s async" — test it under load

✅ Use tools like clinic.js, autocannon, wrk to profile

✅ Monitor event loop lag using event-loop-delay or prom-client

🧑‍💻 Interview Bonus

❓ “How would you scale a Node.js service that does image resizing + file I/O?”

Answer:

File I/O stays async
Move image resizing to worker threads or delegate to an external service (e.g. Lambda, FFmpeg server)

🧩 Final Thoughts

Node.js is fast — when you use it right.

It’s not meant to run CPU-heavy jobs in the main thread. Once you understand the event loop + libuv combo , you’ll be able to design highly scalable, performant services.

“Don’t block the loop. Respect the event loop.”

🙌 Enjoyed the post?

If this helped you think differently about performance in JavaScript apps, drop a 👏 or leave a comment — I’d love to hear what you’re building or struggling with!

🧑‍💻 Check out more dev tools & blogs I’m working on:

📁 Portfolio → https://sachinkasana-dev.vercel.app

🔧 JSON Formatter Tool → https://json-formatter-web.vercel.app

Let’s keep making the web faster — one main thread at a time. 🚀

Thank you for being a part of the community

Before you go:

Be sure to clap and follow the writer ️👏 ️️
Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Differ | Twitch
Start your own free AI-powered blog on Differ 🚀
Join our content creators community on Discord 🧑🏻‍💻
For more content, visit plainenglish.io + stackademic.com

How Web Workers Saved My JavaScript App from Freezing on Every CSV Upload

Sachin Kasana — Tue, 13 May 2025 16:48:17 +0000

A real-world performance fix that made my app usable again.

Ever uploaded a file and watched your app turn into a brick?

That’s what was happening in my dashboard app — a CSV visualizer that lets users upload massive spreadsheets, crunch the data, and generate real-time stats + charts.

It was working great… until people started uploading actual real-world CSVs.

1 MB? Fine.
5 MB? Kinda slow.
20 MB? 🧊 Frozen UI. Zero response.

You clicked a button? Nothing.

Tried to scroll? Good luck.

Even the loader stopped spinning because… JavaScript was busy choking.

💡 Where It Went Wrong

JavaScript runs on a single thread.

That means any heavy CPU work (like parsing and summarizing CSV data) blocks everything else — buttons, scroll, animations, even paint.

I tried async/await. I tried debouncing. I tried optimizing my code like a maniac.

But the real problem?

My app was asking the main thread to do everything.

⚙️ What Was Happening Behind the Scenes

Every time a CSV was uploaded, I was doing this:

const reader = new FileReader();
reader.onload = (e) => {
  const text = e.target.result;
  const rows = parseCSV(text); // heavy loop!
  const stats = generateStats(rows); // CPU-heavy
  renderDashboard(stats); // React state update
};
reader.readAsText(file);

Looks simple — but parseCSV and generateStats were brutal on big files.

React choked. The browser hung. The UI stopped responding.

🔥 Enter Web Workers

I needed a way to move all that heavy lifting off the main thread.

That’s where Web Workers come in — basically background threads for JavaScript.

They can’t touch the DOM, but they can do all the grunt work without blocking your UI.

🛠️ Step-by-Step: How I Refactored with Web Workers

📁 Create a worker file

// csvWorker.js
self.onmessage = function (event) {
  const csvText = event.data;
  const rows = parseCSV(csvText); // custom parser
  const stats = generateStats(rows); // summary metrics
  self.postMessage(stats);
};

📥 Send work from your app

// inside App.jsx
const worker = new Worker(new URL('./csvWorker.js', import.meta.url), { type: 'module' });

worker.postMessage(csvText);

worker.onmessage = (e) => {
  const stats = e.data;
  setDashboardData(stats); // back on the main thread
};

Boom. 🎯

The UI no longer froze. The spinner kept spinning. And users could scroll and click freely — even with 30MB CSVs uploading in the background.

🎉 The Results

Before Web Workers:

App froze for 3–5 seconds on every upload
Some browsers showed “Page is unresponsive” warnings
Rage-quits happened

After Web Workers:

Smooth, non-blocking experience
UI stays interactive while CSV is being parsed
Feels like a native desktop app now

🧠 Lessons I Learned

Web Workers are wildly underused. Especially for apps that deal with data-heavy processing.
They’re not hard to set up. Especially with modern tooling (Vite, Webpack, etc. support importing worker files natively).
You can’t share variables between threads. Use postMessage to send and receive data — no shared memory.
They work great with React. Just don’t try to touch DOM or React state inside the worker.

🔚 Final Thoughts

If your JavaScript app feels sluggish during file uploads, data crunching, or image processing — don’t blame React.

Blame the main thread.

Then give it a break — and let a Web Worker do the dirty work.

They’re not the most glamorous tool in the toolbox, but they might just save your app from performance hell.

🙌 Enjoyed the post?

If this helped you think differently about performance in JavaScript apps, drop a 👏 or leave a comment — I’d love to hear what you’re building or struggling with!

🧑‍💻 Check out more dev tools & blogs I’m working on:

📁 Portfolio → https://sachinkasana-dev.vercel.app

🔧 JSON Formatter Tool → https://json-formatter-web.vercel.app

Let’s keep making the web faster — one main thread at a time. 🚀

Thank you for being a part of the community

Before you go:

Be sure to clap and follow the writer ️👏 ️️
Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Differ | Twitch
Start your own free AI-powered blog on Differ 🚀
Join our content creators community on Discord 🧑🏻‍💻
For more content, visit plainenglish.io + stackademic.com