DEV Community: Mohammad Rajaei Monfared

Are AI-Generated Videos Rewriting Our Understanding of Physics?

Mohammad Rajaei Monfared — Sun, 26 Jul 2026 12:20:11 +0000

How synthetic reality may influence human intuition about motion, gravity, and causality

AI video generation has reached a point where a model can create scenes that look physically convincing at first glance:

A person jumping impossible distances
Objects moving without inertia
Water flowing upward
Animals performing human-like actions
Buildings bending like rubber
People interacting with impossible environments

For decades, humans learned physics by observing the real world.

A ball falls.
A glass breaks.
A person cannot walk through a wall.
Heavy objects require more force to move.

These observations create what cognitive scientists call intuitive physics: an internal mental model that predicts how objects should behave.

But what happens when the majority of visual experiences become synthetic?

Could AI-generated videos slowly change how future generations perceive reality?

Humans Do Not See Reality Directly

A common misconception is that our brain works like a camera:

Reality → Eyes → Brain → Understanding

The actual process is closer to:

Reality
   ↓
Sensory input
   ↓
Brain prediction model
   ↓
Perception

The brain is constantly predicting what should happen next.

When you see a ball thrown into the air, your brain automatically predicts:

trajectory
speed
gravity
collision point
acceleration

This happens before conscious reasoning.

This capability is known as predictive processing.

Your brain is not only asking:

"What am I seeing?"

It is also asking:

"Does this match my internal model of how the world works?"

The Brain Learns Physics From Experience

Young children do not learn physics from equations.

They learn by interaction.

A baby discovers:

Objects continue to exist when hidden
Unsupported objects fall
Solid objects cannot overlap
Larger objects require more effort to move

Researchers call these abilities core knowledge systems.

Humans appear to have an innate expectation that the physical world follows consistent rules.

For example:

A child watching a ball roll behind a box expects it to continue moving.

A child watching a video where a ball disappears and appears somewhere else recognizes something is unusual.

The brain has a physics simulator.

What Changes When Videos Become Physically Incorrect?

Imagine a child growing up with thousands of hours of AI-generated videos.

Many videos may contain:

impossible acceleration
incorrect gravity
unrealistic collisions
objects changing shape
characters violating biomechanics

Does the brain update its physics model?

The answer is:

Probably yes, but not in a simple way.

The human brain is highly adaptable.

It constantly adjusts based on experience.

For example:

Pilots

Pilots who use flight simulators develop new perceptual abilities.

Their brains adapt to:

unusual movement
instrument-based navigation
artificial visual environments

Gamers

People who play first-person games become better at:

spatial reasoning
predicting movement
controlling virtual cameras

The brain can learn artificial environments.

But There Is an Important Difference

Games and simulations usually have:

consistent fake physics

AI-generated videos may have:

inconsistent fake physics

This difference matters.

A game creates a new rule system:

World A:
Gravity = 9.8 m/s²
Collision = consistent
Movement = predictable

Your brain learns:

"This world has different rules."

But AI-generated videos may show:

Video 1:
Gravity exists

Video 2:
Gravity disappears

Video 3:
Objects move backward in time

Video 4:
Humans stretch like cartoons

The problem is not artificial reality.

The problem is unstable reality.

The Same Question Was Asked About Cartoons

This is not the first time humans have worried about artificial representations.

Cartoons have shown impossible physics for more than a century.

Examples:

Characters surviving explosions
Objects stretching
Gravity stopping until someone notices
Characters falling after realizing they are in the air

Yet most people do not believe these things happen.

Why?

Because humans categorize information.

The brain understands:

Cartoon world ≠ Real world

The concern with AI-generated video is different:

AI video ≈ Real video

The boundary becomes less obvious.

The New Problem: Loss of Reality Labels

Historically, humans had strong signals:

Real:

camera imperfections
physical limitations
consistent lighting
natural motion

Fake:

animation style
obvious CGI
unrealistic rendering

Modern AI video reduces this gap.

A generated video may look like:

Real camera
+
Real person
+
Real environment
+
Impossible physics

The viewer receives conflicting information:

Visual realism says:

"This happened."

Physics intuition says:

"This cannot happen."

Could This Affect Future Generations?

A realistic scenario:

A child sees thousands of AI-generated videos before having enough real-world experience.

Their visual dataset becomes:

Internet videos:
    70% synthetic
    30% real

Their brain learns statistical patterns from this environment.

Modern AI systems work similarly.

A neural network learns from data distribution.

Humans also learn from experience distribution.

However, humans have additional sources:

physical interaction
social correction
scientific education
personal experience

Touching a falling object is stronger evidence than watching 10,000 videos.

The Bigger Risk Is Not Physics — It Is Trust

The most significant cognitive impact may not be:

"People believe impossible physics."

It may be:

"People stop knowing what evidence to trust."

AI-generated videos challenge our assumption:

Seeing = knowing

For thousands of years:

"I saw it happen" was strong evidence.

Now:

"I saw a video" is no longer enough.

This affects:

journalism
education
scientific communication
politics
social trust

Implications for Software Engineers Building AI Systems

As developers building generative AI products, we should think beyond model quality.

The question is not only:

"Can we generate realistic video?"

The bigger question:

"How will humans interpret these generated realities?"

Possible engineering solutions:

1. Provenance Metadata

Generated content should carry:

{
  source: "AI-generated",
  model: "video-model-x",
  timestamp: "...",
  generation_id: "..."
}

Similar to image metadata standards.

2. Watermarking

Invisible signals could help detect synthetic media.

Challenges:

attackers may remove them
compression can damage them

3. Physics-Aware Generation

Future video models may need:

Visual realism
+
Physical simulation

Instead of only learning:

"What pixels usually look like"

they need:

"How the world behaves."

Possible integration:

AI Video Model

        +

Physics Engine

        +

World Model

The Future: Synthetic Reality Needs Synthetic Literacy

The next generation may not have a problem distinguishing:

real vs cartoon

They will need to distinguish:

real event
generated event
simulated event
edited event

Just as previous generations learned:

books are not reality
movies are not reality
games are not reality

future generations must learn:

AI video is not automatically evidence

Final Thoughts

AI-generated videos probably will not make humans forget basic physics.

Our brains are too strongly grounded in physical interaction.

However, synthetic media may change something deeper:

our relationship with visual evidence.

The challenge of the AI era is not only creating machines that can generate realities.

It is creating humans who can navigate a world where reality itself can be generated.

The future skill may not be:

"Can you create realistic images?"

It may be:

"Can you reason about reality when images are no longer reliable?"

How I Refactored a Distributed Hardware Control System into a Reusable Framework

Mohammad Rajaei Monfared — Sat, 25 Jul 2026 13:55:41 +0000

Building software for industrial machines taught me an unexpected lesson: scaling isn't about adding more hardware, it's about reducing architectural complexity.

A few years ago, I led the development of a distributed hardware control system that orchestrated multiple industrial machines. The master controller coordinated production, while a React dashboard gave operators real-time visibility through WebSockets. Under the hood, we were running a fleet of Raspberry Pis, each communicating with an Arduino Due running the g2core motion control firmware.

At first, everything seemed straightforward. But as we added more robotic cells, our software began to buckle under the weight of its own abstractions.

This is the story of how a simple collection of control scripts morphed into an overly generic, bloated framework, and how I eventually had to tear it all down to build a clean, domain-driven architecture.

1. The Day Scripts Stopped Scaling

When you are controlling physical motors, early success is intoxicating. You send a JSON payload over TCP, a stepper motor whirs to life, and a robotic arm moves exactly 150 millimeters to the right.

But distributed systems have a funny way of punishing organic growth. As we expanded the production line by adding six more robotic cells, bringing the system to around sixteen distributed nodes, the software architecture began showing its limits. We experienced dropped TCP connections, skipped heartbeats, and UI state that desynced from the physical hardware.

The real challenge wasn't controlling motors anymore. It was controlling complexity.

To understand why the system started fighting us, you first have to understand the hardware stack we were building on.

2. Understanding the Hardware Stack

Industrial environments require strict separation of concerns between high-level orchestration and low-level real-time execution. Our stack looked like this:

HMI (Human-Machine Interface): A React frontend communicating via WebSockets for real-time monitoring and HTTP for configuration.
Master Controller: An asynchronous Python application orchestrating the entire factory floor.
Raspberry Pi (Slave): A local edge computer for each machine, running a Python TCP server.
Arduino Due: The real-time microcontroller running g2core, translating high-level JSON/G-code into precise electrical pulses for the motor drivers.

This hardware separation is standard. The architectural problem was how we mapped our software onto it.

3. The First Design: Simple, But Naive

For the first version of the system, we kept the slave software intentionally dumb. The Raspberry Pi exposed a TCP server, accepted JSON commands, forwarded them to g2core over a serial port, and returned the results.

It looked something like this:

# Early design: Networking, request routing, and hardware control
# all live inside a single class.
class DeviceServer:
    def __init__(self, serial_port):
        # Open a direct serial connection to the Arduino/g2core firmware.
        self.ser = serial.Serial(serial_port, 115200)

        # Simple command router: map incoming JSON commands
        # to Python handler functions.
        #
        # This worked well initially, but as more commands and
        # workflows were added, this dictionary became the center
        # of the entire application.
        self.COMMAND_HANDLER = {
            "raw": self._handle_raw,
            "G1": self._handle_move,
            "get_status": self._handle_status,
        }

    async def handle_client(self, reader, writer):
        # Receive a JSON request from a TCP client.
        data = await reader.read(1024)
        request = json.loads(data.decode())

        # Find the corresponding command handler.
        command = request.get("cmd")
        handler = self.COMMAND_HANDLER.get(command)

        if handler:
            # Execute business logic, which often communicates
            # with the Arduino over the serial port.
            response = handler(request["payload"])

            # Send the result back to the client.
            writer.write(json.dumps(response).encode())
            await writer.drain()

    def _send_serial(self, data):
        # Send a command to the Arduino/g2core controller.
        self.ser.write((data + "\n").encode())

        # ⚠️ Problem:
        # This blocks until the Arduino responds.
        #
        # Although the server uses asyncio, every command that
        # waits here prevents this request from making progress.
        # As more machines and longer-running operations were added,
        # serial communication became a scalability bottleneck.
        return self.ser.readline().decode()

The Original Request Flow

Simple. Easy to understand. Easy to debug. For one machine, it was exactly the right architecture.

4. The Architectural Smells

As the system grew, this simple script became a nightmare. We encountered problems that every distributed system eventually faces:

Blocking I/O Killed Concurrency: Look at _send_serial in the snippet above. It calls ser.readline(). Because serial communication is slow, this blocked the entire asynchronous event loop. While the Pi waited for the Arduino to confirm a motor move, it couldn't respond to network heartbeats. The Master Controller assumed the Pi was dead and initiated a fault recovery.
State Lived Everywhere: If an operator pressed "Pause" on the HMI, where did that state live? The Controller had a is_paused flag. The Pi TCP server had a state = PAUSED variable. The Arduino also had its own internal motion planner state. Keeping these three in sync across unreliable TCP connections resulted in massive race conditions.
Workflow Leaked into Infrastructure: We started adding retry logic, pause/resume handling, and fault recovery directly inside the socket handlers. Our networking code was suddenly making business decisions.

5. The Wrong Refactor: Abstract Everything

Like many engineers facing a messy codebase, my instinct was to extract every recurring pattern into its own module. I decided to build a "Hardware Control Framework."

The directory structure gradually looked like this:

framework/
├── cycles/        # Lifecycle managers
├── events/        # Global event bus (Pub/Sub)
├── hardware/      # Base classes for hardware
├── mixins/        # StateMachineMixin, RetryMixin, etc.
├── network/       # Abstracted TCP/UDP logic
├── serial/        # Serial communication wrappers
└── system/        # Global singletons

At first glance, this looked like progress. Everything was abstract. Everything was reusable.

But I had fallen into a classic trap: The framework had started solving problems that didn't actually exist.

I had heavily utilized mixins and deep inheritance. A single RoboticArm class inherited from HardwareBase, StateMachineMixin, and NetworkNode. When a TCP packet failed to send, the stack trace hopped through 15 different abstract files.

Some abstractions represented real domain concepts. Others existed simply because I could create them. They made the framework larger without making the architecture clearer.

6. Designing the Architecture I'd Build Today

Looking back, I realized the project contained three completely different kinds of software:

Infrastructure: TCP sockets, connection pooling, heartbeats.
Device Runtime: Serial communication, g2core protocols, hardware limits.
Production Logic: Recipes, machine coordination, calibration steps.

If I were starting over, I would abandon the "general-purpose framework" approach and strictly organize the software around domain responsibilities.

The Refactored Architecture

Here is why each component exists and the specific problems it solves:

Why the Controller Exists

The controller orchestrates the system. It starts production scripts, manages the lifecycle, and enforces that only one production workflow runs at a time.

The Problem it Solves: Without it, workflow ownership is unclear, and pause/resume logic spreads across the codebase.
The Constraint: It doesn't know anything about serial ports, motor drivers, or sockets. It coordinates. Nothing more.

Why the Machine Agent Exists

Each physical machine becomes an object with ownership over its own state on the master server.

The Problem it Solves: Instead of scattering networking code throughout the application, the MachineAgent owns the TCP client, the status cache, and high-level operations.
The Result: The caller never thinks about sockets or retries. Production scripts just call machine.rotate(10) or machine.home(). The agent encapsulates the network complexity.

Why the Job Queue Exists (The Game Changer)

Industrial machines require deterministic execution. Motion commands cannot execute concurrently just because they're asynchronous in software. If you send a "Move X" and "Move Y" command at the same time, the hardware might attempt to interpolate them, crash, or ignore one entirely.

Each edge device now owns a strict, sequential Job Queue.

This simple rule removed an entire class of race conditions. Concurrency is handled by the transport layer (so heartbeats can still be processed), but hardware execution is strictly sequential.

Why the Transport Layer is Isolated

