DEV Community: Amin Sadeghi

The Hidden Danger of Promise.all() in JavaScript

Amin Sadeghi — Sun, 01 Nov 2026 02:44:44 +0000

Promise.all() is one of the most useful tools in JavaScript for handling multiple asynchronous operations.

It allows us to run several promises concurrently and wait until all of them are fulfilled.

But there's something developers often overlook:

When one promise rejects, Promise.all() rejects immediately, but the other operations don't automatically stop.

Let's understand why this matters.

1. The Problem

Imagine fetching user information, notifications, and account settings simultaneously:

const [user, notifications, settings] = await Promise.all([
  fetchUser(),
  fetchNotifications(),
  fetchSettings()
]);

This looks perfectly fine.

But what happens if fetchNotifications() fails?

Promise.all() rejects, and execution moves to the catch block.

However, fetchUser() and fetchSettings() may still be running.

JavaScript doesn't automatically cancel the remaining promises.

This can become problematic when those operations involve expensive requests or side effects.

2. Promise.all() Doesn't Cancel Anything

Consider this example:

const delay = (ms) =>
  new Promise((resolve) => setTimeout(resolve, ms));

const task1 = delay(1000).then(() => {
  console.log("Task 1 completed");
});

const task2 = delay(2000).then(() => {
  throw new Error("Task 2 failed");
});

const task3 = delay(3000).then(() => {
  console.log("Task 3 completed");
});

try {
  await Promise.all([task1, task2, task3]);
} catch (error) {
  console.log(error.message);
}

The output will be:

Task 1 completed
Task 2 failed
Task 3 completed

Notice that Task 3 still completes after Promise.all() has already rejected.

That's because Promise rejection and operation cancellation are two different things.

3. What If You Want Every Result?

Sometimes, failing the entire operation because one promise rejects isn't what you want.

For example, when loading several independent dashboard sections, you may want successful results even if one request fails.

That's where Promise.allSettled() becomes useful:

const results = await Promise.allSettled([
  fetchUser(),
  fetchNotifications(),
  fetchSettings()
]);

for (const result of results) {
  if (result.status === "fulfilled") {
    console.log("Success:", result.value);
  } else {
    console.error("Failed:", result.reason);
  }
}

Unlike Promise.all(), it waits for every promise to settle, regardless of whether it fulfilled or rejected.

4. What If You Actually Need Cancellation?

For operations that support cancellation, such as fetch(), you can use AbortController.

const controller = new AbortController();

try {
  const results = await Promise.all([
    fetch("/api/users", {
      signal: controller.signal
    }),
    fetch("/api/notifications", {
      signal: controller.signal
    }),
    fetch("/api/settings", {
      signal: controller.signal
    })
  ]);

} catch (error) {
  controller.abort();
  throw error;
}

If one request rejects, the controller aborts the other requests that are still in progress.

Keep in mind that cancellation is cooperative. It doesn't guarantee that server-side processing has stopped.

5. Which One Should You Use?

Method	Behavior
`Promise.all()`	Rejects when the first promise rejects
`Promise.allSettled()`	Waits for every promise to settle
`Promise.race()`	Settles with the first settled promise
`Promise.any()`	Fulfills with the first fulfilled promise

Each method solves a different problem.

Choosing the right one depends on what your application expects when asynchronous operations fail.

Final Thoughts

Asynchronous JavaScript isn't just about running multiple operations at the same time.

It's also about understanding failure behavior, cancellation, and how independent operations affect each other.

A small misunderstanding about promises can create unexpected behavior in production.

Here's a question:

When building a dashboard with multiple independent API requests, would you use Promise.all() or Promise.allSettled()?

And more importantly, why?

Let's discuss.

Authentication in SPAs: 8 Ways to Handle Tokens and Sessions

Amin Sadeghi — Thu, 29 Oct 2026 19:10:17 +0000

Authentication is one of those things that looks simple until you start thinking about security, token storage, session expiration, and multiple browser tabs.

You can store a JWT in localStorage, keep an access token in memory, use HttpOnly cookies, or introduce a Backend for Frontend (BFF). Each approach comes with different trade-offs.

The important question isn't just how to log users in. It's how to keep them authenticated without exposing their credentials unnecessarily.

1. Memory + Silent Refresh

Keep the access token in JavaScript memory and the refresh token in an HttpOnly cookie.

When the access token expires, the client calls a refresh endpoint. The browser automatically sends the cookie, and the backend issues a new access token.

Trade-off: JavaScript cannot persist the access token across page reloads, so the application needs a refresh flow. The refresh endpoint must also be protected against CSRF where applicable.

2. LocalStorage + JWT

Store the access token in localStorage and attach it to API requests.

const token = localStorage.getItem("access_token");