Communication deserves its own module. Nothing more. Nothing less. It handles request/response tracking, the JSON protocol, connection pooling, and fault recovery. It is not a service discovery framework, and it does not know what a "motor" is.

Why Recipes are Separated from Workflows

In the old system, scripts contained hardcoded values. In the new architecture, Recipes are configuration, and Scripts are execution. A recipe stores parameters (e.g., target_temperature = 200, feed_rate = 50). Production scripts decide how to use them. Keeping data and logic separate makes both trivially easy to test.

7. Why This Design Scales Better

This domain-driven approach fundamentally changed the stability of our system.

Fault Isolation: When a serial cable was unplugged, the Device Runtime threw an error. The Job Queue paused. The Transport layer cleanly reported the error back to the Machine Agent. The Controller saw the error and halted the workflow. No hanging sockets, no deadlocks.
No More God Objects: By favoring composition over inheritance, we deleted all our Mixins. A Machine doesn't inherit from a NetworkNode; a Machine has a NetworkNode.
True Asynchronous I/O: By separating the network transport from the hardware execution queue, the Pi could instantly respond to a "status check" or "heartbeat" over TCP, even if the motors were in the middle of a 30-second physical movement.

8. Lessons Learned: Design Principles I Follow Today

When engineers hear the word "framework," it's tempting to think about flexibility and abstraction. But experience has taught me that frameworks should emerge from domain concepts, not from implementation details.

If I were starting this system over today, I would follow these seven rules:

The Master orchestrates; the Slave executes. Never put business logic on the edge device.
Scripts describe workflows; recipes hold data. Don't hardcode production logic.
Machines own their own state and queues. Protect your hardware with strict, sequential execution queues.
Prefer composition over deep inheritance or mixins. Avoid the trap of the "clever" object-oriented hierarchy.
Create new modules only when a second real use case appears. Don't preemptively abstract.
Wire dependencies explicitly at startup instead of relying on global singletons.
Keep infrastructure invisible to business logic whenever possible.

These principles aren't specific to robotics or mechatronics. You could replace the Arduino with a cloud database, the stepper motors with background worker tasks, and the Raspberry Pi with a microservice. The architectural boundaries remain exactly the same.

The most valuable part of this project wasn't writing code that controlled motors. It was learning to separate orchestration, communication, and device control. Ironically, the final architecture contained fewer modules than my original "framework", yet it explained the system much more clearly.

Sometimes the best refactoring isn't adding another abstraction. It's deleting one.

I'd love to hear how you've approached similar problems. Have you ever built a framework that later became too generic? Or simplified an architecture by removing abstractions instead of adding them? Let's discuss it in the comments below.

Advanced JS Execution: Promises, Workers, and Comlink

Mohammad Rajaei Monfared — Wed, 22 Jul 2026 13:52:41 +0000

You wrap a slow loop in an async function. You sprinkle in await. You tell yourself the page will stay smooth because the work is "async now."

Then you click the button.

The tab locks. Scroll dies. The spinner never spins. Clicks pile up like unanswered mail. Thirty seconds later, the status finally says "Done" — and you wonder whether Promises are broken.

They are not. You asked them to solve a problem they were never designed for.

Promises help you wait. They do not move CPU work off the main thread. Web Workers do.

That distinction is the whole article. We will build it in order:

Why async can still freeze the UI
How a worker fixes it with postMessage
How Comlink, SharedArrayBuffer, and pools fit when the app grows up

One example carries us through: crunch a large array of numbers (pixels, analytics rows, whatever) without locking the page.

If you want the foundation first — call stack, microtasks vs macrotasks, and the event loop — start with my earlier post: Why Your JavaScript Runs in the Wrong Order. This article picks up where that one leaves off: when waiting is not enough and you need another thread.

Runnable examples

Every major step has a small project you can clone and run. They live in examples/. The repo README.md has install commands.

Example	Folder	What you learn
Frozen UI	`01-main-thread-freeze`	`async` + heavy loop still blocks
Raw worker	`02-raw-web-worker`	`postMessage` keeps UI responsive
Comlink	`03-comlink-worker`	Call the worker like `await api.calculate(length)`
Shared memory	`04-shared-array-buffer`	Comlink + SharedArrayBuffer + COOP/COEP
Browser pool	`05-workerpool`	Queue many jobs across workers
Node pool	`06-piscina-node`	Piscina on Node `worker_threads`

git clone https://github.com/mrajaeim/Advanced-JS-Execution.git
cd Advanced-JS-Execution/examples/02-raw-web-worker
npm install
npm run dev

The snippets below are shortened for reading. Prefer the GitHub projects when you want the full UI — status text, a Ping button that shows click counts on its label, and Vite setup included.

The Problem

Most of us learn a comforting story about async JavaScript:

If the code uses async / await / Promises, the UI stays smooth.

That story is half true. It holds when you are waiting — for a network response, a timer, a disk read. It falls apart the moment you start computing on the main thread.

Here is the trap in miniature:

async function processOnMainThread(numbers) {
  await Promise.resolve(); // yields once, then...

  let total = 0;
  for (let i = 0; i < numbers.length; i++) {
    total += Math.sqrt(numbers[i] * numbers[i] + 1);
  }
  return total; // ...this still owns the main thread
}

button.addEventListener('click', async () => {
  status.textContent = 'Working...';
  const numbers = Array.from({ length: 85_000_000 }, (_, i) => i);
  const total = await processOnMainThread(numbers);
  status.textContent = `Done: ${total}`;
});

What you expect: the status updates, the page stays clickable, then "Done" appears.

What you get: a frozen tab until the loop finishes.

Open examples/01-main-thread-freeze, click Run heavy work, dismiss the alert, then try Ping UI or change the array length. The Ping button label (Ping UI (1), Ping UI (2), …) should stall — and so should the input. That is the main thread, busy doing math, unable to paint or handle input.

await Promise.resolve() only delayed the freeze by one microtask. The math never left the main thread. You scheduled a wait — then immediately monopolized the only thread the UI has.

Why It Happens

Promises resume on the same thread

A Promise is a promise of a value later. When it settles, .then and await continue as microtasks on the same main thread that started them.

MAIN THREAD
sync code → await (wait for I/O) → more sync code HERE

That shape is perfect for fetch. It is a disaster for a multi-second CPU loop, because the loop is not waiting for anything. It is work. And work on the main thread means the browser cannot reliably handle clicks, DOM updates, or smooth animation.

The main thread has one call stack

While that stack is chewing through tens of millions of iterations, nothing else gets a turn. The UI is not "slow." It is parked.

Workers are a second JavaScript thread

A Web Worker has its own call stack and its own event loop. It cannot touch the DOM — that is the trade. In exchange, it can grind through heavy work while the main thread stays free for people clicking buttons.

You talk with messages:

MAIN THREAD                         WORKER THREAD
UI, DOM, clicks                     heavy CPU work
     │ postMessage(data)                  │
     └──────────────────────────────────► │
     │                                    │ compute
     │ ◄──────────────────────────────────┘
       onmessage(result)

Approach	Where the loop runs	UI during work
`await` + loop on main	Main call stack	Frozen
Worker + `postMessage`	Worker call stack	Responsive

Here is the part that confuses people: the main thread can still use a Promise to wait for the worker's reply. That Promise is waiting for a message. The heavy work already ran somewhere else. Same await keyword. Completely different place the CPU spent its time.

How to Confirm It (Before You Fix It)

Before you reach for a worker, ask of each line: is this waiting, or is this computing?

await Promise.resolve(); // WAIT (cheap)
for (...) { ... }        // COMPUTE on main (expensive)

If the expensive part is compute, another Promise will not save you. You need another thread.

In Chrome DevTools Performance, record a click. Look for a long yellow main-thread task that lines up with your loop. That block is the smoking gun — and the reason your spinner never moved.

Better Solution: Move the Loop to a Worker

Use a Promise for waiting. Use a Web Worker for heavy computing.

The pattern is simple once you say it out loud:

Keep UI on the main thread
Put the heavy work in worker.js — including building the big array
Send only what you need with postMessage (here: the length)
Wrap the reply in a Promise so UI code can still await

Full runnable app: examples/02-raw-web-worker.

worker.js

self.onmessage = (event) => {
  const length = event.data;
  const numbers = Array.from({ length }, (_, i) => i);

  let total = 0;
  for (let i = 0; i < numbers.length; i++) {
    total += Math.sqrt(numbers[i] * numbers[i] + 1);
  }
  self.postMessage(total);
};

main.js

function processInWorker(length) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(new URL('./worker.js', import.meta.url));

    worker.onmessage = (event) => {
      resolve(event.data);
      worker.terminate();
    };
    worker.onerror = (error) => {
      reject(error);
      worker.terminate();
    };

    worker.postMessage(length);
  });
}

button.addEventListener('click', async () => {
  status.textContent = 'Working...';
  const total = await processInWorker(85_000_000);
  status.textContent = `Done: ${total}`;
});

Now the expected behavior matches reality: "Working..." stays visible, Ping UI keeps updating its label (Ping UI (1), Ping UI (2), …), and "Done" appears when the worker finishes. The await is still there — but it is waiting for a message, not for the main thread to finish math.

What each piece does

Piece	Role
`new Worker(...)`	Starts a second JS thread (no DOM access)
`postMessage(length)`	Sends a small number; main continues immediately
Worker's `onmessage`	Builds the array and runs the loop on the worker stack
`processInWorker`'s Promise	Only waits for the reply — does not run the math

MAIN                                   WORKER
click → status = "Working..."
postMessage(length) ────────────────► receive length
await (main free for clicks)            build array + run loop
onmessage ←────────────────────────── postMessage(total)
status = "Done..."

You can soften small freezes by chunking a loop with setTimeout(0) on the main thread. For large jobs it gets messy fast — progress, cancellation, slower total time, harder reasoning. A worker is the clearer architecture: one place for UI, one place for grind.

Next Step: Comlink (RPC-style Workers)

Raw postMessage is honest and a little painful. As soon as the worker has more than one job, you invent a protocol: message types, payloads, request IDs, error shapes. You become a courier for your own functions.

Comlink is a thin RPC layer on top of workers. The idea is almost embarrassingly simple:

The worker exposes an API object
The main thread wraps the worker
You call await api.calculate(length) like a normal async module

Under the hood it still uses messages. The mental model does not change: wait with Promises, compute on a worker. Comlink just stops you from hand-writing the routing.

Runnable project: examples/03-comlink-worker.

Worker

import { expose } from 'comlink';

function calculate(length) {
  const numbers = Array.from({ length }, (_, i) => i);

  let total = 0;
  for (let i = 0; i < numbers.length; i++) {
    total += Math.sqrt(numbers[i] * numbers[i] + 1);
  }
  return total;
}

expose({ calculate });

Main

import { wrap } from 'comlink';

const worker = new Worker(new URL('./worker.js', import.meta.url), {
  type: 'module',
});
const api = wrap(worker);

const total = await api.calculate(85_000_000);

Style	Call site	Who routes replies
Raw `postMessage`	`{ type, payload }`	You
Comlink	`await api.calculate(length)`	Comlink

Use raw messaging for one tiny job with zero dependencies. Reach for Comlink when the worker becomes a real API — image pipelines, inference helpers, multi-method tools. Comlink also supports transferables, typed APIs, and SharedArrayBuffer-friendly flows when you need them later.

When Copying Data Is the Bottleneck: SharedArrayBuffer

Sometimes the math is fine, and the tax is the copy. postMessage clones or transfers data. For huge frames or tensors shared by several workers, that traffic can dominate cost — you spend more time moving memory than processing it.

A SharedArrayBuffer is memory more than one thread can see at once. Workers mutate it in place. You still need careful partitioning or Atomics so threads do not corrupt each other. Shared memory without a race strategy is just a faster way to get weird bugs.

Main (UI)
   │ Comlink (start job / progress / done)
Worker pool
   │ SharedArrayBuffer (pixels, tensors)
WASM / SIMD kernels

Runnable project (Vite already sets COOP/COEP): examples/04-shared-array-buffer.

const buffer = new SharedArrayBuffer(length * Float32Array.BYTES_PER_ELEMENT);
// Workers fill and mutate their slices; main only allocates.
await api.processShared(buffer, start, end);

Before you adopt it, you need three things:

Cross-origin isolation headers (COOP: same-origin, COEP: require-corp)
A race strategy (split ranges, single writer, or Atomics)
Proof from profiling that cloning or transfer is actually the problem

Start with Comlink + normal messages or transferables. Add SharedArrayBuffer when memory movement — not the algorithm — is the cost.

Pools: Many Jobs, Not One Worker Per Click

Creating a worker has startup cost. Spawning a fresh one on every click is like hiring a new employee for every email. If the UI fires many jobs, use a pool: a small set of workers that share a queue.

Need	Tool	Example
Browser job queue	workerpool	`examples/05-workerpool`
Node `worker_threads` pool	Piscina	`examples/06-piscina-node`

Browser (workerpool):

import workerpool from 'workerpool';

const pool = workerpool.pool(new URL('./heavy.worker.js', import.meta.url).href);
const result = await pool.exec('calculate', [length, jobId]);

Node (Piscina):

import Piscina from 'piscina';

const pool = new Piscina({
  filename: new URL('./worker.mjs', import.meta.url).href,
});
const result = await pool.run({ length, jobId });

Pick a stack by scenario

Scenario	Stack
React / Vite UI, readable worker API	Comlink (+ workerpool if many jobs)
Browser AI / vision / big frames	Comlink or workerpool + WASM/ONNX, SharedArrayBuffer if needed
Node images, PDFs, compression, ML	Piscina

A quick map of the libraries (numbers and APIs change over time):

Package	Best at
Comlink	`await worker.method()` ergonomics in the browser
workerpool	Queue + N workers (browser or Node)
Piscina	Production Node worker pool

Warnings Worth Knowing

A few sharp edges show up again and again:

No DOM in workers. Compute there. Update React or the DOM on the main thread.
Huge clones stall the main thread too. Prefer transferables for big ArrayBuffers: worker.postMessage(buffer, [buffer]).
Match worker type to how you load it (classic vs { type: 'module' }). A mismatch fails in ways that look mysterious at first.
Wire worker.onerror (and pool errors). Without that, failures look like hung Promises that never settle.
Browser Workers ≠ Node worker_threads. Same idea, different APIs and libraries. Do not paste one into the other and expect kindness.

When to Use What

Situation	Use
Waiting on network, timers, IndexedDB	Promises / `async`
Short work between awaits	Stay on the main thread
Large CPU work, UI must stay live	Web Worker
Worker grows into many methods	Comlink
Many concurrent jobs	workerpool (browser) or Piscina (Node)
Huge shared frames/tensors	SharedArrayBuffer after measuring
I/O-bound or tiny work	Do not add a worker

Not every freeze needs a worker. Tiny work and pure I/O usually do not. Reach for parallelism when the UI must stay alive and the CPU has real work to do.

Conclusion

async does not mean "runs in parallel." It means "can wait without busy-waiting on this thread."

A Web Worker is the tool that runs heavy JavaScript somewhere else while the UI thread stays free. Wrap the reply in a Promise so your app code stays readable — the await is for the message, not for the math.

Then climb only as far as you need:

Raw postMessage (example 02)
Comlink (example 03)
A pool (examples 05 / 06)
SharedArrayBuffer (example 04) when memory movement is the bottleneck

The fastest way to feel the difference: clone the repo, run 01 next to 02, dismiss each alert, and click Ping UI in both. In 01 the button label freezes; in 02 it keeps counting. That comparison teaches the architecture faster than any diagram.

What was the first job you tried to "fix" with async/await that still froze the tab?

Why Your JavaScript Runs in the Wrong Order

Mohammad Rajaei Monfared — Sun, 19 Jul 2026 16:30:00 +0000

Copy this into your browser console:

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');

You probably expect: 1, 2, 3, 4.

You get: 1, 4, 3, 2.

Nothing is broken. JavaScript is doing exactly what it was designed to do. The confusing part is that the language looks like it runs top to bottom, but it does not always work that way.

In this article you will learn three ideas that explain almost every async surprise in JavaScript:

The call stack (what runs right now)
The event loop (what runs next)
Async code (how waiting fits in without freezing your app)

No prior knowledge of the event loop required. We will build the mental model step by step.

The Problem

What developers expect

Most of us learn JavaScript like this: the engine reads your file line by line and runs each line in order.

That mental model works fine for code like this:

function greet() {
  console.log('hello');
}
greet();
console.log('bye');

Output: hello, then bye. Easy.

Then we add setTimeout, Promises, and async/await. The same mental model breaks.

A common frustrating moment

You are debugging a feature. You sprinkle console.log calls to trace the flow. The logs come back in an order that makes no sense.

Or you build a search box. Each keystroke fires a fetch. Sometimes an older response overwrites a newer one. The bug feels random.

Or you use async/await thinking the UI will stay responsive, but a heavy loop after an await still freezes the page.

These are not separate mysteries. They all come from the same root cause: JavaScript can only run one piece of code at a time, but it still needs to handle waiting.

Why It Happens

Part 1: The call stack

Think of the call stack as JavaScript's to-do list for right now. It is a Last-In, First-Out (LIFO) structure: the newest call sits on top and is the only thing that runs.

When your code calls a function, that function goes on top of the stack. When the function finishes, it comes off. The engine always works on whatever is on top.

function c() { console.log('c'); }
function b() { c(); }
function a() { b(); }

a();

While c runs, the stack looks like this:

┌─────────┐
│   c()   │  ← running now
├─────────┤
│   b()   │
├─────────┤
│   a()   │
└─────────┘
  CALL STACK

Rules of the call stack:

Only one function runs at a time
Synchronous code runs immediately, in call order
When the stack is empty, the current "turn" of synchronous work is done

That last rule is the key to everything that follows.

Part 2: JavaScript cannot wait on the stack

Say you write this:

const data = fetch('/api/user'); // network request
console.log(data);

If JavaScript actually stopped and waited for the network, your entire page would freeze. No clicks. No scrolling. No animations.

So the engine does something smarter. It starts the fetch, then moves on to the next line. When the network responds later, a callback runs.

That "run later" part is handled outside the call stack, by the event loop.

Part 3: The event loop in plain English

Part 1 showed what runs right now (the call stack).

Part 2 showed that fetch and setTimeout cannot block the stack while they wait.

So where does that waiting work go? And when does the "run later" code actually execute?

That is what the event loop handles. It is the coordinator that lets single-threaded JavaScript stay non-blocking: slow work (network, timers, I/O) is handed to the browser or Node.js, and the loop decides when their callbacks get a turn on the call stack.

The pieces that work together

Four structures share the job. Think of them as one runtime, not four separate engines:

+-------------------------------------------------------------+
|                     Browser / Node.js                       |
|                                                             |
|   +-------------------+             +-------------------+   |
|   |    Call Stack     |             |  Web / Node APIs  |   |
|   |  (synchronous)    |             | (timers, fetch…)  |   |
|   +---------+---------+             +---------+---------+   |
|             ^                                 |             |
|             |  pushes work                    | finishes    |
|             |  onto the stack                 v             |
|     +-------+-------+               +---------+---------+   |
|     |  Event Loop   |               |  Microtask Queue  |   |
|     | (coordinator) |<--------------+ (Promises, await) |   |
|     +---------------+   drains      +---------+---------+   |
|                             before            ^             |
|                             the next          |             |
|                                     +---------+---------+   |
|                                     |  Macrotask Queue  |   |
|                                     | (setTimeout, DOM) |   |
|                                     +-------------------+   |
+-------------------------------------------------------------+

Piece	Role in one sentence
Call stack	LIFO stack of the function that is running right now. Frames go on when called, off when finished.
Web / Node APIs	Work the runtime owns outside your JS thread: timers, `fetch`, DOM events, and similar I/O.
Microtask queue	High-priority FIFO line for Promise callbacks (`.then` / `.catch` / `.finally`), `await` continuations, and `queueMicrotask()`.
Macrotask queue	Lower-priority FIFO line for timer callbacks, many I/O callbacks, and UI events. Often called the task / callback queue.

The event loop itself is not a background thread. It is the rulebook that moves work between these pieces.

A simple analogy

Imagine a cashier (the call stack) who can only help one customer at a time.

Synchronous code walks up and gets served immediately.
setTimeout and fetch are like customers who step aside and wait for a text message ("your order is ready") — that waiting happens in the Web / Node APIs.
When the cashier has no one in line, they check two waiting lists before calling the next walk-in customer.

Those two waiting lists are the important part. JavaScript does not use one generic "later" queue. It uses two, with a strict priority order.

The two waiting lists

Waiting list	Plain name	What goes here	Examples
Microtask queue	the Promise line	callbacks that should run soon	`.then()`, `await` continuations, `queueMicrotask()`
Macrotask queue	the timer/event line	callbacks that can wait a bit longer	`setTimeout`, clicks, network I/O callbacks

Think of it like airport boarding:

Microtasks = priority boarding (Promises go first)
Macrotasks = general boarding (setTimeout, UI events)

What the event loop does, step by step

The engine follows one continuous checklist:

1. Run synchronous code until the call stack is empty
2. Hand async APIs (setTimeout, fetch, …) to Web / Node APIs and keep going
3. When background work finishes, drop its callback into the microtask
   or macrotask queue (depending on the API)
4. With an empty stack, drain EVERY microtask — including ones spawned
   by other microtasks
5. Take exactly ONE macrotask, push it onto the call stack, and run it
6. Go back to step 4

One sentence version: sync first, then all Promises, then one timer/event, then repeat.

That "every microtask" step matters. If a Promise callback schedules another Promise callback, the new one still runs before any macrotask. A busy microtask chain can delay timers and UI events.

Where `setTimeout` and `fetch` fit

When you call setTimeout or fetch, the engine does not run your callback immediately. It hands the waiting job to the browser (or Node.js). That happens outside the call stack.

Your JS code                    Browser / Node (outside the stack)
─────────────                   ──────────────────────────────────
setTimeout(fn, 0)    ────────►   timer starts...
fetch('/api')        ────────►   network request starts...
                                 (your code keeps running)
                                 ...time passes...
timer fires          ◄────────   puts fn in the timer/event line
response arrives     ◄────────   puts .then callback in the Promise line

Your callback only runs when the event loop picks it from a waiting list and puts it back on the call stack.

Walk through our opening example

Here is the snippet again:

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');

Step 1: synchronous code (call stack)

Line	What happens	Printed so far
`console.log('1')`	runs immediately	`1`
`setTimeout(...)`	browser starts a timer; when it fires, the callback waits in the timer/event line	`1`
`Promise.then(...)`	callback waits in the Promise line	`1`
`console.log('4')`	runs immediately	`1`, `4`

Call stack is now empty. Synchronous work is done.

Step 2: Promise line (microtasks)

The engine drains the microtask queue completely before touching timers:

What runs	Printed so far
`console.log('3')`	`1`, `4`, `3`

Step 3: timer/event line (one macrotask)

Now the loop takes exactly one macrotask — the setTimeout callback:

What runs	Printed so far
`console.log('2')`	`1`, `4`, `3`, `2`

Final answer: 1, 4, 3, 2

Why that order sticks:

1 and 4 are pure sync work on the call stack, so they print first.
setTimeout(..., 0) registers a timer right away; when it expires, the callback lands in the macrotask queue — not on the stack.
The resolved Promise schedules its callback in the microtask queue.
After the main script finishes, the event loop clears microtasks before any macrotask, so 3 prints before 2.

3 beats 2 because Promise callbacks always run before setTimeout callbacks, even when the timer is set to 0.

The one rule to remember

Sync code first. Then all Promises. Then one timer or event. Then repeat.

If you remember that, the opening example stops feeling random.

Part 4: What `async/await` actually does

async/await is just Promise syntax. It does not pause the entire program.

async function load() {
  console.log('A');
  await fetch('/api/user');
  console.log('B');
}

console.log('1');
load();
console.log('2');

What happens:

1 prints (sync)
load() starts, A prints (sync)
await hits the network and steps out of the function
2 prints (sync) because the stack is free
Fetch finishes, B prints (microtask)

Output: 1, A, 2, B

The code after await does not run when the network finishes inside your function like a blocking pause. It gets scheduled as a microtask for later.

Manual Solution: Trace the Code by Hand

You do not need tools to predict small examples. Label each line, then follow the event loop rules.

Take our opening snippet:

console.log('1');                                    // SYNC
setTimeout(() => console.log('2'), 0);               // schedules MACROTASK
Promise.resolve().then(() => console.log('3'));    // schedules MICROTASK
console.log('4');                                    // SYNC

Now walk through it.

Round 1: synchronous code

Step	Call stack	Console output
`console.log('1')`	`[log]`	`1`
`setTimeout(...)`	`[setTimeout]`	(schedules `2` for later)
`Promise.then(...)`	`[then]`	(schedules `3` for later)
`console.log('4')`	`[log]`	`4`
Stack empty	`[]`

Round 2: microtasks

The Promise callback runs:

Console output
`3`

Round 3: one macrotask

The setTimeout callback runs:

Console output
`2`

Final output: 1, 4, 3, 2

That is the full manual process. For any small snippet:

Run every synchronous line until the stack is empty
Run every microtask
Run one macrotask
Repeat from step 2

Verify in DevTools

Open Chrome DevTools, go to Sources, and set a breakpoint inside a .then() callback. When execution pauses, look at the Call Stack panel on the right. It shows exactly which functions are active.

For log-order bugs, numbered labels help:

console.log('[sync] user clicked');

I use this in code reviews all the time. It is simple and it works.

Drawbacks of the Manual Process

Tracing by hand is great for interview questions and 5-line snippets. It gets painful in real apps.

React, Vue, and other frameworks schedule work you cannot see
Network responses arrive in unpredictable order
One file may mix setTimeout, Promises, and await in ways that are hard to track
It is easy to forget the rule: all microtasks run before the next macrotask

Knowing the rules is not the same as writing code that survives fast user input and slow networks. That is where patterns help.

Better Solution: Three Rules for Async Code

Instead of tracing every line in your head, write code that matches how the runtime works.

Rule 1: Keep synchronous blocks short.

Long loops on the main thread block everything, even after an await. If work is heavy, break it into chunks or move it to a Web Worker.

Rule 2: Use async/await to sequence steps in one flow.

When step B needs the result of step A, await is the right tool. It keeps the logic readable.

Rule 3: Guard against out-of-order async results.

When the user can trigger the same async action multiple times (search, pagination, tab switches), ignore or cancel stale results.

These three rules fix most production async bugs I have seen.

Complete Code

Here is a before/after for a search box. This is the full example we will break down.

Before (buggy):

searchInput.addEventListener('input', async (event) => {
  const query = event.target.value;

  const response = await fetch(`/api/search?q=${query}`);
  const data = await response.json();

  renderResults(data); // may render stale data
});

After (fixed):

let activeController = null;

searchInput.addEventListener('input', async (event) => {
  const query = event.target.value;

  // Cancel the previous in-flight request
  if (activeController) {
    activeController.abort();
  }

  activeController = new AbortController();

  try {
    const response = await fetch(
      `/api/search?q=${encodeURIComponent(query)}`,
      { signal: activeController.signal }
    );
    const data = await response.json();
    renderResults(data);
  } catch (error) {
    if (error.name === 'AbortError') {
      return; // a newer search started, ignore this one
    }
    showError(error);
  }
});

Breakdown

Why the "before" code breaks

Each keystroke starts a fetch. All requests run at the same time. Whichever response arrives last wins, not whichever query is current.

If the user types react quickly, the response for re might arrive after react. The UI shows results for re. That looks like async code is "random." It is not. The event loop is working fine. The code just never checks whether the result is still relevant.

`activeController`

A variable that holds the current AbortController. Think of it as a remote control for the in-flight fetch.

When the user types a new character, we abort the old request before starting a new one.

`AbortController` and `signal`

fetch accepts a signal option. When you call controller.abort(), the in-flight fetch rejects with an AbortError.

This is better than ignoring stale results silently. It actually cancels work you no longer need.

The `try/catch` block

Not every aborted request is an error worth showing. AbortError means "a newer search replaced this one." We return early and do nothing.

Real errors (network down, 500 response) still go to showError.

Real Example: Step by Step

Let us trace the fixed search box when a user types r, then re.

Keystroke 1: user types `r`

SYNC:  input handler runs
SYNC:  abort() called (nothing to abort yet)
SYNC:  fetch('/api/search?q=r') starts (network waits in background)
SYNC:  handler returns, stack is empty
...later...
MICRO: await continuation runs, renderResults for "r"

Keystroke 2: user types `re` (before `r` responds)

SYNC:  input handler runs
SYNC:  abort() cancels the "r" request
SYNC:  fetch('/api/search?q=re') starts
SYNC:  handler returns
MICRO: "r" fetch rejects with AbortError → catch block returns early
...later...
MICRO: "re" fetch resolves → renderResults for "re"

The UI always shows results for the latest query. No race condition.

Back to the classic log-order example

Paste this in your console and watch it run:

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');

Phase	What runs	Output so far
Sync	`1`, `4`	`1`, `4`
Microtasks	Promise callback	`1`, `4`, `3`
Macrotask	setTimeout callback	`1`, `4`, `3`, `2`

Once you have done this two or three times, the order stops feeling random.

Warnings and Edge Cases

Blocking the call stack freezes everything

JavaScript has one main thread for your page script. A long sync job — resizing a huge image in a loop, parsing a massive JSON blob, or an accidental infinite loop — never leaves the call stack. While that frame is stuck, the event loop cannot drain microtasks or macrotasks. Clicks queue up. Animations stall. The tab looks dead even though "async" APIs are still waiting in the background.

That is why heavy CPU work belongs in chunks or in a Web Worker, not in a tight loop after an await.

Timers are minimums, not appointments

setTimeout(fn, 1000) does not promise that fn runs at the one-second mark. It means: after at least 1000ms, the callback may enter the macrotask queue. If the stack is busy, or microtasks keep spawning, the callback waits longer. Treat the delay as a floor, not a schedule.

`setTimeout(fn, 0)` does not mean "run immediately after sync code"

It means "schedule a macrotask." Promise callbacks still run first. If you need to defer work to after the current synchronous block but before timers, use queueMicrotask() instead.

`await` does not run fetches in parallel

This is sequential (B waits for A):

const a = await fetch('/a');
const b = await fetch('/b');

This runs both at once:

const [a, b] = await Promise.all([
  fetch('/a'),
  fetch('/b'),
]);

Long sync work after `await` still blocks the UI

async function heavy() {
  await fetch('/data');
  for (let i = 0; i < 1_000_000_000; i++) {} // blocks clicks and scrolling
}

await only yields before the loop, not during it.

Node.js has one extra queue

In Node, process.nextTick() runs even before microtasks. Browser code rarely needs this, but Node tutorials lean on it. Node's loop is also organized into phases (timers, I/O, check, close, and so on). The browser-friendly story in this article still holds for most app code; when you debug server timers and nextTick ordering, read the Node event loop guide.

Frameworks add their own scheduling

React 18 batches state updates differently than React 17. If your logs inside useEffect do not match a bare-bones example, the framework may be batching work. Always test in your real setup.

When to Use This Knowledge

Reach for this mental model when:

Console logs appear in a confusing order
A fetch-heavy UI shows stale data
You are choosing between setTimeout, Promise, and queueMicrotask
You are reviewing async code in a pull request

This alone is not enough when:

You have CPU-heavy work (use a Web Worker)
You need true multi-core parallelism
You are doing server-side concurrency in Node (look into worker threads)

On a team, it helps to agree on one pattern for canceling stale fetches (AbortController is a good default) and to ask in review: "what happens if the user triggers this twice before the first call finishes?"

Conclusion

JavaScript runs synchronous code on the call stack first. When the stack is empty, the event loop drains every microtask (Promises, await), then runs one macrotask (setTimeout, events), and repeats.

That single rule explains why 1, 4, 3, 2 is the correct output for our opening example. It also explains why search boxes need cancellation logic, and why async/await alone does not keep the UI smooth during heavy loops.

You do not need to memorize every edge case. Remember the big picture: sync first, then microtasks, then one macrotask. Everything else is a variation on that.

Go further

MDN: JavaScript execution model — the formal picture of the stack, tasks, and microtasks
Node.js: The Node.js Event Loop — how phases and nextTick differ from the browser story

If you want a follow-up deep dive, the natural next stops are: how async/await maps onto that visual timeline, how to hunt a specific out-of-order race, or how Node's phases differ when you leave the browser.

What was the first async bug that made you stop and question how JavaScript actually works?

Stop Rebasing Every Time: A Safer Way to Keep Your Git Branch Updated with `master`

Mohammad Rajaei Monfared — Sat, 18 Jul 2026 18:30:00 +0000

If you work on long-lived feature branches, you've probably experienced this:

master (or main) keeps moving.
Your branch falls behind.
Pull requests become harder to review.
Merge conflicts get bigger every day.

Many teams solve this by rebasing their feature branches.

Others—including many enterprise teams—prefer merging the latest master into the feature branch to preserve commit history and avoid rewriting commits that may already be shared.

If your workflow uses merge instead of rebase, this article shows how to make the process much faster with a custom Git alias.

The Problem

Imagine your repository looks like this.

master
A──B──C──D

feature/login
     \
      E──F

While you're developing, your teammates merge several pull requests.

master
A──B──C──D──G──H──I

feature/login
     \
      E──F

Now your feature branch is missing the latest changes.

If you don't sync it:

merge conflicts accumulate
CI may fail unexpectedly
testing becomes less reliable
your eventual pull request becomes much harder to review

Keeping your branch up-to-date regularly makes integration much smoother.

Updating Your Branch Manually

Suppose you're working on:

feature/login

and want to sync it with master.

First, fetch the latest changes:

git fetch origin

Switch to your feature branch:

git checkout feature/login

Reset your local branch to match the remote version:

git reset --hard origin/feature/login

Why reset?

This ensures your local branch exactly matches the remote branch before merging. It's useful if your local branch is only a working copy of the remote branch.

Warning: Any unpushed commits will be permanently deleted.

Merge the latest master:

git merge --no-ff origin/master

Finally, push the updated branch:

git push

Your history now becomes:

master
A──B──C──D──G──H──I
               \
feature/login   M
      \        /
       E──────F

where M is the merge commit.

That's a Lot of Typing...

Every time you want to synchronize a branch, you're repeating the same commands:

git fetch
git checkout feature/login
git reset --hard origin/feature/login
git merge --no-ff origin/master
git push

After doing this dozens of times each week, it becomes repetitive.

Fortunately, Git aliases can automate the workflow.

Creating a Git Alias

Run the following command once:

git config --global alias.sync-branch '!f() {
    git fetch &&
    git checkout "$1" &&
    git diff --quiet &&
    git diff --cached --quiet &&
    git reset --hard origin/$1 &&
    git merge --no-ff origin/${2:-master};
}; f'

This creates a new command called:

git sync-branch

How to Use It

Sync your branch with master:

git sync-branch feature/login

Or sync it with another branch:

git sync-branch feature/login develop

which is equivalent to:

git fetch
git checkout feature/login
git reset --hard origin/feature/login
git merge --no-ff origin/develop

What Does the Alias Do?

Let's break it down.

git fetch

Downloads the latest commits from the remote.

git checkout "$1"

Switches to the target branch.

git diff --quiet
git diff --cached --quiet

Ensures there are no uncommitted changes.

If your working tree isn't clean, the alias stops instead of accidentally deleting work.

git reset --hard origin/$1

Makes your local branch identical to the remote branch.

This removes:

local commits
staged changes
unstaged changes

that haven't been pushed.

git merge --no-ff origin/${2:-master}

Merges the latest master (or another specified branch) into your feature branch while always creating a merge commit.

When Should You Use This?

This workflow is ideal if your team:

prefers merge over rebase
wants to preserve merge history
frequently syncs long-running feature branches
already pushes work to the remote regularly

It is not recommended if you often keep local-only commits that haven't been pushed yet.

Important Warnings

⚠️ This alias uses:

git reset --hard

If you have local commits or changes that are not pushed, they will be permanently deleted.

Before using it:

commit your work
push your commits
or stash your changes

Always understand what a Git alias does before adding it to your global configuration.

Final Thoughts

One of Git's most underused features is aliases.

Small automations like this can eliminate repetitive commands and reduce mistakes, especially when you perform the same workflow dozens of times a week.

If your team follows a merge-based workflow, a sync-branch alias can save time while keeping every feature branch aligned with the latest changes from master.

The Hidden Windows Port Issue: Why Your New App Won't Start (Especially After Using a VPN) and How to Fix It

Mohammad Rajaei Monfared — Fri, 17 Jul 2026 08:42:16 +0000

Have you ever cloned a new project, ran:

npm run dev

docker compose up

only to be greeted with an error like:

Error: listen EADDRINUSE

bind: An attempt was made to access a socket in a way forbidden by its access permissions.

The strange part?

Nothing appears to be using the port.
Restarting the application doesn't help.
Even changing to another port sometimes fails.
The issue often starts after connecting to a VPN, enabling Docker Desktop, WSL2, or Hyper-V.

I recently ran into exactly this problem, and the fix was surprisingly simple.

Why Does This Happen?

On Windows, the Host Network Service (HNS) manages networking for technologies such as:

Docker Desktop
WSL2
Hyper-V
Windows Containers
Some VPN software

Sometimes HNS reserves or holds ports even after applications have exited, preventing new processes from binding to them. This behavior has also been reported by developers using Docker, Hyper-V, and WSL networking.

As a result, Windows behaves as if the port is already occupied.

Symptoms

You may notice errors like:

EADDRINUSE

Address already in use

Only one usage of each socket address is normally permitted

or Docker errors related to port publishing.

This is especially common after:

Connecting or disconnecting from a VPN
Starting Docker Desktop
Using WSL2
Working with Hyper-V virtual machines
Switching between networking environments

The Fix

Open PowerShell as Administrator and run:

net stop hns

If Windows asks whether dependent services should also be stopped:

The following services are dependent on the Host Network Service...
Do you want to continue? (Y/N)

Type:

That's it.

In many cases, your application will immediately be able to bind to the port again.

If That Doesn't Work

If the issue persists, check whether Windows has reserved your port:

netsh interface ipv4 show excludedportrange protocol=tcp

If your desired port falls inside one of the excluded ranges, Windows has reserved it for networking components such as Hyper-V or HNS.

Why Restarting HNS Works

Stopping the Host Network Service forces Windows to rebuild its networking state and releases stale network resources.

It's much faster than:

Restarting your computer
Reinstalling Docker
Reinstalling your VPN
Spending an hour wondering why localhost:3000 suddenly stopped working

When Should You Use This?

This solution is worth trying if:

Your development server suddenly won't start.
Docker reports port binding failures.
A port appears to be in use but nothing is listening on it.
The issue began after using Docker Desktop, WSL2, Hyper-V, or a VPN.

Final Thoughts

The next time Windows insists that a port is already in use—even though every process says otherwise—don't immediately assume your application is broken.

Try:

net stop hns

It has saved me more than once, and hopefully it saves you some debugging time too.

If you've encountered other strange Windows networking issues, I'd love to hear how you solved them in the comments.

Data Processing Pipelines in Python Using Generators: Build Memory-Efficient ETL and AI Workflows

Mohammad Rajaei Monfared — Mon, 06 Jul 2026 13:42:47 +0000

When processing large datasets, it's common to chain together multiple operations such as reading data, filtering records, transforming values, and writing the results somewhere else.

A straightforward implementation often creates intermediate lists after each step:

data = read_data()
filtered = filter_data(data)
transformed = transform_data(filtered)
save(transformed)

While this works well for small datasets, it becomes inefficient when processing millions of records because every intermediate result is stored in memory.

A better approach is to use generator-based pipelines.

Generators allow data to flow through each processing stage one item at a time, making your code more memory-efficient, composable, and easier to maintain.

In this article, we'll build several generator pipelines ranging from simple text processing to ETL and computer vision workloads.

What Is a Generator Pipeline?

A generator pipeline consists of multiple independent stages.

Each stage:

Receives an iterable (usually another generator).
Processes each item.
Produces items using yield.

The output of one stage becomes the input of the next.

Read -> Filter -> Transform -> Save / Output" width="799" height="416">

One of the biggest advantages is that only one item typically moves through the pipeline at a time.

Example 1: Processing a Large Text File

Suppose you have a multi-gigabyte log file and want to:

Ignore comments
Remove whitespace
Convert everything to uppercase

Each step becomes its own generator.

def read_lines(filename):
    with open(filename) as f:
        for line in f:
            yield line


def remove_comments(lines):
    for line in lines:
        if not line.startswith("#"):
            yield line


def strip_lines(lines):
    for line in lines:
        yield line.strip()


def uppercase(lines):
    for line in lines:
        yield line.upper()

Connecting them is straightforward:

pipeline = uppercase(
    strip_lines(
        remove_comments(
            read_lines("log.txt")
        )
    )
)

for line in pipeline:
    print(line)

Notice that nothing happens until the final loop starts consuming the generator.

At any point, only a single line is being processed.

Example 2: Building a Simple ETL Pipeline

Generator pipelines are a natural fit for ETL (Extract, Transform, Load).

Let's define a simple model.

from dataclasses import dataclass


@dataclass
class User:
    id: int
    name: str
    age: int

Extract

def extract():
    users = [
        {"id": 1, "name": "Alice", "age": 22},
        {"id": 2, "name": "Bob", "age": 17},
        {"id": 3, "name": "Charlie", "age": 35},
    ]

    for user in users:
        yield user