await fetch("/api/profile", {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

This is straightforward, but any successful XSS attack that executes JavaScript in your origin may expose the token. Long-lived credentials in localStorage increase the potential impact.

3. SessionStorage + JWT

sessionStorage keeps tokens separate between tabs and normally clears them when the tab's page session ends.

It still remains accessible to JavaScript, so it does not protect tokens from XSS. Its shorter persistence is a usability and lifecycle trade-off, not a complete security solution.

4. Server-Side Sessions with HttpOnly Cookies

The backend creates a session and sends the browser a session cookie.

The session data lives on the server, often in a shared store such as Redis or a database.

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

The browser sends the cookie automatically on matching requests. This avoids exposing the session identifier to ordinary JavaScript, but cookie-based authentication requires appropriate CSRF defenses.

5. JWT in an HttpOnly Cookie

The backend can store a JWT in an HttpOnly cookie rather than returning it for JavaScript to manage.

This reduces direct token access through JavaScript, but it does not make XSS harmless. Malicious scripts may still perform authenticated actions from the compromised page.

Because cookies are sent automatically, CSRF protection and careful cookie configuration remain important.

6. OAuth 2.0 Authorization Code Flow with PKCE

PKCE protects the authorization code flow against authorization-code interception.

It is commonly used for public clients, including browser-based and mobile applications. However, PKCE is not a token-storage strategy by itself. The application still needs to decide how tokens are handled after authorization.

For an application that can keep credentials on a backend, a server-side session or BFF can reduce the amount of sensitive token material exposed to the browser.

7. Backend for Frontend (BFF)

The browser communicates with a backend dedicated to its frontend. The BFF manages access tokens and communicates with downstream APIs.

The browser uses a session cookie instead of handling API access tokens directly.

This can reduce token exposure, but it introduces backend infrastructure and still requires secure session handling, CSRF defenses, and appropriate authorization checks.

8. Refresh Token Rotation

Refresh token rotation issues a new refresh token whenever the current one is used. The previous token is invalidated, and reuse detection can help identify stolen tokens.

This is not an alternative to cookie storage or a BFF. It is a complementary strategy for managing refresh-token lifecycles.

The backend must implement rotation and revocation correctly, including handling concurrent refresh attempts.

Authentication Is Not Authorization

Authentication answers: Who are you?

Authorization answers: What are you allowed to do?

After authenticating a user, the backend still needs to enforce access rules.

Common approaches include:

RBAC: Access based on roles such as admin or editor.
Permission-based authorization: Fine-grained permissions such as user.read or order.create.
ABAC: Decisions based on attributes such as resource ownership or department.
Claims-based authorization: Decisions based on trusted claims, with appropriate validation and server-side enforcement.

A decoded JWT is not automatically trustworthy. The backend must validate its signature, issuer, audience, expiration, and other relevant claims. Authorization decisions must be enforced by the server, not just by hiding buttons in the frontend.

Which Approach Should You Choose?

There is no single solution that fits every application.

For a first-party web application where you control the backend, server-side sessions or a BFF are often worth considering. For a standalone SPA that directly calls APIs, access tokens in memory combined with a carefully designed refresh flow may be appropriate.

The decision depends on your architecture, threat model, deployment constraints, and operational requirements.

The real goal is not to find the most complicated authentication setup. It's to choose the simplest architecture that meets your security requirements and implement it correctly.

Pac-Man AI Explained: How the Ghosts Think, Chase, and Predict Your Moves Copy title

Amin Sadeghi — Tue, 27 Oct 2026 02:11:34 +0000

How a game from 1980 uses state machines, target selection, local pathfinding, and simple decision rules to create surprisingly intelligent enemies.

Pac-Man looks like a simple game.

You move through a maze, collect dots, avoid ghosts, and try to survive as long as possible.

But have you ever wondered why the ghosts behave differently?

Why does one follow you directly, another try to get ahead of you, and another seem to change its mind when it gets close?

The interesting part is that the original Pac-Man does not need a modern AI model to create these behaviors. Its enemies use a collection of relatively simple rules that work together to make the game challenging.

In this article, we'll break down the main algorithms behind Pac-Man, understand how the four ghosts make decisions, and explore how you could implement a similar system yourself.

1. The Core Idea: AI Without Machine Learning

When people hear "game AI," they often think about neural networks, reinforcement learning, or large language models.

But game AI doesn't necessarily require any of these techniques.

In the original Pac-Man, the ghosts primarily rely on:

Finite State Machines (FSMs) to manage behavioral modes.
Target selection to decide where each ghost wants to go.
Local movement decisions to choose the next direction at intersections.
Timers and conditions to change behavior during gameplay.
Rules specific to each ghost to create different personalities.

These techniques are examples of rule-based AI.

The ghosts don't need to understand the maze the way a human does. They only need enough information to choose their next move.

That's an important distinction: a character can appear intelligent without planning every step of its journey in advance.

2. Representing the Maze as a Grid

Before implementing enemy behavior, we need a representation of the game world.

A Pac-Man maze can be modeled as a grid of tiles. Each tile represents a location that may contain a wall, a corridor, a dot, a power pellet, or another game object.

For example:

#############
#P....#.....#
#.#.#.#.###.#
#.#...G.....#
#.....#.....#
#############

Here, P represents Pac-Man and G represents a ghost.

A simple representation in JavaScript could look like this:

const maze = [
  "#########",
  "#.......#",
  "#.###...#",
  "#.......#",
  "#########",
];

const WALL = "#";
const EMPTY = ".";

We can represent a position using two coordinates:

const pacman = {
  x: 1,
  y: 1,
  direction: "right",
};

This makes it easy to check whether a move is valid.

function canMoveTo(x, y) {
  return maze[y]?.[x] !== undefined &&
         maze[y][x] !== WALL;
}

This is only a basic example. A complete implementation would also need to handle tunnel transitions, movement timing, collision rules, and the exact geometry of the maze.

Why tiles matter

The original game's ghost logic is based on tile positions and decisions made at intersections, rather than requiring each ghost to continuously calculate a complete route across the maze.

This simplifies movement decisions and makes the behavior predictable enough to learn, while still allowing the ghosts to pressure the player.

3. The Ghost AI State Machine

The ghosts don't use the same behavior all the time.

Their movement changes according to the current game mode.

Three important modes are:

Chase: Ghosts pursue Pac-Man according to their individual targeting rules.
Scatter: Ghosts target their assigned corners of the maze.
Frightened: Ghosts become vulnerable and choose movement directions in a more random way.

A state machine controls which behavior is active.

Conceptually, it looks like this:

              ┌───────────┐
              │  SCATTER  │
              └─────┬─────┘
                    │ timer
                    ▼
              ┌───────────┐
        ┌─────│   CHASE   │
        │     └─────┬─────┘
        │           │ power pellet
        │           ▼
        │     ┌───────────┐
        └─────│ FRIGHTENED│
              └───────────┘

This is a conceptual diagram, not the complete transition graph of the arcade game. The actual implementation also needs timers, mode transitions, and rules for handling frightened ghosts.

A simplified implementation might look like this:

const GhostMode = {
  SCATTER: "scatter",
  CHASE: "chase",
  FRIGHTENED: "frightened",
};

function updateGhost(ghost, game) {
  switch (ghost.mode) {
    case GhostMode.SCATTER:
      return moveTowardTarget(
        ghost,
        ghost.scatterTarget
      );

    case GhostMode.CHASE:
      return moveTowardTarget(
        ghost,
        getChaseTarget(ghost, game)
      );

    case GhostMode.FRIGHTENED:
      return moveRandomly(ghost, game);
  }
}

The key design decision is that the current mode determines the movement strategy.

Instead of writing one enormous function that handles every possible situation, we separate the behavior into smaller pieces.

This also makes the system easier to extend and test.

Why switch between Chase and Scatter?

If all the ghosts pursued Pac-Man continuously, the game could become much harder and less varied.

Scatter mode gives the player temporary breathing room. Each ghost heads toward its own corner instead of directly targeting the player.

Chase mode then brings the pressure back.

The original game alternates these modes according to a timed schedule, rather than making every transition depend on the player's immediate position.

This creates a rhythm between pursuit and temporary relief.

4. The Four Ghosts Use Different Targeting Algorithms

This is where Pac-Man's design becomes especially interesting.

The ghosts share much of the same movement logic, but they calculate their targets differently.

The four classic ghosts are:

Ghost	Color	Main behavior
Blinky	Red	Direct pursuit
Pinky	Pink	Ambush
Inky	Cyan	Position-dependent targeting
Clyde	Orange	Pursuit with a distance-based switch

These are not four independent, highly sophisticated AI systems. They're different targeting strategies built on top of a shared movement system.

4.1 Blinky: Direct Pursuit

Blinky is the most straightforward ghost to understand.

During Chase mode, his target is Pac-Man's current tile.

If Pac-Man is at position ((p_x, p_y)), Blinky's target is:

[
T_B = (p_x, p_y)
]

In code:

function getBlinkyTarget(pacman) {
  return {
    x: pacman.x,
    y: pacman.y,
  };
}

This sounds simple, but direct pursuit is effective because Pac-Man must navigate the same corridors and intersections as Blinky.

The ghost doesn't need to predict the player's future. It continually updates its target as Pac-Man moves.

In later stages of the original game, Blinky can also enter a faster behavior known as Cruise Elroy, which makes him more aggressive.

The lesson: A simple pursuit rule can be dangerous when it operates continuously in a constrained environment.

4.2 Pinky: Ambush Instead of Following

Pinky uses a different strategy.

Instead of targeting Pac-Man's current position, Pinky targets a tile four tiles ahead of Pac-Man's current direction.

Suppose Pac-Man is moving to the right:

P . . . T

P is Pac-Man, and T is Pinky's target.

If Pac-Man is at ((p_x, p_y)) and moving right, the target is approximately:

[
T_P = (p_x + 4, p_y)
]

A simplified implementation:

function getPinkyTarget(pacman) {
  const offsets = {
    up:    { x: 0, y: -4 },
    down:  { x: 0, y: 4 },
    left:  { x: -4, y: 0 },
    right: { x: 4, y: 0 },
  };

  const offset = offsets[pacman.direction];

  return {
    x: pacman.x + offset.x,
    y: pacman.y + offset.y,
  };
}

This is a simplified version of the targeting rule.

The original arcade implementation contains a well-known quirk: when Pac-Man faces up, Pinky's target is offset four tiles up and four tiles left because of an integer-overflow behavior in the original code.

That bug became part of the game's behavior.

Why is this strategy effective?

Imagine that Pac-Man is moving through a long corridor.

Blinky follows the current position, but Pinky aims farther along the corridor. If Pac-Man continues in the same direction, Pinky may reach an intersection ahead of him.

Instead of simply chasing the player, Pinky can cut off the player's route.

This creates the impression of prediction, even though the algorithm only uses the player's current position and direction.

The lesson: A small change in the target calculation can produce a completely different enemy personality.

4.3 Inky: Targeting Based on Two Characters

Inky uses a more complex rule because his target depends on both Pac-Man and Blinky.

First, calculate a point two tiles ahead of Pac-Man:

[
A = P + 2D
]

Where:

(P) is Pac-Man's current position.
(D) is the direction vector.
(A) is the intermediate target.

Next, calculate the vector from Blinky's position (B) to that point:

[
V = A - B
]

Finally, double that vector from Blinky's position:

[
T_I = B + 2V
]

Combining the equations gives:

[
T_I = 2A - B
]

This target can end up far from Pac-Man's current position.

A simplified implementation:

function getInkyTarget(pacman, blinky) {
  const offsets = {
    up:    { x: 0, y: -2 },
    down:  { x: 0, y: 2 },
    left:  { x: -2, y: 0 },
    right: { x: 2, y: 0 },
  };

  const offset = offsets[pacman.direction];

  const ax = pacman.x + offset.x;
  const ay = pacman.y + offset.y;

  return {
    x: 2 * ax - blinky.x,
    y: 2 * ay - blinky.y,
  };
}

This code captures the central vector calculation, but it doesn't reproduce every detail of the original arcade implementation, including the upward-direction quirk and handling of targets outside the maze.

Why does Blinky's position matter?

Imagine Pac-Man moving toward an intersection while Blinky approaches from one side.

Inky's target changes according to Blinky's position. As a result, Inky can approach the same area from a different direction.

This can create situations where Pac-Man is pressured from multiple directions without the ghosts needing a shared plan that explicitly says, "surround the player."

Their individual rules can create that effect.

The lesson: Combining simple algorithms with shared world state can create more complex behavior than any single rule produces on its own.

4.4 Clyde: Chase Until a Distance Threshold

Clyde uses a distance-based rule.

When he's far from Pac-Man, he targets Pac-Man directly. When he's close, he switches to his Scatter target.

In the original arcade game, the important threshold is eight tiles.

A simplified rule is:

[
T_C =
\begin{cases}
P, & d(C,P) \geq 8 \
S_C, & d(C,P) < 8
\end{cases}
]

Where:

(C) is Clyde's position.
(P) is Pac-Man's position.
(S_C) is Clyde's Scatter target.

In code:

function getClydeTarget(clyde, pacman) {
  const dx = clyde.x - pacman.x;
  const dy = clyde.y - pacman.y;

  const distanceSquared = dx * dx + dy * dy;

  if (distanceSquared < 8 * 8) {
    return clyde.scatterTarget;
  }

  return {
    x: pacman.x,
    y: pacman.y,
  };
}

This example uses Euclidean distance for simplicity. The exact original behavior should be implemented using the game's actual distance and tile rules rather than assuming this snippet is a bit-for-bit recreation.

Why does this create a distinct personality?

Clyde can approach Pac-Man aggressively, then head toward his corner when he gets too close.

The result looks inconsistent if you assume that every ghost is trying to minimize its distance to Pac-Man at all times.

But the behavior makes sense when you understand that Clyde's target changes according to a rule.

He isn't making an emotional decision. He's following a different policy.

The lesson: Different conditional rules can make agents appear to have distinct personalities without requiring a personality model.

5. How Do Ghosts Choose Their Next Move?

Knowing a target isn't enough.

A ghost also needs to decide which direction to take at the next intersection.

This is where movement selection comes in.

A common misconception is that the original ghosts run a full A* search every time they move.

Their classic movement logic is more local than that.

At a decision point, the ghost considers its legal directions and chooses the one that brings it closest to its current target according to the game's distance calculation.

A simplified version might look like this:

function chooseDirection(ghost, target, legalMoves) {
  let bestMove = null;
  let bestDistance = Infinity;

  for (const move of legalMoves) {
    const nextX = ghost.x + move.dx;
    const nextY = ghost.y + move.dy;

    const dx = target.x - nextX;
    const dy = target.y - nextY;

    const distance = dx * dx + dy * dy;

    if (distance < bestDistance) {
      bestDistance = distance;
      bestMove = move;
    }
  }

  return bestMove;
}

This example illustrates greedy local decision-making. A faithful implementation needs the original game's movement constraints, direction priority rules, target handling, and intersection timing.

Why use squared distance?

If the goal is only to compare distances, calculating the square root is unnecessary.

Instead of comparing:

[
d = \sqrt{(\Delta x)^2 + (\Delta y)^2}
]

we can compare:

[
d^2 = (\Delta x)^2 + (\Delta y)^2
]

Since square root preserves the ordering of non-negative values, the closest candidate remains the closest candidate.

This avoids an unnecessary calculation.

Why not always use A*?

A* is a pathfinding algorithm that searches for a route through a graph. It can be a great choice for games where characters need a globally planned, obstacle-aware route.

But the original Pac-Man ghosts use a more constrained movement model. Their local decisions, combined with the maze geometry and targeting rules, are sufficient for the intended behavior.

This distinction matters:

Target selection answers: Where should the ghost try to go?
Movement selection answers: Which legal direction should it take next?
Pathfinding usually refers to finding a route through the environment to reach a destination.

These concepts are related, but they aren't interchangeable.

A ghost can have a sophisticated target-selection rule while using relatively simple movement decisions.

6. Movement Restrictions Are Part of the AI

The ghost's decision is not made from every possible direction.

The maze restricts movement, and the game imposes additional rules. For example, ghosts generally cannot reverse direction whenever they want. Direction reversals are associated with specific events, including mode changes.

A more realistic movement function starts by generating legal candidates:

function getLegalMoves(ghost, maze) {
  const directions = [
    { name: "up",    dx: 0,  dy: -1 },
    { name: "left",  dx: -1, dy: 0 },
    { name: "down",  dx: 0,  dy: 1 },
    { name: "right", dx: 1,  dy: 0 },
  ];

  return directions.filter((direction) => {
    if (isReverseDirection(ghost, direction)) {
      return false;
    }

    return canMoveTo(
      ghost.x + direction.dx,
      ghost.y + direction.dy
    );
  });
}

This is illustrative rather than complete arcade logic. In a real implementation, you must also handle dead ends, mode changes, tunnels, and cases where the candidate list becomes empty.

The order in which directions are evaluated can also matter when multiple moves have equal distances. A faithful recreation needs the original priority rules rather than relying on arbitrary array order.

These small implementation details are important because they affect what players observe.

7. Frightened Mode: Changing the Objective

When Pac-Man eats a power pellet, the ghosts enter Frightened mode.

Their behavior changes in several ways:

They become vulnerable to being eaten.
Their movement becomes less predictable.
They generally move more slowly.
The mode has a limited duration, which varies with the game's level and rules.

This is not simply a different target coordinate.

The objective itself has changed. Instead of pursuing Pac-Man in the usual way, the ghosts use frightened movement behavior.

A simplified implementation could be:

function chooseFrightenedMove(legalMoves) {
  if (legalMoves.length === 0) {
    return null;
  }

  const index = Math.floor(
    Math.random() * legalMoves.length
  );

  return legalMoves[index];
}

The original arcade behavior has additional rules and should not be treated as equivalent to uniformly selecting from every legal move. This example only demonstrates how a separate strategy can be plugged into the movement system.

Why randomness matters

A deterministic enemy can become predictable if the player learns its rules.

Randomized movement can make the frightened state less predictable, giving the player a temporary advantage without making every encounter identical.

However, randomness alone is not intelligence. It's simply another tool for creating variation.

8. The Architecture Behind the Behavior

If I were implementing a Pac-Man-style AI today, I would separate the system into several responsibilities.

Game State
    |
    v
Ghost State Machine
    |
    v
Target Selection
    |
    v
Legal Move Generation
    |
    v
Movement Decision
    |
    v
Collision and Game Update

Each layer has a different responsibility.

Component	Responsibility
Game state	Tracks positions, directions, pellets, and timers
State machine	Determines whether the ghost is chasing, scattering, or frightened
Target selection	Calculates the destination for the active mode
Move generation	Finds legal directions at the current position
Movement decision	Selects the next direction
Collision system	Checks contact between Pac-Man and ghosts

This separation is useful because each component can be changed without rewriting the entire AI.

For example, you could replace the greedy movement strategy with A* while keeping the same target-selection functions.

Or you could add a new ghost personality without duplicating the entire movement engine.

This is one of the most useful software design lessons in the game: separate the decision about where to go from the algorithm used to move there.

9. Could We Make Pac-Man AI Smarter?

Definitely.

The original system is effective because it was designed around the game's constraints, not because it solves every possible decision optimally.

Modern implementations can explore several alternatives.

Option 1: A* Pathfinding

A* searches for a route through a graph using the cost already incurred and an estimate of the remaining cost.

It can be useful when you want ghosts to follow globally optimal routes rather than making only local decisions.

However, if every ghost always takes the shortest route directly to Pac-Man, the game may become too easy to predict or too difficult to survive, depending on speed and coordination.

The algorithm should serve the intended gameplay, not just minimize path length.

Option 2: Predictive Targeting

Instead of aiming at a fixed number of tiles ahead, a ghost could estimate where Pac-Man will be after a short time.

For example:

[
P_{future} = P_{current} + v \Delta t
]

Where (v) is the player's velocity and (\Delta t) is a prediction horizon.

This approximation works in simple movement environments, but a maze introduces walls and turns. A better predictor would account for legal routes and likely player choices.

Option 3: Coordinated Ghosts

The original ghosts use individual targeting rules. A modern system could add explicit coordination.

For example:

One ghost follows Pac-Man.
Another targets an upcoming intersection.
Another attempts to block an escape route.
Another stays near a strategically important area.

The system could assign these roles dynamically based on the game state.

This would be a different AI design, not a description of how the original arcade game works.

Option 4: Reinforcement Learning

You could train an agent to play Pac-Man using reinforcement learning.

The agent would observe the game state, choose an action, and receive a reward based on the result.

A reward function might consider:

Pellets collected.
Survival time.
Lives lost.
Power pellets collected.
Distance to remaining objectives.

But defining the reward function is only part of the problem. You also need to choose the observation representation, action space, training method, and evaluation criteria.

And if the goal is to reproduce the classic ghost behavior, reinforcement learning is probably unnecessary. A rule-based implementation is easier to understand, control, and debug.

10. What Pac-Man Teaches Us About AI Design

There are several broader lessons here.

1. Complex behavior can emerge from simple rules.

The ghosts don't need an elaborate model of Pac-Man's intentions. Their different target calculations and movement constraints can produce the appearance of coordinated pursuit.

2. State is as important as the algorithm.

The same ghost can behave differently depending on whether it is in Chase, Scatter, or Frightened mode. An algorithm cannot be understood independently of the state in which it operates.

3. Local decisions can be enough.

A full search of the maze is not always necessary. A constrained decision rule can work well when the environment and movement rules are designed around it.

4. Imperfections can become part of a system's identity.

Pinky's upward-targeting quirk is a famous example of an implementation bug becoming a recognizable gameplay behavior.

5. Predictability is a design choice.

A game needs rules that players can gradually understand, but it also needs enough variation and pressure to remain interesting.

The goal isn't necessarily to make the enemy as intelligent as possible. It's to make its behavior appropriate for the experience the game is trying to create.

Conclusion

Pac-Man is a useful example of how much can be achieved without machine learning.

Its AI combines state machines, target calculations, distance-based decisions, movement constraints, and carefully timed behavior changes.

The four ghosts share much of the same underlying movement logic, but their different targeting strategies make them feel like distinct opponents.

That is the most interesting part of the design: the personality comes largely from the rules, not from a complex model of intelligence.

If you're building a game AI, it's worth studying systems like this before reaching for a neural network. Sometimes a small number of well-designed rules, combined with the right environment, can produce exactly the behavior you need.

Experience: What Life Teaches You Beyond Books and Theory

Amin Sadeghi — Mon, 26 Oct 2026 00:17:16 +0000

We often confuse knowing something with truly understanding it.

You can read a book, complete an online course, or watch dozens of tutorials and still struggle when you face a real situation. The information may be familiar, but applying it under real conditions is a different skill.

That is where experience comes in.

What Is Experience?

Experience is what you learn by doing something, facing a situation, and reflecting on the outcome.

It does not come only from success. Mistakes, unexpected problems, difficult decisions, and even failures can teach us valuable lessons.

But experience is not simply about how much time you spend doing something. It is about how much you learn from that time.

Two people can spend five years doing the same job and develop completely different levels of understanding. One may repeat the same process without questioning it. The other may continuously evaluate decisions, learn from mistakes, and improve their approach.

Time creates opportunities for experience. Reflection turns those opportunities into learning.

How Is Experience Built?

Experience develops through several interconnected processes.

1. Repetition

Doing something repeatedly helps you recognize patterns and become more comfortable with familiar situations.

For example, writing JavaScript regularly can help you recognize common errors, understand language behavior, and solve familiar problems more efficiently.

However, repetition alone is not enough. Repeating the same mistake without understanding it does not necessarily make you better.

2. Making Mistakes

Mistakes reveal gaps between what you believe and what actually happens.

When something goes wrong, you have an opportunity to examine your assumptions, understand the cause, and adjust your approach.

In software development, fixing a bug is useful. Understanding why it happened, why your original approach failed, and how to prevent similar issues is even more valuable.

The real lesson is not always the solution itself. Sometimes, it is the reasoning that led you to the solution.

3. Facing Different Situations

Familiar situations teach you how to handle familiar problems. New situations challenge you to adapt.

Working with different technologies, collaborating with different people, or dealing with limited resources forces you to reconsider what you already know.

Over time, you begin to understand not only what works, but also when it works and when it does not.

4. Making Decisions Under Uncertainty

Experience becomes especially valuable when you do not have all the information you need.

In theory, problems often have clearly defined conditions. In practice, requirements change, deadlines approach, resources are limited, and several solutions may appear reasonable.

Experience helps you evaluate trade-offs, recognize risks, and make informed decisions without expecting perfect certainty.

Why Does Experience Matter?

Experience changes how you approach problems.

You recognize patterns faster. Previous situations help you identify familiar problems without starting your analysis from zero every time.

You make more informed decisions. You have a better understanding of the consequences, limitations, and trade-offs associated with different choices.

You respond more effectively to pressure. Familiarity with difficult situations can help you remain focused instead of reacting impulsively.

You turn knowledge into practical judgment. You learn that a technically correct solution is not always the most appropriate solution for the situation.

These benefits do not appear automatically with age or time. They develop when you actively learn from what you experience.

Theory vs. Experience

Theory and experience are not opposites. They serve different purposes, and both are necessary.

Theory helps you understand concepts, principles, and possible approaches. Experience helps you apply that understanding in specific circumstances.

Consider two developers learning React.

One has completed a course and understands components, props, state, and hooks. Another has also worked on projects, debugged unexpected behavior, handled changing requirements, and evaluated different implementation approaches.

Both may understand React. But the second developer has had more opportunities to learn how those concepts behave in practice.

That does not mean the second developer is automatically better. The quality of their decisions, the complexity of their work, and their willingness to learn all matter.

The difference is that practical experience exposes you to problems that theory alone cannot fully reproduce.

Theory gives you a foundation. Experience helps you develop judgment.

Experience Is Not the Same as Never Making Mistakes

It is tempting to think that experienced people always know what to do.

In reality, experience does not eliminate uncertainty or guarantee correct decisions. Experienced people still make mistakes, encounter unfamiliar problems, and sometimes need to reconsider their assumptions.

What often changes is how they respond.

Instead of immediately blaming someone or searching for the fastest workaround, they may investigate the underlying cause, compare possible solutions, and consider the long-term consequences.

Experience does not mean having every answer. It means becoming better at finding answers and learning when your current understanding is insufficient.

How to Get More Value From Your Experiences

You cannot control every situation you encounter, but you can control how deliberately you learn from it.

Here is a simple process:

Take action. Apply what you know instead of waiting until you feel completely ready.
Observe the outcome. Compare what actually happened with what you expected.
Analyze the difference. Identify the assumptions, decisions, or conditions that influenced the result.
Extract a lesson. Determine what you would repeat or change next time.
Apply what you learned. Use that lesson when a similar situation appears again.

This process works beyond programming. It applies to communication, relationships, learning, decision-making, and personal development.

The important part is not merely going through an experience. It is examining what that experience can teach you.

Final Thoughts

Books, courses, and theory can help you understand the world, but they cannot replace every lesson that comes from interacting with it.

You need to try things, face unexpected outcomes, make decisions, and reconsider your approach when the results do not match your expectations.

And when something goes wrong, do not stop at asking, "How do I fix this?"

Also ask, "What can I learn from why this happened?"

Because knowledge tells you what is possible. Experience helps you understand what works, under which conditions, and why.

You do not gain experience simply by living through situations. You gain it by learning from them.

Professionalism in Software Development: Focus on Your Strengths

Amin Sadeghi — Sun, 25 Oct 2026 13:33:16 +0000

Professionalism is often misunderstood as simply being good at your job. In reality, it involves much more than technical knowledge.

Being a professional means knowing your strengths, developing your expertise, delivering quality work, and taking responsibility for the results.

Why Focus Matters

1. Depth Over Superficial Knowledge

Trying to learn everything at once can leave you with a broad but shallow understanding of many subjects.

Focusing on a specific field allows you to understand its fundamentals, recognize complex problems, and make better technical decisions.

For example, a developer who focuses on backend engineering can gradually build deeper knowledge of APIs, databases, authentication, system design, and performance optimization.

2. Trust Is Built Through Consistency

Clients, employers, and teammates need people they can rely on.

Trust comes from delivering what you promise, communicating clearly, meeting deadlines, and being honest about what you can and cannot do.

You don't need to know everything to be a professional. You need to be reliable about the things you take responsibility for.

3. Better Results Through Specialization

When you understand a field deeply, you can often solve problems more efficiently because you recognize familiar patterns and understand the trade-offs behind different solutions.

This doesn't mean you should stop exploring other technologies. It means you should build a strong foundation before constantly jumping between unrelated areas.

4. Knowing Your Limits Is a Strength

Imagine you're a web developer and someone asks you to design a complete brand identity.

You might have some experience with design tools, but that doesn't necessarily make you a professional designer.

A professional response could be to explain your limitations, collaborate with a designer, or take on only the parts you're qualified to handle.

Accepting every task just to prove yourself can lead to poor results. Recognizing when you need help is part of professional judgment.

Professionalism Goes Beyond Technical Skills

Being skilled at your job is only one part of the equation.

Professionalism also requires:

Continuous learning: Keeping your knowledge relevant as tools and practices evolve.
Accountability: Taking ownership of mistakes and working toward solutions.
Communication: Explaining decisions, asking the right questions, and setting realistic expectations.
Attention to quality: Considering maintainability, reliability, and long-term consequences, not just whether something works today.
Ethics: Being honest about your skills, progress, and limitations.

These qualities matter just as much as technical ability when working with a team or building a career.

The Balance: Specialize Without Becoming Narrow-Minded

Focusing on your expertise doesn't mean refusing to learn anything outside it.

A backend developer still benefits from understanding frontend fundamentals. A frontend developer benefits from knowing how APIs, databases, and authentication work.

The goal is to develop T-shaped skills: deep expertise in one area, supported by enough knowledge of related fields to collaborate effectively and understand the bigger picture.

You don't have to do everything yourself. You need to understand your role, recognize how it connects to others, and know when collaboration is the better solution.

Final Thoughts

Professionalism isn't about pretending to know everything or accepting every opportunity that comes your way.

It's about understanding what you do well, improving where you fall short, delivering work you can stand behind, and knowing when to ask for help.

Focus on your craft. Build depth. Take responsibility. Let the quality of your work earn people's trust.

That's a more sustainable path to becoming a professional than trying to be good at everything at once.

Your Rate Limiter Works Until You Deploy a Second Server

Amin Sadeghi — Sat, 24 Oct 2026 00:44:20 +0000

A rate limiter can work perfectly in development and still fail in production.

You test it locally, send too many requests, and receive a 429 Too Many Requests response. Everything looks fine.

Then you deploy your Node.js application with two instances behind a load balancer.

Suddenly, users can send more requests than your limit allows.

The problem isn't necessarily your rate-limiting algorithm. It's where you're storing the request counts.

The Problem With In-Memory Rate Limiting

Consider this Express middleware:

const requests = new Map();

function rateLimiter(req, res, next) {
  const key = req.ip;
  const now = Date.now();
  const windowMs = 60_000;
  const limit = 10;

  let record = requests.get(key);

  if (!record || now - record.start >= windowMs) {
    record = {
      count: 0,
      start: now,
    };
  }

  record.count++;
  requests.set(key, record);

  if (record.count > limit) {
    return res.status(429).json({
      message: "Too many requests",
    });
  }

  next();
}

This simplified fixed-window limiter allows up to 10 requests per IP address per minute in a single process.

But what happens when your application runs on two servers?

Imagine the load balancer distributes requests like this:

Server A receives 10 requests.
Server B receives another 10 requests.
Each server maintains its own Map.

Both servers see only 10 requests. Neither rejects the requests.

Your intended limit was 10 requests per minute, but the user managed to send 20.

With more instances, the discrepancy can become even larger.

The key issue is that each process has its own memory.

An in-memory counter is not shared across Node.js processes, containers, or separate application instances.

Why This Matters in Production

This becomes especially important when rate limits protect:

Login and password-reset endpoints
Public APIs with usage quotas
Expensive database queries
AI or third-party API calls that cost money
Endpoints vulnerable to automated abuse

A rate limiter that works only within one process may provide weaker protection than you expect.

There is another problem: when a process restarts, its counters disappear. Scaling, restarting, or replacing instances can therefore change the effective limit.

A Better Approach: Use Redis

Redis gives multiple application instances access to shared state.

Instead of keeping request counts in a local Map, each instance updates a shared counter.

A simplified Redis fixed-window implementation might look like this:

async function rateLimiter(req, res, next) {
  try {
    const key = `rate-limit:${req.ip}`;
    const limit = 10;
    const windowSeconds = 60;

    const count = await redis.incr(key);

    if (count === 1) {
      await redis.expire(key, windowSeconds);
    }

    if (count > limit) {
      return res.status(429).json({
        message: "Too many requests",
      });
    }

    next();
  } catch (error) {
    next(error);
  }
}

Here, redis represents an already configured Redis client.

Now both servers use the same counter. If Server A processes six requests and Server B processes five, the shared count reaches eleven, so the eleventh request is rejected.

However, this example illustrates the idea rather than providing a complete production-ready implementation.

There is still a subtle problem

The counter increment and expiration are separate commands.

If the process fails between INCR and EXPIRE, the key might remain without an expiration. That could cause requests to be rejected indefinitely.

For production use, execute the counter update and expiration logic atomically, for example with a Redis Lua script or an appropriate atomic Redis operation.

You should also decide what happens when Redis becomes unavailable. Failing open allows requests through but weakens protection; failing closed preserves the limit but can make an endpoint unavailable. The right choice depends on the endpoint and its risk.

Redis Doesn't Automatically Make Every Rate Limiter Correct

Using shared storage solves the per-instance counter problem, but other design decisions still matter.

1. Choose the right algorithm

A fixed-window limiter is easy to implement, but it can allow bursts around window boundaries.

For example, a client might send 10 requests just before a window resets and another 10 immediately afterward.

Depending on your requirements, a sliding-window counter, sliding log, or token bucket may provide better behavior.

2. Identify clients correctly

Using req.ip requires careful proxy configuration.

If Express trusts forwarded headers from untrusted clients, an attacker might spoof their apparent IP address. Configure trust proxy according to your actual infrastructure rather than enabling it blindly.

For authenticated APIs, you may want to rate-limit by user ID, API key, IP address, or a combination of these.

3. Set limits by endpoint

A public read endpoint and a password-reset endpoint do not have the same risk profile.

You might allow more requests for inexpensive reads while applying stricter limits to authentication or resource-intensive operations.

4. Consider an existing library

For many Express applications, using a maintained rate-limiting library with a Redis-compatible store is safer than implementing every detail yourself.

A library can handle important concerns such as response headers, window behavior, storage integration, and configuration. You still need to verify that its algorithm and failure behavior match your requirements.

How to Test Your Rate Limiter

Don't test only one request at a time against your local development server.

A more useful test plan includes:

Send more requests than the configured limit and verify that excess requests receive 429.
Send requests through multiple application instances and confirm that the shared limit is enforced.
Verify that the counter resets or expires as intended.
Test concurrent requests, not just sequential requests.
Simulate Redis failures and confirm the intended fail-open or fail-closed behavior.
Test forwarded IP headers using your actual proxy configuration.

For production systems, also monitor rejected requests and storage errors. A rate limiter that silently fails can be difficult to diagnose.

The Real Lesson

Rate limiting is not just about counting requests. It is about maintaining consistent state across the infrastructure that processes those requests.

An in-memory counter can be perfectly reasonable for a single-process prototype. But once an application scales horizontally, local state is no longer enough for a globally enforced limit.

Before deploying a rate limiter, ask yourself one question: does every server agree on how many requests this client has made?

If the answer is no, your limit might not be the limit you think it is.

Have you implemented rate limiting in a production application? Did you use Redis, a gateway, or another approach?

JavaScript Iterator Helpers: Lazy Evaluation Explained with Real Examples

Amin Sadeghi — Wed, 21 Oct 2026 02:35:50 +0000

JavaScript developers are used to writing chains like this:

const result = users
  .filter(user => user.active)
  .map(user => user.name)
  .slice(0, 5);

It's readable, concise, and works well for ordinary arrays.

But there's a catch.

Every array method in that chain creates an intermediate array. First, filter() creates an array of active users. Then, map() creates another array containing their names. Finally, slice() creates the result.

For small datasets, this usually doesn't matter. But what if you want to process values one at a time, stop early, or work with a sequence that doesn't exist as an array?

This is where Iterator Helpers come in.

1. What are Iterator Helpers?

Iterator Helpers introduce methods such as:

map()
filter()
flatMap()
take()
drop()
reduce()
toArray()
forEach()
some()
every()
find()

Instead of eagerly creating intermediate arrays, many of these methods return iterator helpers that process values lazily.

The feature became part of ECMAScript 2025.

2. The biggest difference: lazy evaluation

Consider this example:

function* generateNumbers() {
  console.log("Generating 1");
  yield 1;

  console.log("Generating 2");
  yield 2;

  console.log("Generating 3");
  yield 3;
}

const numbers = generateNumbers();

const result = numbers
  .filter(n => n > 1)
  .map(n => n * 10)
  .take(1);

console.log("Pipeline created");
console.log(result.next());

The output is:

Pipeline created
Generating 1
Generating 2
{ value: 20, done: false }

Notice what didn't happen: Generating 3 was never printed.

Why?

Because take(1) only needs one matching result. The iterator pipeline processes values as they're requested and stops when it has enough.

This is lazy evaluation in practice.

One important detail: filter() may need to inspect several source values before finding a match. Lazy doesn't mean every operation processes exactly one input.

3. Why this matters for real applications

Imagine processing a large stream of records where you only need the first few that match a condition.

With an array pipeline:

const matches = records
  .filter(record => record.status === "published")
  .map(record => record.title)
  .slice(0, 10);

The filtering and mapping happen before slice() limits the result.

With an iterator pipeline:

const matches = records.values()
  .filter(record => record.status === "published")
  .map(record => record.title)
  .take(10)
  .toArray();

The iterator pipeline can stop once it has collected ten published titles.

This can reduce unnecessary processing and intermediate allocations when the source is large and the pipeline terminates early.

It doesn't guarantee a performance improvement in every case. The actual benefit depends on the source, the operations, and how much data needs to be processed.

4. You can work with infinite sequences

Arrays must have a finite length, but generators can produce values on demand.

function* naturalNumbers() {
  let number = 1;

  while (true) {
    yield number++;
  }
}

const result = naturalNumbers()
  .filter(n => n % 2 === 0)
  .map(n => n * n)
  .take(5)
  .toArray();

console.log(result);
// [4, 16, 36, 64, 100]

This sequence has no natural stopping point.

Yet the pipeline terminates because take(5) requests only five matching results.

Try implementing the same behavior with an infinite array. You can't: constructing the complete array would never finish.

5. Iterators are not arrays

This is an important distinction.

You can't assume every array method is available:

const numbers = [1, 2, 3, 4, 5];

const iterator = numbers.values();

console.log(typeof iterator.map);
// "undefined"

But Iterator Helpers let you build a pipeline:

const result = numbers.values()
  .filter(n => n > 2)
  .map(n => n * 2)
  .toArray();

console.log(result);
// [6, 8, 10]

You can also convert the result back into an array with toArray() when you need array-specific operations or repeated access.

6. A few things to watch out for

Iterator Helpers are useful, but they're not a universal replacement for array methods.

Iterators are generally consumable. Once you've advanced an iterator, you can't assume you can restart it from the beginning. If you need to process the same data multiple times, create a new iterator or retain the underlying data.

Lazy pipelines can hide when work happens. Creating a pipeline doesn't necessarily execute its transformations. Values are processed when a terminal operation requests them.

Not every helper is lazy. Methods such as toArray(), reduce(), forEach(), some(), and find() consume values to produce a result or complete their operation.

Runtime support matters. Iterator Helpers are part of the ECMAScript 2025 standard, but you should verify support in your target browsers and JavaScript runtimes before using them in production.

Final thoughts

Iterator Helpers bring a useful programming model to JavaScript: compose transformations without immediately materializing every intermediate result.

They're especially interesting when working with generators, large sequences, early termination, or data-processing pipelines.

You probably don't need to replace every filter().map() chain in your codebase. Arrays remain a good choice for finite collections that need indexing, repeated traversal, or multiple array operations.

But when you need to process values on demand, Iterator Helpers give you a built-in way to do it.

Have you started using Iterator Helpers, or are array methods still your default for everything?

References:

AI Is Making Developers Faster. So Why Are We Still Measuring Productivity by Lines of Code?

Amin Sadeghi — Mon, 19 Oct 2026 16:20:00 +0000

Let's be honest.

Writing code has never been the hardest part of software engineering.

Understanding the problem, making the right trade-offs, debugging unexpected behavior, and maintaining a system over time are often much harder.

Yet, for some reason, we still associate writing more code with being a better developer.

AI makes that assumption even more questionable.

The productivity illusion

Imagine two developers.

Developer A writes 1,000 lines of code in a day using AI. The feature works, but nobody has reviewed the edge cases, tested failure scenarios, or considered the long-term maintenance cost.

Developer B writes 100 lines of code. The implementation is tested, the failure modes are understood, and the feature solves the actual problem without introducing unnecessary complexity.

Who is more productive?

If your answer is Developer A because they produced ten times more code, you're measuring output, not value.

And those two things are not the same.

AI didn't eliminate the hard part

AI coding tools can generate functions, write tests, explain unfamiliar code, and accelerate routine implementation.

That's useful. Ignoring these tools doesn't make someone a better engineer.

But generating code is only one part of building software.

Someone still needs to determine whether the generated solution:

Solves the correct problem.
Handles edge cases and unexpected input.
Introduces security vulnerabilities.
Fits the existing architecture.
Can be understood and maintained by another developer.
Is worth implementing in the first place.

The faster code is generated, the more important it becomes to evaluate what should actually be shipped.

Otherwise, we're just producing technical debt at a higher speed.

Here's the uncomfortable question

If AI can generate a significant portion of routine code, what exactly should companies pay developers for?

Typing speed?

Framework knowledge?

The ability to turn a specification into working code?

Or the judgment to know which solution is correct, which trade-offs are acceptable, and which features shouldn't be built at all?

My view is that implementation skills still matter. You cannot reliably evaluate a system you don't understand.

But implementation alone is becoming a weaker way to distinguish one developer from another.

The real advantage is increasingly the combination of technical understanding, problem-solving, verification, and sound engineering judgment.

So what should we measure instead?

Lines of code are easy to count. Engineering value is harder to measure.

A better evaluation considers several dimensions:

Correctness: Does the software behave as intended?
Reliability: Does it handle failures and edge cases?
Maintainability: Can the team safely change it later?
Delivery: Does it solve the problem within reasonable constraints?
Impact: Does it improve a meaningful outcome for users or the business?

None of these metrics is perfect in isolation. Even measuring impact can be difficult when results depend on factors outside an engineer's control.

But that doesn't make lines of code a good substitute.

My question to developers and engineering managers

If AI lets one developer produce five times as much code, should that developer be considered five times as productive?

Or should we stop treating code volume as a proxy for engineering value?

And here's the more controversial question:

If a developer can consistently deliver better software by writing less code and using AI intelligently, is the developer who writes everything manually actually more skilled, or just slower?

I'd like to hear arguments from both sides.

Promise.race() Doesn't Cancel Your Fetch Request: Here's Why

Amin Sadeghi — Sun, 18 Oct 2026 21:51:12 +0000

`Promise.race()` Doesn't Cancel Your Fetch Request: Here's Why

Have you ever implemented a timeout for fetch() using Promise.race() and assumed the request would stop when the timeout expired?

There is a subtle problem with that approach: Promise.race() settles when the first Promise settles, but it does not cancel the other Promises.

Let's look at why this matters and how to handle request timeouts correctly.

1. The Common Approach: `Promise.race()`

You might write something like this:

function fetchWithTimeout(url, timeout = 5000) {
  const timeoutPromise = new Promise((_, reject) => {
    setTimeout(() => {
      reject(new Error("Request timed out"));
    }, timeout);
  });

  return Promise.race([
    fetch(url),
    timeoutPromise
  ]);
}

At first glance, this seems reasonable.

If the request takes longer than five seconds, the timeout Promise rejects, and Promise.race() rejects as well.

But what happens to the original fetch() request?

It keeps running.

Promise.race() only determines which Promise settles the returned Promise first. It doesn't stop the losing operation.

That means the browser may continue waiting for the response and consuming network resources even though your application has already reported a timeout.

There's another issue: the timer isn't cleared when the request finishes early.

2. A Better Solution: `AbortSignal.timeout()`

Modern JavaScript provides a built-in way to abort supported operations after a specified duration.

async function fetchWithTimeout(url, timeout = 5000) {
  const response = await fetch(url, {
    signal: AbortSignal.timeout(timeout)
  });

  if (!response.ok) {
    throw new Error(`HTTP error: ${response.status}`);
  }

  return response.json();
}

Now, if the timeout expires before the fetch operation completes, the signal is aborted and the fetch rejects.

No custom timeout Promise is needed.

You can also handle the timeout explicitly:

try {
  const data = await fetchWithTimeout(
    "/api/users",
    5000
  );

  console.log(data);
} catch (error) {
  if (error.name === "TimeoutError") {
    console.error("The request timed out.");
  } else {
    console.error("The request failed:", error);
  }
}

Note that network errors and HTTP errors are different. A fetch() call doesn't reject just because the server returns a 404 or 500; that's why checking response.ok matters.

3. What If You Need Manual Cancellation Too?

Sometimes a request should stop either when the timeout expires or when the user cancels the operation.

For example, imagine a search interface where users can cancel a request or start another search before the previous one finishes.

You can combine multiple abort signals with AbortSignal.any().

const controller = new AbortController();

const signal = AbortSignal.any([
  controller.signal,
  AbortSignal.timeout(5000)
]);

try {
  const response = await fetch("/api/search?q=javascript", {
    signal
  });

  if (!response.ok) {
    throw new Error(`HTTP error: ${response.status}`);
  }

  const results = await response.json();
  console.log(results);
} catch (error) {
  if (error.name === "TimeoutError") {
    console.log("Request timed out.");
  } else if (error.name === "AbortError") {
    console.log("Request was cancelled.");
  } else {
    console.error(error);
  }
}

// Cancel manually whenever necessary:
controller.abort();

The combined signal aborts when either the manual controller is aborted or the timeout signal fires.

4. An Important Backend Consideration

There is one more detail that is easy to overlook.

Aborting a fetch request in the browser does not guarantee that the server stops processing it.

The server might already have received the request and started executing a database query or another operation.

This matters even more for operations such as:

Creating an order
Processing a payment
Updating account information
Triggering a background job

If a client times out and retries, the original operation might still complete. The retry could cause the same action to happen twice.

For operations that must not be duplicated, an idempotency mechanism can help ensure that repeated requests with the same key don't create duplicate effects. The server must implement and enforce that behavior.

Client-side cancellation and server-side cancellation are separate concerns.

5. When Should You Use Each Approach?

Use Promise.race() when you need to race multiple Promises and only care about which settles first, while understanding that losing operations continue unless separately cancelled.

Use AbortSignal.timeout() when you want a supported operation, such as fetch(), to be aborted after a deadline.

Use AbortSignal.any() when you need to combine timeout cancellation with manual cancellation or other abort signals.

Choose based on the behavior you actually need, not just the shortest code.

Final Takeaway

A timeout isn't automatically cancellation.

Promise.race() controls which result your code observes first. AbortSignal gives you a mechanism to signal cancellation to APIs that support it.

Understanding that distinction helps you write more reliable frontend applications and avoid subtle bugs when requests are slow, users retry actions, or the network behaves unpredictably.

Have you ever used Promise.race() to implement a timeout? Did you know the original request could keep running? Share your experience in the comments.

DEV Community: Amin Sadeghi

The Hidden Danger of Promise.all() in JavaScript

1. The Problem

2. Promise.all() Doesn't Cancel Anything

3. What If You Want Every Result?

4. What If You Actually Need Cancellation?

5. Which One Should You Use?

Final Thoughts

Authentication in SPAs: 8 Ways to Handle Tokens and Sessions

1. Memory + Silent Refresh

2. LocalStorage + JWT

3. SessionStorage + JWT

4. Server-Side Sessions with HttpOnly Cookies

5. JWT in an HttpOnly Cookie

6. OAuth 2.0 Authorization Code Flow with PKCE

7. Backend for Frontend (BFF)

8. Refresh Token Rotation

Authentication Is Not Authorization

Which Approach Should You Choose?

Pac-Man AI Explained: How the Ghosts Think, Chase, and Predict Your Moves Copy title

1. The Core Idea: AI Without Machine Learning

2. Representing the Maze as a Grid

Why tiles matter

3. The Ghost AI State Machine

Why switch between Chase and Scatter?

4. The Four Ghosts Use Different Targeting Algorithms

4.1 Blinky: Direct Pursuit

4.2 Pinky: Ambush Instead of Following

Why is this strategy effective?

4.3 Inky: Targeting Based on Two Characters

Why does Blinky's position matter?

4.4 Clyde: Chase Until a Distance Threshold

Why does this create a distinct personality?

5. How Do Ghosts Choose Their Next Move?

Why use squared distance?

Why not always use A*?

6. Movement Restrictions Are Part of the AI

7. Frightened Mode: Changing the Objective

Why randomness matters

8. The Architecture Behind the Behavior

9. Could We Make Pac-Man AI Smarter?

Option 1: A* Pathfinding

Option 2: Predictive Targeting

Option 3: Coordinated Ghosts

Option 4: Reinforcement Learning

10. What Pac-Man Teaches Us About AI Design

Conclusion

Further Reading

Experience: What Life Teaches You Beyond Books and Theory

What Is Experience?

How Is Experience Built?

1. Repetition

2. Making Mistakes

3. Facing Different Situations

4. Making Decisions Under Uncertainty

Why Does Experience Matter?

Theory vs. Experience

Experience Is Not the Same as Never Making Mistakes

How to Get More Value From Your Experiences

Final Thoughts

Professionalism in Software Development: Focus on Your Strengths

Why Focus Matters

1. Depth Over Superficial Knowledge

2. Trust Is Built Through Consistency

3. Better Results Through Specialization

4. Knowing Your Limits Is a Strength

Professionalism Goes Beyond Technical Skills

The Balance: Specialize Without Becoming Narrow-Minded

Final Thoughts

Your Rate Limiter Works Until You Deploy a Second Server

The Problem With In-Memory Rate Limiting

Why This Matters in Production

A Better Approach: Use Redis

There is still a subtle problem

Redis Doesn't Automatically Make Every Rate Limiter Correct

1. Choose the right algorithm

2. Identify clients correctly

3. Set limits by endpoint

4. Consider an existing library

How to Test Your Rate Limiter

`Promise.race()` Doesn't Cancel Your Fetch Request: Here's Why

1. The Common Approach: `Promise.race()`

2. A Better Solution: `AbortSignal.timeout()`