Filter

def filter_adults(users):
    for user in users:
        if user["age"] >= 18:
            yield user

Transform

def transform(users):
    for user in users:
        yield User(**user)

Load

def load(users):
    for user in users:
        print(user)

Putting Everything Together

load(
    transform(
        filter_adults(
            extract()
        )
    )
)

Output:

User(id=1, name='Alice', age=22)
User(id=3, name='Charlie', age=35)

Each stage has a single responsibility, making the pipeline easy to extend and test.

Example 3: Computer Vision Pipeline

Generator pipelines are especially useful in machine learning and computer vision, where images can consume significant memory.

def load_images(paths):
    for path in paths:
        image = cv2.imread(path)
        yield image


def resize(images):
    for image in images:
        yield cv2.resize(image, (224, 224))


def normalize(images):
    for image in images:
        yield image / 255.0


def predict(images, model):
    for image in images:
        yield model.predict(image[None])

Usage:

predictions = predict(
    normalize(
        resize(
            load_images(image_paths)
        )
    ),
    model,
)

for prediction in predictions:
    ...

Instead of loading every image into memory first, images are loaded, processed, and predicted one at a time.

Example 4: Processing Database Records

The same approach works for database queries.

def fetch_rows(cursor):
    while True:
        rows = cursor.fetchmany(1000)

        if not rows:
            break

        for row in rows:
            yield row

Cleaning the records:

def clean(rows):
    for row in rows:
        row["name"] = row["name"].strip()
        yield row

Saving them:

def save(rows):
    for row in rows:
        insert_into_new_db(row)

Only small batches are fetched from the database, while individual rows continue flowing through the pipeline.

Using `yield from`

Sometimes a generator simply forwards another iterable.

Instead of manually iterating:

def flatten(data):
    for lst in data:
        for item in lst:
            yield item

You can delegate using yield from.

def flatten(data):
    for lst in data:
        yield from lst

Example:

data = [[1, 2], [3, 4], [5]]

print(list(flatten(data)))

Output:

[1, 2, 3, 4, 5]

yield from makes generator composition cleaner and more readable.

Generator Expressions

For simple transformations, generator expressions are concise and expressive.

numbers = range(10)

pipeline = (
    x * x
    for x in numbers
    if x % 2 == 0
)

print(list(pipeline))

Output:

[0, 4, 16, 36, 64]

They work particularly well for lightweight pipelines.

Building Configurable Pipelines

As applications grow, it's useful to compose stages dynamically.

from collections.abc import Iterable, Callable


def run_pipeline(data: Iterable, *stages: Callable):
    for stage in stages:
        data = stage(data)
    return data

Now define a pipeline at runtime.

pipeline = run_pipeline(
    range(20),
    lambda xs: (x for x in xs if x % 2 == 0),
    lambda xs: (x * x for x in xs),
    lambda xs: (x + 1 for x in xs),
)

print(list(pipeline))

Output:

[1, 5, 17, 37, 65, 101, 145, 197, 257, 325]

This makes it easy to swap, reorder, or add processing stages without modifying existing code.

Why Use Generator Pipelines?

Generator pipelines provide several advantages over list-based processing.

Memory efficient — process one item at a time instead of storing intermediate collections.
Lazy evaluation — work happens only when data is requested.
Composable — each stage performs a single responsibility.
Reusable — stages can be mixed and matched across pipelines.
Scalable — ideal for files, database cursors, streams, APIs, and machine learning datasets.
Testable — each generator can be unit tested independently.

Where You'll See This Pattern

Generator pipelines appear in many real-world systems, including:

ETL and data engineering workflows
Log processing
Web scraping
CSV and JSON processing
Computer vision preprocessing
Machine learning data loaders
Streaming applications
API response processing

Once you start recognizing the pattern, you'll find opportunities to use it in many Python projects.

Conclusion

Python generators are more than a way to iterate over data—they're a powerful tool for building clean, modular, and memory-efficient processing pipelines.

By splitting your workflow into small generator stages, you can process datasets of virtually any size while keeping your code easy to understand, test, and extend.

If you're working with large files, databases, APIs, or AI workloads, generator pipelines are a technique worth adding to your Python toolbox.

Happy coding! 🚀

🚖 Building a Scalable Frontend Mock Architecture with MSW, Factories, and Services (Uber-Like Example)

Mohammad Rajaei Monfared — Thu, 16 Oct 2025 21:30:01 +0000

If you’ve ever built an app that depends on complex backend APIs — like a ride-sharing or delivery platform — you know the pain:

“The backend isn’t ready yet… but I still need to test my UI, maps, and user flows.”

Frontend developers often get stuck waiting for endpoints or using rigid JSON mocks that quickly become outdated.
There’s a better way.

In this article, we’ll explore how to build a scalable mock architecture for your frontend using Mock Service Worker (MSW) — the modern way to simulate APIs directly in the browser or test environment.

We’ll model a simplified Uber-like app with entities like User, Drivers, Vehicles, Wallet, MyLastTrips, and more.

🧠 Note: The entities and examples here are simplified to illustrate the architecture.
Real ride-sharing systems have more complex relationships and data flows.

🧩 Why Traditional Mocks Don’t Scale

Most frontend teams start with something simple:

// mocks/handlers.ts
rest.get('/api/drivers', (req, res, ctx) => {
  return res(ctx.json([{ id: 1, name: 'John', rating: 4.9 }]));
});

It works… until it doesn’t.
When your app grows — filters, pagination, dynamic routes, price estimates, and user-specific logic — this flat mock structure becomes unmaintainable.

The solution?
Design your mocks like a real backend, with clear layers and responsibilities.

🏗 The Layered Mock Architecture

Here’s the folder structure we’ll use:

src/
  mocks/
    handlers/
      driversHandlers.ts
      ridesHandlers.ts
    factories/
      userFactory.ts
      driversFactory.ts
      vehiclesFactory.ts
      walletFactory.ts
      myLocationsFactory.ts
      myLastTripsFactory.ts
    generators/
      carLocationsGenerator.ts
      rideRequestsGenerator.ts
      priceEstimatesGenerator.ts
      routesGenerator.ts
    services/
      ridesService.ts
      driversService.ts
      walletService.ts
    browser.ts
    server.ts

Each layer has a specific purpose:

Layer	Role	Description
`factories/`	Static seed data	Acts as your “mock database”
`generators/`	Dynamic or computed data	Produces live, random, or rule-based data
`services/`	Business logic	Simulates backend operations (search, filters, etc.)
`handlers/`	API interface	Connects MSW routes to your mock services

🧱 Step 1: Factories — The Mock Database

Factories provide static, consistent seed data.
They act like an in-memory database for your mocks.

Here’s a reusable base factory:

// factories/BaseFactory.ts
export class BaseFactory {
  constructor(seed = []) {
    this.seed = seed;
  }

  clone(value) {
    return typeof structuredClone === 'function'
      ? structuredClone(value)
      : JSON.parse(JSON.stringify(value));
  }

  createMany() {
    return this.seed.map((item) => this.clone(item));
  }

  createOne() {
    if (!this.seed.length)
      throw new Error(`${this.constructor.name} has no seed data`);
    return this.clone(this.seed[0]);
  }
}

Then, define your domain factories:

// factories/driversFactory.ts
import { BaseFactory } from './BaseFactory';

export class DriversFactory extends BaseFactory {
  constructor() {
    super([
      { id: 1, name: 'Alice', vehicleId: 101, rating: 4.9 },
      { id: 2, name: 'Bob', vehicleId: 102, rating: 4.7 },
    ]);
  }
}

Other factories might include:

UserFactory – the logged-in user data
VehiclesFactory – registered vehicles
WalletFactory – balance and transactions
MyLocationsFactory – user’s saved addresses
MyLastTripsFactory – trip history

✅ Tip: Keep this data simple and clean. It doesn’t need to be “real” — just realistic.

⚙️ Step 2: Generators — Dynamic or Computed Data

Some data can’t be static. Think about:

A driver’s live location
Price estimates that change with distance
Routes generated from coordinates

That’s where generators come in.

// generators/carLocationsGenerator.ts
import { faker } from '@faker-js/faker';

export function generateCarLocations(count = 5) {
  return Array.from({ length: count }, () => ({
    driverId: faker.number.int({ min: 1, max: 5 }),
    lat: faker.location.latitude(),
    lng: faker.location.longitude(),
    updatedAt: faker.date.recent().toISOString(),
  }));
}

You can build similar ones for:

rideRequestsGenerator – mock incoming ride requests
priceEstimatesGenerator – calculate approximate fares
routesGenerator – fake polyline routes between points

✅ Why it matters:
Generators make your mocks feel alive, perfect for testing live maps, dynamic UI updates, or ride-status screens.

🧠 Step 3: Services — Mock Backend Logic

Services combine factories and generators into domain-specific logic.

// services/ridesService.ts
import { MyLastTripsFactory } from '../factories/myLastTripsFactory';
import { generateRideRequests } from '../generators/rideRequestsGenerator';
import { generatePriceEstimates } from '../generators/priceEstimatesGenerator';

export class RidesService {
  constructor() {
    this.trips = new MyLastTripsFactory().createMany();
  }

  listMyTrips(userId) {
    return this.trips.filter((trip) => trip.userId === userId);
  }

  getActiveRideRequests() {
    return generateRideRequests(3);
  }

  getPriceEstimate(pickup, dropoff) {
    return generatePriceEstimates(pickup, dropoff);
  }
}

✅ Why it matters:
This mirrors how a real backend behaves — filtering, calculating, and combining data logically — not just serving static JSON.

🌐 Step 4: Handlers — The MSW API Layer

Now we wire everything together using Mock Service Worker (MSW):

// handlers/ridesHandlers.ts
import { rest } from 'msw';
import { RidesService } from '../services/ridesService';

const ridesService = new RidesService();

export const ridesHandlers = [
  rest.get('/api/trips', (req, res, ctx) => {
    const userId = Number(req.url.searchParams.get('userId') || 1);
    const trips = ridesService.listMyTrips(userId);
    return res(ctx.status(200), ctx.json(trips));
  }),

  rest.get('/api/price-estimate', (req, res, ctx) => {
    const pickup = req.url.searchParams.get('pickup');
    const dropoff = req.url.searchParams.get('dropoff');
    const price = ridesService.getPriceEstimate(pickup, dropoff);
    return res(ctx.status(200), ctx.json(price));
  }),
];

And connect it to your dev environment:

// mocks/browser.ts
import { setupWorker } from 'msw';
import { ridesHandlers } from './handlers/ridesHandlers';
import { driversHandlers } from './handlers/driversHandlers';

export const worker = setupWorker(...ridesHandlers, ...driversHandlers);

Start it automatically in dev mode:

if (import.meta.env.DEV) {
  const { worker } = await import('./mocks/browser');
  worker.start({ onUnhandledRequest: 'bypass' });
}

🧰 Bonus: Works in Tests and Storybook Too

This architecture is not just for local development — it also powers:

Unit/Integration Tests (via setupServer from msw/node)
Storybook (via msw-storybook-addon)
End-to-End Prototyping without a real backend

Example Storybook config:

import { initialize, mswDecorator } from 'msw-storybook-addon';
initialize();
export const decorators = [mswDecorator];

🌱 Why This Architecture Works

Benefit	Description
🧩 Separation of Concerns	Each layer (factory, generator, service) does one job
⚙️ Backend-Like Simulation	Services handle filtering, routes, and price logic
🔁 Reusability	Works in dev, tests, and Storybook
💡 Flexibility	Add or override scenarios easily (e.g., surge pricing, no drivers)
🧱 Maintainability	Add new entities (e.g., Wallet, Vehicles) without rewriting mocks

✅ Conclusion

This architecture gives you production-like realism without depending on real APIs.
Your frontend becomes faster to develop, test, and demo — even before the backend exists.

By organizing your mocks into:

🧱 Factories (static seeds)
⚙️ Generators (dynamic data)
🧠 Services (logic layer)

…and connecting them through MSW handlers, you create a self-contained virtual backend for your app.

This example used Uber-like entities such as Drivers, Vehicles, MyLocations, Wallet, and RideRequests, but the same pattern applies to any complex domain — e-commerce, fintech, IoT, you name it.

Click the links below to follow me on all platforms:

🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

A Guide to Modern Browser Storage And Data Sharing Capabilities

Mohammad Rajaei Monfared — Thu, 16 Oct 2025 20:54:50 +0000

Choosing the right browser storage can make or break your app's performance and security—here's how to get it right.

In the early days of the web, browsers were simple document viewers. Today, they are powerful application platforms. Modern web apps often feel as responsive and capable as their native counterparts, and a key reason for this is their ability to store data directly on the client-side. But with great power comes great responsibility. The choice of where and how you store data in the browser has profound implications for your application's user experience, security, and overall performance.

It's a common pitfall to reach for a familiar tool like localStorage for every problem, but not all storage mechanisms are created equal. Some are synchronous, blocking the main thread and creating a janky user experience. Others are asynchronous and scalable but come with a steeper learning curve. Some are vulnerable to cross-site scripting (XSS) attacks, while others offer a more secure, sandboxed environment. Making the wrong choice can lead to anything from a sluggish UI to a critical security breach.

This article is a practical guide to navigating the complex landscape of modern browser storage. We'll move beyond the familiar localStorage and explore the full spectrum of tools at your disposal, including SessionStorage, Cookies, IndexedDB, Service Workers, and more. For each, we'll analyze the critical trade-offs between performance and security, and establish clear best practices. By the end, you'll be equipped to choose the right storage for the right job, building faster, more secure, and more reliable web applications.

The Classics: localstorage, sessionstorage, and cookies
- LocalStorage: The Persistent Key-Value Store
- SessionStorage: The Tab-Specific Store
- Cookies: The Server's Messenger
- Quick Comparison: The Classics
The Modern Powerhouse: raw-indexeddb-endraw
- Performance: Asynchronous and Scalable
- Security: Origin-Isolated with Potential for More
- The Catch: A Complex API
- Best Practices: Use a Wrapper!
Specialized Tools for Specific Jobs
- In-Memory Storage: The Need for Speed
- URL Query Parameters: The Shareable State
- BroadcastChannel API: The Cross-Tab Communicator
Powering Offline Experiences: Service Workers and the Cache API
- The Service Worker: Your App's Network Proxy
- The Cache API: The Service Worker's Storage
Tying It All Together: Comparison and Best Practices
- At a Glance: A Comparison of Browser Storage
- Unified Best Practices
- Key Takeaways
Conclusion: Build Smarter, Not Harder

The Classics: `LocalStorage`, `SessionStorage`, and `Cookies`

Before we dive into the heavy-duty storage solutions, let's revisit the three tools that have been the bedrock of browser data persistence for years. While still useful in specific scenarios, their limitations are what drove the need for more modern APIs.

`LocalStorage`: The Persistent Key-Value Store

LocalStorage is often the first tool developers reach for when they need to save data across browser sessions. It offers a simple, synchronous API for storing key-value pairs as strings.

Performance: The biggest drawback of LocalStorage is its synchronous API. Every read or write operation blocks the main thread, which can lead to a frozen UI if you're working with large amounts of data. With a typical limit of 5-10 MB, it's easy to run into performance bottlenecks.
Security: Data in LocalStorage is accessible to any JavaScript running on the same origin. This makes it a prime target for Cross-Site Scripting (XSS) attacks. If a malicious script finds its way onto your page, it can read everything in LocalStorage. For this reason, you should never store sensitive information like JWTs, API keys, or personal user data here.
Best For: Non-sensitive, infrequently updated data, such as user interface preferences (like a theme choice) or remembering that a welcome modal has been closed.

`SessionStorage`: The Tab-Specific Store

SessionStorage is nearly identical to LocalStorage in its API, with one critical difference: its scope. Data stored in SessionStorage is isolated to the current browser tab and is cleared the moment the tab is closed.

Performance & Security: It shares the same synchronous, blocking API and XSS vulnerabilities as LocalStorage. The tab-specific isolation provides a minor security benefit by preventing scripts in other tabs from accessing the data, but the core risks remain.
Best For: Storing transient data related to a single user session within one tab. A classic example is saving partially filled form data to prevent loss on an accidental reload.

`Cookies`: The Server's Messenger

Unlike LocalStorage and SessionStorage, cookies were designed primarily for server-client communication, not client-side storage. They are automatically sent with every HTTP request to the same domain.

Performance: Because they are attached to every request, large cookies can bloat request headers and slow down your application. Their small size limit (around 4KB) also makes them unsuitable for storing any significant amount of data.
Security: Cookies are the traditional way to manage user sessions, but they come with their own set of security risks, most notably Cross-Site Request Forgery (CSRF). To mitigate this, modern applications must use the HttpOnly, Secure, and SameSite=Strict attributes. The HttpOnly flag is particularly important, as it makes the cookie inaccessible to JavaScript, providing a strong defense against XSS-based token theft.
Best For: Storing server-issued session identifiers. Use them for authentication tokens, but keep them small and secure them with the right flags. Avoid using them as a general-purpose data store.

Quick Comparison: The Classics

Feature	`LocalStorage`	`SessionStorage`	`Cookies`
Persistence	Until cleared by user	Per tab/session	Expires or session-based
Scope	Origin-wide	Tab-specific	Domain/path specific
API	Synchronous	Synchronous	N/A (sent via HTTP headers)
Capacity	~5-10 MB	~5 MB	~4 KB
Security	High XSS risk	High XSS risk	CSRF/XSS risk (mitigable)
Main Use	UI preferences	Temporary form data	Server authentication

The Modern Powerhouse: `IndexedDB`

When your application's storage needs grow beyond simple key-value pairs, or when the performance cost of LocalStorage becomes too high, it's time to turn to IndexedDB. This is a true client-side database, offering capabilities far beyond the simple storage mechanisms we've discussed so far.

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. It's the browser's answer to the limitations of LocalStorage and is the foundation for most modern, data-intensive web applications.

Performance: Asynchronous and Scalable

The single most important feature of IndexedDB is its asynchronous API. Unlike LocalStorage, operations in IndexedDB do not block the main thread. This means you can read or write large amounts of data without freezing the user interface, resulting in a smooth and responsive application. It's designed for scale, with storage limits typically in the hundreds of megabytes or even gigabytes, depending on the browser and available disk space.

Furthermore, IndexedDB stores structured data—JavaScript objects—natively. This means you don't have the overhead of serializing and deserializing JSON for every operation, which can be a significant performance gain in applications with frequent data access.

Security: Origin-Isolated with Potential for More

Like other browser storage, IndexedDB is isolated by origin, which prevents other websites from accessing your data. However, it is still accessible to any JavaScript running on your page, which means it's vulnerable to XSS attacks if your application has a security flaw.

For sensitive data, the best practice is to add a layer of client-side encryption. You can use the built-in Web Crypto API to encrypt data before you store it in IndexedDB, ensuring that even if an attacker gains access to the database, the data remains unreadable.

The Catch: A Complex API

With great power comes... a more complex API. The native IndexedDB API is event-based and requires you to manage transactions, versioning, and schemas manually. It can be cumbersome to work with directly, which has led to the development of several excellent wrapper libraries.

Best Practices: Use a Wrapper!

For almost all use cases, it's highly recommended to use a library like Dexie.js or idb. These wrappers provide a clean, modern, Promise-based API that handles the underlying complexity of IndexedDB transactions and schema management. They make working with IndexedDB feel almost as simple as working with LocalStorage, while retaining all of its performance benefits.

Best For:

Applications that need to store large amounts of structured data.
Offline-first Progressive Web Apps (PWAs).
Caching complex API responses to reduce network requests.
Any scenario where the synchronous nature of LocalStorage would cause performance issues.

Specialized Tools for Specific Jobs

While IndexedDB is the champion of large-scale persistent storage, not all data needs to be stored in a database. Sometimes you need the fastest possible access for temporary data, a way to share state in a URL, or a method to communicate between open tabs. For these jobs, we have a set of specialized tools.

In-Memory Storage: The Need for Speed

Not all data needs to survive a page refresh. The fastest storage available is the computer's RAM, which you can access directly by storing data in JavaScript variables or more structured state management solutions like Redux or Zustand stores.

Performance: Unbeatable. Access is nearly instantaneous, with no serialization overhead. This is where your application's active state should live.
Security & Persistence: Being volatile is its key feature. Since the data is wiped on every page load, the security exposure is minimal. It's perfect for data that is fetched and used in a single session.
Best For: Caching frequently accessed data that can be easily re-fetched, managing the real-time state of your UI, and holding temporary data that doesn't need to be persisted.

URL Query Parameters: The Shareable State

Sometimes, the state of your application needs to be shareable. Think of applying a set of filters on an e-commerce site and wanting to send the results to a friend. This is the perfect use case for URL query parameters.

Performance: There's no real I/O cost, but be mindful of URL length limits (generally around 2000 characters), as excessively long URLs can cause issues.
Security: This is the most public form of state. The data is visible in the user's browser history, server logs, and to anyone they share the link with. Never, ever put sensitive information in a URL.
Best For: Small, non-sensitive pieces of data that make a page's state shareable and bookmarkable, such as search queries, filter settings, or pagination info (?page=2).

`BroadcastChannel` API: The Cross-Tab Communicator

What happens when a user logs out in one tab? Ideally, they should be logged out in all other open tabs of your application as well. This is the problem the BroadcastChannel API was designed to solve.

Performance: It's a lightweight, event-driven API that allows different browser tabs, windows, or iframes of the same origin to send and receive messages.
Security: Channels are scoped to a single origin, but any script on that origin can listen in. Therefore, you should never broadcast sensitive data. Instead, send simple signals or notifications, like "user-logged-out" or "theme-changed-to-dark".
Best For: Syncing state across multiple open tabs. It's the modern, efficient way to ensure a consistent user experience, especially for actions like authentication, theme changes, or real-time notifications.

For more detailed information, please visit Mastering Cross-Window Communication in JavaScript: postMessage vs BroadcastChannel Explained

Powering Offline Experiences: Service Workers and the Cache API

What truly separates a modern web app from a traditional website is the ability to function without a network connection. This is the domain of the Service Worker, a powerful technology that acts as a programmable proxy between your application, the browser, and the network.

The Service Worker: Your App's Network Proxy

A Service Worker is a type of Web Worker that runs on a separate thread from your main application. It can intercept and handle network requests, manage a cache of responses, and enable push notifications. Because it runs independently of your UI, it can continue to work even when the user has closed the application's tab, enabling features like background sync.

Service Workers are the cornerstone of Progressive Web Apps (PWAs), allowing them to provide a reliable, app-like experience even on a flaky network connection or when completely offline.

The `Cache API`: The Service Worker's Storage

While a Service Worker can use IndexedDB, its primary storage tool is the Cache API. This is a specialized storage mechanism designed for holding HTTP request and response pairs. It allows you to programmatically save network responses and serve them directly from the cache, bypassing the network entirely.

Performance: The performance implications are massive. By serving assets and API responses from the cache, you can make your application load almost instantly on repeat visits. Caching strategies like stale-while-revalidate (serving from the cache while fetching an update in the background) provide the perfect balance of speed and freshness.
Security: Service Workers are highly secure. They can only be registered on pages served over HTTPS, which prevents man-in-the-middle attacks. They run in a sandboxed environment and have no direct access to the DOM, which limits their exposure to XSS attacks. However, you must still be careful not to cache sensitive, user-specific data, as the cache is persistent and could be accessed if the application's security is compromised.
Best For:
- Creating offline-first applications.
- Caching application shell assets (HTML, CSS, JS) for instant loading.
- Caching API responses to reduce network dependency and improve perceived performance.

Tying It All Together: Comparison and Best Practices

We've explored a wide range of browser storage options, each with its own strengths and weaknesses. Choosing the right one depends on a careful balance of performance, security, and persistence requirements. To make this easier, let's summarize our findings.

At a Glance: A Comparison of Browser Storage

Storage Type	Security Level	Performance Impact	Persistence	Size Limit	Async	Typical Use Case
In-Memory	✅ Secure (Volatile)	⚡ Fastest	❌ None	RAM Limit	✅ N/A	Temporary UI State
LocalStorage	❌ High XSS Risk	🚫 Blocking I/O	✅ Permanent	~5MB	❌ No	Non-sensitive Preferences
SessionStorage	⚠️ High XSS Risk	🚫 Blocking I/O	⚪ Per Tab	~5MB	❌ No	Single-tab Session Data
Cookies	⚠️ CSRF/XSS Risk	🚫 Slows HTTP	✅ Expires	~4KB	✅ N/A	Server Session Tokens
IndexedDB	⚪ XSS Risk (Encrypt!)	✅ Async, Scalable	✅ Permanent	100MB+	✅ Yes	Large/Structured Data
Cache API	✅ Sandboxed (HTTPS)	✅ Async, Fast	✅ Evictable	Large	✅ Yes	Offline Assets & Responses
URL Params	❌ Publicly Visible	⚡ Light	⚪ Shareable	~2KB	✅ N/A	Shareable Filter State
BroadcastChannel	⚠️ Cross-tab Exposure	⚡ Fast (Events)	❌ None	N/A	✅ Yes	Cross-tab Syncing

Unified Best Practices

Regardless of the tool you choose, a few universal principles will help you build more secure and performant applications.

🧱 Security Principles

Never Store Sensitive Data in Client-Accessible Storage: This includes JWTs, API keys, passwords, or personal information. LocalStorage, SessionStorage, and IndexedDB are all readable by any JavaScript on the page.
Use HttpOnly Cookies for Auth Tokens: This is the single most effective defense against token theft via XSS, as it makes the cookie inaccessible to JavaScript.
Encrypt Sensitive Local Data: If you must store sensitive information client-side (e.g., in IndexedDB for an offline app), use the Web Crypto API to encrypt it first.
Assume All Client-Side Data Can Be Manipulated: Always validate data on the server before processing it.

⚡ Performance Principles

Async Over Sync: Always prefer asynchronous APIs like IndexedDB and the Cache API over synchronous ones like LocalStorage to avoid blocking the main thread.
Lazy Load Your Data: Don't eagerly load large amounts of data into storage. Fetch and cache it as needed.
Use In-Memory for Hot Data: For data that is accessed frequently, keep it in an in-memory state variable for the fastest possible access. Persist it to storage only when necessary.
Be Mindful of Quotas: Monitor storage usage with navigator.storage.estimate() and be prepared to handle quota errors gracefully.

Key Takeaways

LocalStorage is not your default: Its synchronous nature and security risks make it a poor choice for anything but the simplest, non-sensitive data.
IndexedDB is the modern standard: For any significant amount of client-side data, IndexedDB (used with a wrapper like Dexie.js) is the best choice for performance and scalability.
HttpOnly cookies are for authentication: They are the most secure place to store session tokens.
Service Workers are for offline: The Cache API combined with a Service Worker is the key to building reliable, offline-first applications.
Security is paramount: Never trust the client. Encrypt sensitive data and use HttpOnly cookies for authentication.

Conclusion: Build Smarter, Not Harder

The landscape of browser storage is far richer and more nuanced than just localStorage. Choosing the right storage solution is not about finding a single tool that does everything; it's about understanding the trade-offs and composing a strategy that fits your application's unique needs. The modern web is built on a foundation of smart, hybrid approaches.

An application might use HttpOnly cookies for authentication, IndexedDB to store complex data for offline use, in-memory variables for real-time UI state, and the BroadcastChannel API to keep multiple tabs in sync. This is not over-engineering; it's a sign of a mature, robust architecture.

As browsers continue to evolve, the trend is clear: we are moving towards more secure, asynchronous, and origin-isolated storage models. By embracing these modern APIs and understanding their underlying principles, you can build the next generation of web applications—apps that are not only fast and feature-rich but also secure and reliable, no matter the user's device or network condition. The power is in your hands; it's time to build smarter.

Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

Your support and engagement mean the world to me.

Let's create a community of knowledge enthusiasts and professionals striving for excellence and continuous learning.

Click the links below to follow me on all platforms:
🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

#WebSecurity #WebPerformance #WebDevelopment #BrowserAPIs #Frontend #JavaScript #IndexedDB #Cookies #LocalStorage #PWAs #WebDevTips

The Ultimate Guide to Mastering `useEffect`

Mohammad Rajaei Monfared — Wed, 15 Oct 2025 14:24:38 +0000

From lifecycle chaos to declarative harmony, this guide demystifies React's most powerful Hook.

Introduction

The useEffect Hook is arguably one of the most important yet misunderstood parts of modern React. For developers coming from class-based components, it feels like a strange new paradigm. For newcomers, it can seem like a magic box where you put any code that "doesn't fit" in the render. But useEffect is far more than that—it's a precise tool for synchronizing your component with external systems.

This guide breaks down everything you need to know, from the fundamentals of component lifecycles to advanced patterns and common pitfalls. By the end, you'll not only understand how useEffect works but also why it was designed and when to use it effectively. Let's dive in and transform useEffect from a source of confusion into your most reliable ally.

1. Understanding the React Component Lifecycle
- Before Hooks: The Classic Lifecycle Methods
- After Hooks: useEffect Unifies the Lifecycle
- A Visual Timeline of the Functional Component Lifecycle
- Why Was useEffect Introduced?
2. The Purpose of useEffect — What It Really Does
- Common Examples of Side Effects
- It Runs After the Paint
- Misconception: It’s Not for All Logic
3. The Dependencies Array Demystified
- The Three Modes of useEffect
- How React Compares Dependencies
- How to Fix Shallow Comparison Issues
- Tips to Avoid Common Pitfalls
4. Cleanup Functions and the “Return” Mystery
- Why useEffect Can Return a Function
- When Does the Cleanup Function Run?
- Real-World Cases for Cleanup
- Why Cleanup Prevents Memory Leaks
5. Multiple useEffects: Execution and Cleanup Order
- Execution Order: Top to Bottom
- Cleanup Order: Bottom to Top (Reverse Order)
- Why Splitting Concerns is Cleaner
6. Debugging useEffect Like a Pro
- Common Pitfalls and How to Spot Them
- Use the ESLint Rule (and When to Ignore It)
- Tracing with Logs and Custom Hooks
- React DevTools Profiler
- Tips: useRef for Tracking
7. When Not to Use useEffect
- Anti-Pattern: Unnecessary State Mirroring
- Anti-Pattern: Computations and Derived State
- Prefer Event Handlers for User Actions
8. Practical Examples & Patterns
- Pattern: Data Fetching with AbortController
- Pattern: Syncing the Browser Tab Title
- Pattern: Custom Hooks Abstraction (e.g., useLocalStorage)
9. Wrap-Up
- useEffect Cheat Sheet
- Visual Summary
- The Future of Effects
Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

1. Understanding the React Component Lifecycle

Before we can master useEffect, we need to travel back in time to the era of class components. The component lifecycle was a set of distinct methods that gave us hooks into a component's life, from birth to death.

Before Hooks: The Classic Lifecycle Methods

In class components, side effects like fetching data, setting up subscriptions, or manually changing the DOM were handled by specific lifecycle methods:

componentDidMount(): Fired only once, immediately after the component is mounted (inserted into the tree). This was the perfect place for initial data fetches or setting up subscriptions.
componentDidUpdate(prevProps, prevState): Called on every re-render, but not for the initial render. Logic here often required checking if props or state had changed to avoid unnecessary re-fetches.
componentWillUnmount(): Called right before the component is destroyed. This was the place to clean up subscriptions, timers, or any other lingering side effects to prevent memory leaks.

This separation often led to related logic being split across different methods, making components harder to follow.

After Hooks: `useEffect` Unifies the Lifecycle

The useEffect Hook simplifies this by unifying these concepts into a single API. It runs after React renders the component, allowing you to perform side effects without blocking the browser paint.

Here’s how it maps to the old lifecycle methods:

componentDidMount: An effect with an empty dependency array ([]) runs only once, after the initial render.
componentDidUpdate: An effect with dependencies in its array ([prop, state]) runs after the initial render and any time those dependencies change.
componentWillUnmount: The cleanup function returned from an effect serves this purpose.

This new model encourages you to group related logic together, not by lifecycle event, but by concern.

A Visual Timeline of the Functional Component Lifecycle

Why Was `useEffect` Introduced?

The shift to Hooks wasn't just for a cleaner syntax. It solved fundamental problems with class components:

Separation of Concerns: In classes, a single componentDidMount might contain logic for data fetching, setting up event listeners, and logging. useEffect allows you to split these into separate, independent effects. Each effect handles one concern, making the code more modular and readable.
Declarative Side Effects: Instead of issuing imperative commands at different points in time (mount, update), you declare the side effects that should be synchronized with your component's state. You tell React, “When this data changes, run this effect.” React handles the when and how, making your code less error-prone and easier to reason about.

2. The Purpose of `useEffect` — What It Really Does

The official React documentation defines useEffect as a way to perform side effects in function components. But what exactly is a “side effect”?

Definition: A side effect is any interaction with the “outside world” that occurs outside of a component’s render. If your component is a pure function, its only job is to return JSX based on its props and state. Anything else is a side effect.

Common Examples of Side Effects

useEffect is your go-to tool for managing these interactions. Here are the most common use cases:

Fetching data from an API: Retrieving remote data and updating component state.
Setting up subscriptions: Connecting to a WebSocket or listening to a real-time service.
Manual DOM manipulation: Directly changing the DOM, like focusing an input field or integrating with a non-React library.
Logging: Sending analytics or error reports to a logging service.
Using browser APIs: Interacting with localStorage, Cookies, document.title, or timers like setTimeout and setInterval.

It Runs After the Paint

A critical detail that often trips up developers is when useEffect runs. Unlike componentDidMount and componentDidUpdate, which could block the browser from painting, useEffect is deferred. It runs after React has rendered your component and the browser has painted the result to the screen.

This is a huge performance benefit. It ensures that side effects, which can be slow, don't make your UI feel sluggish. The user sees the updated UI first, and then the effect runs in the background.

Misconception: It’s Not for All Logic

Because useEffect is so versatile, it's tempting to put any and all logic inside it. This is a common anti-pattern. useEffect is for synchronizing with external systems. If you can calculate a value or derive state directly during the render, you don't need an effect. Using it for simple computations adds unnecessary complexity and can lead to bugs.

Rule of Thumb: If your logic doesn't interact with the outside world, it probably doesn't belong in useEffect.

3. The Dependencies Array Demystified

The second argument to useEffect is the dependencies array. This array is the key to controlling when your effect runs. Get it right, and your components will be efficient and predictable. Get it wrong, and you'll face bugs like infinite loops and stale data.

The Three Modes of `useEffect`

You can think of the dependency array as having three primary modes:

No Dependency Array: useEffect(() => { ... })
- When it runs: After the initial render and every single re-render.
- Why it's often bad: This can be inefficient and dangerous. If the effect triggers a state update, it will cause a re-render, which will trigger the effect again, leading to an infinite loop. Use this mode with extreme caution.
Empty Array: useEffect(() => { ... }, [])
- When it runs: Only once, after the initial render.
- This is the equivalent of componentDidMount. It’s perfect for one-time setup logic, like fetching initial data or setting up a subscription that doesn't depend on any props or state.
Array with Dependencies: useEffect(() => { ... }, [prop1, stateValue])
- When it runs: After the initial render and any time a value in the dependency array changes.
- This is the most common and powerful mode. It lets you synchronize your component with a specific piece of data.

How React Compares Dependencies

React performs a shallow comparison of the items in the dependency array. It checks if oldValue === newValue for each dependency.

For primitive values (strings, numbers, booleans), this works as you'd expect. 5 === 5 is true, but 5 === 6 is false.
For reference values (objects, arrays, functions), it checks if the reference itself has changed, not the contents. A new object or array is created on every render, so {} !== {}. This is a classic source of infinite loops.

// ⚠️ Anti-pattern: This will cause an infinite loop!
function MyComponent() {
  const [options, setOptions] = useState({});
  useEffect(() => {
    // Some logic
  }, [options]); // `options` is a new object on every render
}

How to Fix Shallow Comparison Issues

So, how do you depend on an object or array without causing an infinite loop? Here are the recommended solutions:

1. Memoize the Dependency with useMemo

If you need to depend on an object or array that is calculated during render, wrap it in useMemo. This ensures that the object's reference only changes when its own underlying dependencies change.

// ✅ Correct: Memoize the object
function MyComponent({ filterSettings }) {
  // `options` will only be a new object when `filterSettings` changes
  const options = useMemo(() => ({
    filter: filterSettings,
    includeDrafts: false,
  }), [filterSettings]);

  useEffect(() => {
    // This effect now only runs when `options` actually changes
  }, [options]);
}

2. Depend on Primitive Values

The simplest solution is often the best. If your effect only needs a few properties from an object, depend on those properties directly. Primitives are compared by value, so this is always safe.

// ✅ Correct: Depend on the primitive value
function MyComponent({ user }) {
  useEffect(() => {
    console.log(`User ID is: ${user.id}`);
  }, [user.id]); // Depend on `user.id`, not the whole `user` object
}

3. Other Advanced Solutions

JSON.stringify: As a quick fix, you can serialize the object into a string: [JSON.stringify(options)]. This works but can be inefficient for large objects and may not handle all edge cases (like key order).
Deep Comparison Hooks: You can find or create a custom hook (e.g., useDeepCompareEffect) that uses a utility like lodash.isEqual to perform a deep comparison instead of a shallow one. This is a powerful but often unnecessary abstraction.

Tips to Avoid Common Pitfalls

Stale Closures: If you use a state variable or prop inside an effect but forget to include it in the dependency array, the effect will “close over” the initial value of that variable. It will never see the updated value, leading to bugs. The eslint-plugin-react-hooks package is essential for catching this.
Infinite Loops: Always be careful with objects, arrays, and functions in the dependency array. If you must use them, ensure they are stable between renders. Use useCallback for functions and useMemo for objects/arrays to memoize them. > Pro Tip: If your effect doesn't use any props or state, give it an empty dependency array []. If it does, include every one of them in the array. Let the linter guide you.

4. Cleanup Functions and the “Return” Mystery

Many side effects need to be undone. If you set up a subscription, you need to unsubscribe. If you start a timer, you need to clear it. This is where the useEffect cleanup function comes in. It’s the componentWillUnmount of the Hooks world, but much more powerful.

Why `useEffect` Can Return a Function

If you return a function from your useEffect callback, React will store it and run it at the appropriate time. This design is brilliant because it keeps the logic for setting up and tearing down an effect right next to each other.

useEffect(() => {
  // The effect logic: runs after every render where dependencies change
  const timerId = setTimeout(() => {
    console.log("Timer fired!");
  }, 1000);

  // The cleanup function: returned by the effect
  return () => {
    console.log("Clearing timer...");
    clearTimeout(timerId);
  };
}, []); // Empty array means this effect runs once

When Does the Cleanup Function Run?

This is a key point of confusion. The cleanup function runs in two scenarios:

Before the effect runs again: If your dependencies change and the effect is about to re-run, React first runs the cleanup function from the previous render. This ensures you don't have multiple subscriptions or timers running at once.
On unmount: When the component is removed from the DOM, React runs the cleanup function from the last render.

This behavior ensures that your effects are always cleaned up, preventing what are sometimes called “zombie effects”—lingering side effects from a component that is no longer on the screen.

Real-World Cases for Cleanup

Clearing timeouts or intervals: As shown above, clearTimeout and clearInterval are essential to prevent timers from firing after a component has unmounted.
Unsubscribing from events or sockets: If you use addEventListener or connect to a WebSocket, you must remove the listener or close the connection to avoid memory leaks and unnecessary processing.
Canceling pending requests: For data fetching, you can use an AbortController to cancel a network request if the component unmounts or the dependencies change before the request completes. This prevents you from trying to update the state of an unmounted component.

Why Cleanup Prevents Memory Leaks

Without cleanup, your application would slowly degrade. Event listeners would pile up, subscriptions would remain active, and timers would fire unexpectedly, all consuming memory and CPU cycles for components that no longer exist. The useEffect cleanup function provides a simple, reliable pattern to keep your application healthy and performant.

5. Multiple `useEffect`s: Execution and Cleanup Order

A single component can have multiple useEffect hooks. This is a powerful feature for separating unrelated logic. But when you have more than one, it's important to understand the order in which they run.

Execution Order: Top to Bottom

React executes useEffect hooks in the same order they are declared in your component.

function MyComponent() {
  useEffect(() => {
    console.log("First effect runs");
  }, []);

  useEffect(() => {
    console.log("Second effect runs");
  }, []);

  return <div>...</div>;
}

// Console output on mount:
// "First effect runs"
// "Second effect runs"

This predictable, top-to-bottom order allows you to orchestrate side effects that might depend on each other, although it's generally better to keep them independent.

Cleanup Order: Bottom to Top (Reverse Order)

Here's the interesting part: the cleanup functions run in the reverse order of the effects. When the component unmounts (or before a re-run), React will clean up the second effect, then the first.

function MyComponent() {
  useEffect(() => {
    console.log("First effect setup");
    return () => console.log("First effect cleanup");
  }, []);

  useEffect(() => {
    console.log("Second effect setup");
    return () => console.log("Second effect cleanup");
  }, []);

  return <div>...</div>;
}

// On mount:
// "First effect setup"
// "Second effect setup"

// On unmount:
// "Second effect cleanup"
// "First effect cleanup"

Think of it like a stack: the last effect that was set up is the first one to be torn down. This LIFO (Last-In, First-Out) order ensures that dependencies are cleaned up correctly.

Why Splitting Concerns is Cleaner

The ability to use multiple useEffect hooks is the primary reason Hooks are so good at promoting separation of concerns. Instead of a monolithic componentDidMount that does everything, you can have a dedicated effect for each piece of side-effect logic.

Example: Separating Data Fetching from UI Updates

Imagine you need to fetch data and also update the document title based on that data.

function Post({ postId }) {
  const [post, setPost] = useState(null);

  // Effect 1: Handles data fetching
  useEffect(() => {
    const controller = new AbortController();
    fetch(`/api/posts/${postId}`, { signal: controller.signal })
      .then(res => res.json())
      .then(data => setPost(data));

    return () => controller.abort(); // Cleanup for this effect
  }, [postId]);

  // Effect 2: Handles updating the document title
  useEffect(() => {
    if (post) {
      document.title = post.title;
    }
  }, [post]); // Runs only when the `post` state changes

  if (!post) {
    return <div>Loading...</div>;
  }

  return <h1>{post.title}</h1>;
}

This is incredibly clean:

The first effect is solely responsible for fetching data. Its dependency is postId.
The second effect is solely responsible for a UI side effect (updating the title). Its dependency is post. The two pieces of logic are completely decoupled.

6. Debugging `useEffect` Like a Pro

Even with a solid understanding, useEffect can still be a source of bugs. Knowing how to debug it effectively is a superpower. Here are common issues and how to solve them.

Common Pitfalls and How to Spot Them

Infinite Loops:
- Symptom: Your app becomes unresponsive, the fan kicks on, and the browser might crash.
- Cause: An effect is updating state, which causes a re-render, which triggers the effect again. This usually happens when a dependency is an object, array, or function that is re-created on every render.
- Fix: Memoize reference-type dependencies with useMemo or useCallback. For state updates, use the functional update form (setState(prev => ...)), which can sometimes remove the need to depend on the state itself.
Missing Dependencies:
- Symptom: The effect doesn't re-run when you expect it to. Data becomes stale.
- Cause: You used a prop or state variable inside the effect but didn't add it to the dependency array. The effect has a "stale closure" over the old value.
- Fix: Turn on the react-hooks/exhaustive-deps ESLint rule. It's your best friend for catching this. Trust the linter; it's almost always right.
Stale State in Async Operations:
- Symptom: An async function (like a setTimeout callback) reads a state variable, but it sees an old value.
- Cause: The closure was created when the effect ran, capturing the state at that moment.
- Fix: Use useRef to store a mutable value that can be read at any time without re-triggering the effect. Or, refactor to include the state in the dependency array and properly clean up the effect.

Use the ESLint Rule (and When to Ignore It)

The react-hooks/exhaustive-deps ESLint rule is a lifesaver. It statically analyzes your useEffect calls and warns you about missing dependencies.

99% of the time, you should follow its advice.

When is it okay to ignore it? Very rarely. One legitimate case is when you intentionally want to capture the initial value of a prop and never react to its changes. Even then, it's often cleaner to store that value in a useRef.

// To ignore, add this comment. But think twice!
// eslint-disable-next-line react-hooks/exhaustive-deps

Tracing with Logs and Custom Hooks

Simple Logging: The easiest way to see when an effect runs and cleans up.

useEffect(() => {
  console.log('Effect ran with value:', myValue);
  return () => {
    console.log('Cleanup for value:', myValue);
  };
}, [myValue]);

Custom useTraceUpdate Hook: Create a custom hook to see exactly which prop caused an effect to re-run.

import { useEffect, useRef } from 'react';

function useTraceUpdate(props) {
  const prev = useRef(props);
  useEffect(() => {
    const changedProps = Object.entries(props).reduce((ps, [k, v]) => {
      if (prev.current[k] !== v) {
        ps[k] = [prev.current[k], v];
      }
      return ps;
    }, {});
    if (Object.keys(changedProps).length > 0) {
      console.log('Changed props:', changedProps);
    }
    prev.current = props;
  });
}

React DevTools Profiler

The React DevTools are indispensable. Use the Profiler to record a user interaction and see exactly why your components re-rendered. The "Why did this render?" checkbox in the component inspector is a great starting point. For effects, the Profiler's flamegraph can help you spot long-running effects that might be slowing down your app.

Image Ref: https://legacy.reactjs.org

Tips: `useRef` for Tracking

Sometimes you need to access the previous value of a prop or state inside an effect. useRef is perfect for this. Since updating a ref doesn't trigger a re-render, you can use it to store values across renders without affecting the component's lifecycle.

function MyComponent({ count }) {
  const prevCountRef = useRef();

  useEffect(() => {
    prevCountRef.current = count; // Store the current count for the next render
  }); // No dependency array, so this runs on every render

  const prevCount = prevCountRef.current;
  return <h1>Now: {count}, before: {prevCount}</h1>;
}

7. When Not to Use `useEffect`

The most powerful lesson is often learning what a tool is not for. Overusing useEffect can lead to complex, inefficient, and buggy components. The golden rule is: if it can be done during render, don’t put it in useEffect.

Anti-Pattern: Unnecessary State Mirroring

A common mistake is to use useEffect to update a state variable in response to a prop change.

// ❌ Anti-pattern
function UserProfile({ user }) {
  const [name, setName] = useState(user.name);

  useEffect(() => {
    setName(user.name); // Mirrors the prop in state
  }, [user.name]);

  return <h1>{name}</h1>;
}

This is redundant. You already have user.name from props. The effect adds an unnecessary re-render and makes the data flow confusing.

// ✅ Correct: Derive state directly from props
function UserProfile({ user }) {
  // No need for an effect or separate state
  return <h1>{user.name}</h1>;
}

Anti-Pattern: Computations and Derived State

Don't use effects for calculations that can be done directly during rendering.

// ❌ Anti-pattern
function ShoppingCart({ items }) {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    const newTotal = items.reduce((sum, item) => sum + item.price, 0);
    setTotal(newTotal);
  }, [items]);

  return <div>Total: ${total}</div>;
}

This is overly complex. The total can be calculated on every render. If the calculation is expensive, use useMemo to memoize it, but still don't use useEffect.

// ✅ Correct: Calculate during render
function ShoppingCart({ items }) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  return <div>Total: ${total}</div>;
}

// ✅ Correct (for expensive calculations)
function ShoppingCart({ items }) {
  const total = useMemo(() => {
    return items.reduce((sum, item) => sum + item.price, 0);
  }, [items]);
  return <div>Total: ${total}</div>;
}

Prefer Event Handlers for User Actions

Side effects should be caused by a render, not a user event. If a user action (like clicking a button) needs to trigger a state change, do it directly in the event handler.

// ❌ Anti-pattern
function MyForm() {
  const [value, setValue] = useState('');
  const [submittedValue, setSubmittedValue] = useState('');

  useEffect(() => {
    if (submittedValue) {
      // send to API
    }
  }, [submittedValue]);

  return <button onClick={() => setSubmittedValue(value)}>Submit</button>;
}

This is indirect. The state change is just a trigger for the effect. The logic belongs in the event handler itself.

// ✅ Correct
function MyForm() {
  const [value, setValue] = useState('');

  function handleSubmit() {
    // send to API directly
  }

  return <button onClick={handleSubmit}>Submit</button>;
}

By avoiding these anti-patterns, you keep your components simpler, more predictable, and more performant.

8. Practical Examples & Patterns

Theory is great, but code is better. Let's look at some common, production-ready patterns for useEffect.

Pattern: Data Fetching with `AbortController`

This is the canonical example of a robust data fetching effect. It handles loading and error states, and it cancels the request if the component unmounts or the userId changes.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    const { signal } = controller;

    setLoading(true);
    setError(null);

    fetch(`https://api.example.com/users/${userId}`, { signal })
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch');
        return res.json();
      })
      .then(data => setUser(data))
      .catch(err => {
        if (err.name !== 'AbortError') {
          setError(err.message);
        }
      })
      .finally(() => setLoading(false));

    // Cleanup function to abort the request
    return () => controller.abort();
  }, [userId]);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;

  return <h1>{user?.name}</h1>;
}

Pattern: Syncing the Browser Tab Title

A simple but effective use case. This effect synchronizes an external part of the browser (the tab title) with the component's state.

function useDocumentTitle(title) {
  useEffect(() => {
    // Store the original title so we can restore it on unmount
    const originalTitle = document.title;
    document.title = title;

    return () => {
      document.title = originalTitle;
    };
  }, [title]);
}

// Usage in a component
function MyPage() {
  useDocumentTitle('My Awesome Page');
  return <div>...</div>;
}

Pattern: Custom Hooks Abstraction (e.g., `useLocalStorage`)

If you find yourself writing the same useEffect logic repeatedly, it's time to extract it into a custom hook. This is one of the most powerful features of Hooks.

import { useState, useEffect } from 'react';

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.log(error);
      return initialValue;
    }
  });

  useEffect(() => {
    try {
      window.localStorage.setItem(key, JSON.stringify(storedValue));
    } catch (error) {
      console.log(error);
    }
  }, [key, storedValue]);

  return [storedValue, setStoredValue];
}

// Usage in a component
function Settings() {
  const [theme, setTheme] = useLocalStorage('theme', 'light');

  return (
    <select value={theme} onChange={e => setTheme(e.target.value)}>
      <option value="light">Light</option>
      <option value="dark">Dark</option>    </select>
  );
}

9. Wrap-Up

Mastering useEffect is a journey from understanding its rules to developing an intuition for its purpose. It’s not just a replacement for lifecycle methods; it’s a fundamentally different way of thinking about synchronizing your component with the world outside React.

`useEffect` Cheat Sheet

Use it for: Side effects (data fetching, subscriptions, manual DOM changes).
How to control it: The dependency array is key.
- []: Runs once on mount.
- [dep]: Runs when dep changes.
- No array: Runs on every render (use with caution!).
How to clean up: Return a function from the effect. It runs before the next effect or on unmount.
When to avoid it: For derived state or simple computations. If you can calculate it during render, do it.

Visual Summary

The Future of Effects

The React team is always exploring ways to make effects even better. While nothing is set in stone, future versions of React might introduce new APIs or refine the behavior of useEffect to make it even more intuitive and less error-prone. Staying engaged with the React community will keep you prepared for what's next.

By following these principles, you can write cleaner, more efficient, and more predictable React components. Happy coding!

Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

Your support and engagement mean the world to me.

Let's create a community of knowledge enthusiasts and professionals striving for excellence and continuous learning.

Click the links below to follow me on all platforms:
🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

I’m committed to providing the most up-to-date and relevant information.

As things evolve or new insights emerge, I may revisit and update this article to ensure it remains a valuable resource.

DEV Community: Mohammad Rajaei Monfared

Are AI-Generated Videos Rewriting Our Understanding of Physics?

How synthetic reality may influence human intuition about motion, gravity, and causality

Humans Do Not See Reality Directly

The Brain Learns Physics From Experience

What Changes When Videos Become Physically Incorrect?

Pilots

Gamers

But There Is an Important Difference

The Same Question Was Asked About Cartoons

The New Problem: Loss of Reality Labels

Could This Affect Future Generations?

The Bigger Risk Is Not Physics — It Is Trust

Implications for Software Engineers Building AI Systems

1. Provenance Metadata

2. Watermarking

3. Physics-Aware Generation

The Future: Synthetic Reality Needs Synthetic Literacy

Final Thoughts

How I Refactored a Distributed Hardware Control System into a Reusable Framework

1. The Day Scripts Stopped Scaling

2. Understanding the Hardware Stack

3. The First Design: Simple, But Naive

The Original Request Flow

4. The Architectural Smells

5. The Wrong Refactor: Abstract Everything

6. Designing the Architecture I'd Build Today

The Refactored Architecture

Why the Controller Exists

Why the Machine Agent Exists

Why the Job Queue Exists (The Game Changer)

Why the Transport Layer is Isolated

Why Recipes are Separated from Workflows

7. Why This Design Scales Better

8. Lessons Learned: Design Principles I Follow Today

Advanced JS Execution: Promises, Workers, and Comlink

Runnable examples

The Problem

Why It Happens

Promises resume on the same thread

The main thread has one call stack

Workers are a second JavaScript thread

How to Confirm It (Before You Fix It)

Better Solution: Move the Loop to a Worker

What each piece does

Next Step: Comlink (RPC-style Workers)

When Copying Data Is the Bottleneck: SharedArrayBuffer

Pools: Many Jobs, Not One Worker Per Click

Pick a stack by scenario

Warnings Worth Knowing

When to Use What

Conclusion

Why Your JavaScript Runs in the Wrong Order

The Problem

What developers expect

A common frustrating moment

Why It Happens

Part 1: The call stack

Part 2: JavaScript cannot wait on the stack

Part 3: The event loop in plain English

The pieces that work together

A simple analogy

The two waiting lists

What the event loop does, step by step

Where setTimeout and fetch fit

Walk through our opening example

The one rule to remember

Part 4: What async/await actually does

Manual Solution: Trace the Code by Hand

Verify in DevTools

Drawbacks of the Manual Process

Better Solution: Three Rules for Async Code

Complete Code

Breakdown

Why the "before" code breaks

activeController

AbortController and signal

The try/catch block

Real Example: Step by Step

Keystroke 1: user types r

Where `setTimeout` and `fetch` fit

Part 4: What `async/await` actually does

`activeController`

`AbortController` and `signal`

The `try/catch` block

Keystroke 1: user types `r`

Keystroke 2: user types `re` (before `r` responds)

`setTimeout(fn, 0)` does not mean "run immediately after sync code"

`await` does not run fetches in parallel

Long sync work after `await` still blocks the UI

Using `yield from`

The Classics: `LocalStorage`, `SessionStorage`, and `Cookies`

`LocalStorage`: The Persistent Key-Value Store

`SessionStorage`: The Tab-Specific Store

`Cookies`: The Server's Messenger

The Modern Powerhouse: `IndexedDB`