DEV Community: Amrishkhan Sheik Abdullah

The Next.js Hydration Error Everyone Hits and How to Actually Fix It

Amrishkhan Sheik Abdullah — Tue, 18 Aug 2026 05:21:30 +0000

This is the second article in Real Coding Problems, Simple Fixes.

The first article was about a React search box showing old results because API responses came back in the wrong order.

This one is a little harder.

We are going to talk about one of the most confusing errors people hit when moving from normal React to Next.js:

Hydration failed because the server rendered HTML didn't match the client.

That error sounds serious. It also sounds like React is angry about something deep inside the framework.

Most of the time, the problem is much simpler:

The server rendered one version of the page, but the browser rendered a different version when React started.

Let's break that down with a real example.

The Real Problem

Imagine you are building a dashboard.

The dashboard has a theme toggle. If the user selected dark mode earlier, you store that choice in localStorage.

That feels normal:

theme = "dark"

So you write a component that reads the saved theme and renders the button text.

"use client";

import { useState } from "react";

export default function ThemeToggle() {
  const [theme, setTheme] = useState(() => {
    return localStorage.getItem("theme") || "light";
  });

  function toggleTheme() {
    const nextTheme = theme === "light" ? "dark" : "light";
    setTheme(nextTheme);
    localStorage.setItem("theme", nextTheme);
  }

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

If you are coming from a client-only React app, this may look fine.

But in Next.js, this can break.

You may see:

ReferenceError: localStorage is not defined

or:

Hydration failed because the server rendered HTML didn't match the client.

The confusing part is that the file already says:

"use client";

So why is this still a problem?

Why `"use client"` Does Not Mean "Only Runs in the Browser"

This is the part that trips up a lot of developers.

In Next.js App Router, "use client" means the component is allowed to use browser-side React features like:

useState
useEffect
event handlers
browser interactions after the page loads

But the first HTML can still be prepared before the browser fully takes over.

That means your first render must be safe for both worlds:

the server
the browser

The server does not have:

window
document
localStorage
sessionStorage
matchMedia

Those belong to the browser.

So if your render logic depends on them too early, Next.js can end up with different output on the server and the client.

That difference is what causes the hydration error.

What Hydration Means in Plain English

Think of Next.js like a restaurant preparing your table before you arrive.

The server sends ready-made HTML so the page appears quickly.

Then React loads in the browser and attaches all the interactive behavior:

clicks
state
event handlers
updates

That process is hydration.

For hydration to work cleanly, React expects the first browser render to match the HTML that came from the server.

If the server rendered:

<button>Current theme: light</button>

but the browser immediately renders:

<button>Current theme: dark</button>

React sees a mismatch.

That is the error.

The Bad Pattern

Here is the common mistake:

const [theme, setTheme] = useState(() => {
  return localStorage.getItem("theme") || "light";
});

This reads localStorage while React is calculating the initial render.

That is too early.

The server cannot read localStorage, and even if you add checks like this:

const savedTheme =
  typeof window !== "undefined"
    ? localStorage.getItem("theme")
    : "light";

you can still create different server and client output.

The server may render light.

The browser may instantly render dark.

Now the first HTML does not match.

Fix 1: Start With a Safe Default, Then Read Browser Storage

The safest beginner-friendly fix is:

Render the same default value on the server and first client render.
Read localStorage inside useEffect.
Update the UI after the component has mounted.

Here is the fixed version.

"use client";

import { useEffect, useState } from "react";

export default function ThemeToggle() {
  const [theme, setTheme] = useState("light");
  const [isReady, setIsReady] = useState(false);

  useEffect(() => {
    const savedTheme = localStorage.getItem("theme");

    if (savedTheme === "light" || savedTheme === "dark") {
      setTheme(savedTheme);
    }

    setIsReady(true);
  }, []);

  function toggleTheme() {
    const nextTheme = theme === "light" ? "dark" : "light";
    setTheme(nextTheme);
    localStorage.setItem("theme", nextTheme);
  }

  if (!isReady) {
    return <button disabled>Loading theme...</button>;
  }

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

Now the first render is predictable.

The component starts with:

const [theme, setTheme] = useState("light");

Then, after the browser is ready, useEffect reads localStorage.

Why does this work?

Because useEffect only runs in the browser after React has rendered.

So the server is no longer asked to read something it does not have.

Fix 2: Create a Reusable `useMounted` Hook

If you do this in multiple components, repeating isReady everywhere gets boring.

You can create a small hook:

import { useEffect, useState } from "react";

export function useMounted() {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
  }, []);

  return mounted;
}

Then use it like this:

"use client";

import { useEffect, useState } from "react";
import { useMounted } from "./useMounted";

export default function ThemeToggle() {
  const mounted = useMounted();
  const [theme, setTheme] = useState("light");

  useEffect(() => {
    if (!mounted) return;

    const savedTheme = localStorage.getItem("theme");

    if (savedTheme === "light" || savedTheme === "dark") {
      setTheme(savedTheme);
    }
  }, [mounted]);

  function toggleTheme() {
    const nextTheme = theme === "light" ? "dark" : "light";
    setTheme(nextTheme);
    localStorage.setItem("theme", nextTheme);
  }

  if (!mounted) {
    return <button disabled>Loading theme...</button>;
  }

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

The hook makes the intent clear:

Do not show browser-dependent UI until the component is mounted in the browser.

This is useful for theme, cart count, persisted filters, saved sidebar state, or anything else stored in the browser.

Fix 3: Build a Small `useLocalStorageValue` Hook

For a real project, I prefer making storage access explicit and reusable.

Here is a simple hook:

import { useEffect, useState } from "react";

export function useLocalStorageValue(key, defaultValue) {
  const [value, setValue] = useState(defaultValue);
  const [ready, setReady] = useState(false);

  useEffect(() => {
    const storedValue = localStorage.getItem(key);

    if (storedValue !== null) {
      setValue(storedValue);
    }

    setReady(true);
  }, [key]);

  function updateValue(nextValue) {
    setValue(nextValue);
    localStorage.setItem(key, nextValue);
  }

  return { value, setValue: updateValue, ready };
}

Now the component becomes smaller:

"use client";

import { useLocalStorageValue } from "./useLocalStorageValue";

export default function ThemeToggle() {
  const {
    value: theme,
    setValue: setTheme,
    ready,
  } = useLocalStorageValue("theme", "light");

  function toggleTheme() {
    const nextTheme = theme === "light" ? "dark" : "light";
    setTheme(nextTheme);
  }

  if (!ready) {
    return <button disabled>Loading theme...</button>;
  }

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

This is not a perfect hook for every storage case. For example, it only stores strings.

But the pattern is the important part:

use a safe default
read browser storage after mount
avoid changing the first render unexpectedly

Fix 4: Use `dynamic` With `ssr: false` for Browser-Only Widgets

Sometimes a component is completely browser-only.

Examples:

a chart library that needs window
a map widget
a rich text editor
a component that depends heavily on browser APIs

For those cases, you can tell Next.js not to server-render that component.

"use client";

import dynamic from "next/dynamic";

const BrowserOnlyChart = dynamic(() => import("./BrowserOnlyChart"), {
  ssr: false,
});

export default function AnalyticsPage() {
  return (
    <main>
      <h1>Analytics</h1>
      <BrowserOnlyChart />
    </main>
  );
}

This can be the right fix when the component simply cannot produce meaningful HTML on the server.

In the App Router, keep this dynamic usage inside a Client Component file. If you try to use ssr: false directly inside a Server Component, Next.js will complain.

But do not use it everywhere.

If you disable server rendering for too much of your page, you lose some of the benefits of Next.js:

faster first HTML
better SEO for meaningful content
less useful server-rendered output

Use it when the component is truly browser-only.

What About `suppressHydrationWarning`?

Next.js also gives you an escape hatch:

<span suppressHydrationWarning>
  {new Date().toLocaleTimeString()}
</span>

This tells React:

I know this content may be different. Do not warn me for this specific element.

This can be fine for small unavoidable differences, like a timestamp.

But it should not be your first fix for normal app state.

If your cart count, theme, auth UI, or dashboard content is mismatching, hiding the warning does not fix the actual problem. It only makes the warning quieter.

Most of the time, you should fix the render flow instead.

A Simple Debugging Checklist

When you see a hydration error, ask these questions:

Am I reading window, document, or localStorage during render?
Am I rendering Date.now() or Math.random() directly in JSX?
Does the server render one value while the browser immediately renders another?
Is my first render dependent on auth, theme, cart, or browser storage?
Is a third-party component using browser APIs before mount?
Is my HTML valid, or do I have tags nested incorrectly?

The goal is simple:

The server HTML and the first client render should match.

After that first render, React can update the UI normally.

The Mental Model

Here is the easiest way to remember it:

Server render:
Should not depend on browser-only data.

First client render:
Should match what the server rendered.

After mount:
Safe to read localStorage, window, document, and other browser APIs.

If you keep that order in your head, hydration errors become much less mysterious.

Final Takeaway

Hydration errors are not random.

They usually happen because your first browser render does not match the HTML that came from the server.

For localStorage, the practical fix is:

Start with a safe default
+ Read localStorage inside useEffect
+ Render browser-only UI after mount
+ Use dynamic imports only for truly browser-only components
+ Avoid suppressHydrationWarning unless you really mean it

Once you understand that, the error message becomes less scary.

It is just React saying:

I expected the first client render to match the server HTML, but it did not.

And now you know where to look.

References

Next.js docs: Text content does not match server-rendered HTML
React docs: hydrateRoot
React docs: useEffect
Next.js docs: Lazy loading Client Components and libraries

The React Search Bug That Shows Old Results and How to Fix It

Amrishkhan Sheik Abdullah — Mon, 17 Aug 2026 13:18:00 +0000

This is part of a series I like to think of as Real Coding Problems, Simple Fixes.

No fancy architecture. No interview puzzle. Just the kind of bug that shows up while building a normal app.

Today we are fixing a very common search bug:

The user types a new search term, but the UI sometimes shows results from an older search.

If you have built a search box, autocomplete field, customer lookup, product filter, user picker, or admin dashboard table, you have probably been close to this bug.

It usually does not happen every time. That is what makes it annoying. On your machine, with fast internet, everything may look fine. Then someone uses the app on a slower network and suddenly the search results feel haunted.

Let's make that bug visible, then fix it properly.

The Real Problem

Imagine you are building a customer lookup for a support dashboard.

The support agent starts typing a customer name:

a
am
amy

Your React component sends a request for each value:

GET /api/customers?search=a
GET /api/customers?search=am
GET /api/customers?search=amy

You probably expect the responses to come back in the same order.

But the internet does not promise that.

The request for amy might finish first. Then the older request for a might finish last. If your component blindly updates state whenever any response returns, the screen can end up showing results for a even though the input says amy.

That is the bug.

In simple words:

The latest thing the user typed is not always the latest response your app receives.

The Broken Version

Here is a small version of the problem.

import { useEffect, useState } from "react";

export default function CustomerSearch() {
  const [query, setQuery] = useState("");
  const [customers, setCustomers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState("");

  useEffect(() => {
    if (!query.trim()) {
      setCustomers([]);
      return;
    }

    async function searchCustomers() {
      setLoading(true);
      setError("");

      try {
        const response = await fetch(`/api/customers?search=${query}`);
        const data = await response.json();
        setCustomers(data.customers);
      } catch (err) {
        setError("Could not load customers.");
      } finally {
        setLoading(false);
      }
    }

    searchCustomers();
  }, [query]);

  return (
    <section>
      <label htmlFor="customer-search">Search customers</label>
      <input
        id="customer-search"
        value={query}
        onChange={(event) => setQuery(event.target.value)}
        placeholder="Type a customer name..."
      />

      {loading && <p>Searching...</p>}
      {error && <p>{error}</p>}

      <ul>
        {customers.map((customer) => (
          <li key={customer.id}>{customer.name}</li>
        ))}
      </ul>
    </section>
  );
}

At first glance, this looks reasonable.

When query changes, we fetch customers. When the response arrives, we put the customers into state.

The hidden problem is that every request is allowed to update the same customers state, even if that request is old news by the time it finishes.

Why This Happens

React is not doing anything weird here.

The bug comes from timing.

Let's say the user types quickly:

Search 1: "a"   -> slow response
Search 2: "am"  -> medium response
Search 3: "amy" -> fast response

The response order might be:

"amy" returns first
"am" returns second
"a" returns last

If all three responses call setCustomers, the oldest search can win just because it finished last.

That kind of bug is called a race condition.

You do not need to memorize the term. Just remember the practical version:

Multiple async tasks are trying to update the same screen, and the wrong one finishes last.

First Fix: Debounce the Input

Before we cancel old requests, we should also avoid creating too many requests.

If the user types a, am, amy quickly, we probably do not need to search after every single keypress. We can wait until the user pauses for a moment.

That is called debouncing.

Here is a small reusable hook:

import { useEffect, useState } from "react";

export function useDebounce(value, delay = 400) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timerId = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(timerId);
    };
  }, [value, delay]);

  return debouncedValue;
}

Now React will wait 400 milliseconds after the latest change before updating debouncedValue.

That means this:

a
am
amy

can become one actual search request instead of three.

But there is an important detail:

Debounce reduces the number of requests. It does not guarantee old requests can never update your UI.

If a request has already started, debouncing will not magically cancel it.

So debounce is helpful, but it is not the complete fix.

The Proper Fix: Cancel the Old Request

The browser gives us a built-in way to cancel a fetch request: AbortController.

The idea is simple:

Create an AbortController for the current request.
Pass its signal to fetch.
When the effect cleans up, call abort().
Ignore the abort error because it is expected.

Here is the fixed component.

import { useEffect, useState } from "react";
import { useDebounce } from "./useDebounce";

export default function CustomerSearch() {
  const [query, setQuery] = useState("");
  const [customers, setCustomers] = useState([]);
  const [status, setStatus] = useState("idle");
  const [error, setError] = useState("");

  const debouncedQuery = useDebounce(query, 400);

  useEffect(() => {
    const searchTerm = debouncedQuery.trim();

    if (!searchTerm) {
      setCustomers([]);
      setStatus("idle");
      setError("");
      return;
    }

    const controller = new AbortController();

    async function searchCustomers() {
      setStatus("loading");
      setError("");

      try {
        const response = await fetch(
          `/api/customers?search=${encodeURIComponent(searchTerm)}`,
          {
            signal: controller.signal,
          }
        );

        if (!response.ok) {
          throw new Error("Search request failed");
        }

        const data = await response.json();

        setCustomers(data.customers ?? []);
        setStatus("success");
      } catch (err) {
        if (err.name === "AbortError") {
          return;
        }

        setCustomers([]);
        setStatus("error");
        setError("Could not load customers. Please try again.");
      }
    }

    searchCustomers();

    return () => {
      controller.abort();
    };
  }, [debouncedQuery]);

  return (
    <section>
      <label htmlFor="customer-search">Search customers</label>

      <input
        id="customer-search"
        value={query}
        onChange={(event) => setQuery(event.target.value)}
        placeholder="Type a customer name..."
      />

      {status === "loading" && <p>Searching...</p>}
      {status === "error" && <p>{error}</p>}

      {status === "success" && customers.length === 0 && (
        <p>No customers found.</p>
      )}

      <ul>
        {customers.map((customer) => (
          <li key={customer.id}>
            <strong>{customer.name}</strong>
            <span> - {customer.email}</span>
          </li>
        ))}
      </ul>
    </section>
  );
}

Now when debouncedQuery changes, React runs the cleanup function for the previous effect.

That cleanup calls:

controller.abort();

So the older request is told:

You are no longer needed.

When fetch is aborted, it throws an error with the name AbortError. That is why we check this:

if (err.name === "AbortError") {
  return;
}

An aborted request is not a real failure from the user's point of view. It just means the user typed something newer.

What the Fixed Flow Looks Like

With the fixed version, the flow is cleaner:

User types "a"
Wait briefly
Start request for "a"

User changes input to "amy"
React cleans up the old effect
Request for "a" is aborted
Wait briefly
Start request for "amy"

Only the useful result updates the UI

This gives you two benefits:

You send fewer requests because of debounce.
You stop outdated requests because of AbortController.

That combination is much stronger than debounce alone.

A Tiny Mock API for Testing

If you want to test this locally, you can create an endpoint that responds after a random delay.

This makes the bug easier to reproduce.

Here is a tiny Express-style example:

const express = require("express");

const app = express();

const customers = [
  { id: 1, name: "Amy Chen", email: "amy@example.com" },
  { id: 2, name: "Amir Khan", email: "amir@example.com" },
  { id: 3, name: "Ana Lopez", email: "ana@example.com" },
  { id: 4, name: "Brian Stone", email: "brian@example.com" },
];

app.get("/api/customers", async (req, res) => {
  const search = String(req.query.search || "").toLowerCase();
  const delay = Math.floor(Math.random() * 1500);

  await new Promise((resolve) => setTimeout(resolve, delay));

  const matches = customers.filter((customer) =>
    customer.name.toLowerCase().includes(search)
  );

  res.json({ customers: matches });
});

app.listen(3000, () => {
  console.log("API running on http://localhost:3000");
});

The random delay is useful because real networks are not perfectly predictable either.

Try the broken component with this API and type quickly. You may see old results appear. Then switch to the fixed version and test again.

Common Mistakes to Avoid

Mistake 1: Only using debounce

Debounce is good for reducing noise.

But if a request has already started, debounce does not stop it.

Use debounce to avoid unnecessary requests. Use AbortController to cancel requests that are no longer relevant.

Mistake 2: Showing an error when a request was canceled

If the user types a new search term, canceling the old request is normal.

Do not show:

Something went wrong.

just because an old request was aborted.

Check for AbortError and quietly return.

Mistake 3: Forgetting empty input

If the user clears the search box, reset the results.

if (!searchTerm) {
  setCustomers([]);
  setStatus("idle");
  setError("");
  return;
}

This avoids showing old results when the input is empty.

Mistake 4: Not encoding the search term

Search text can contain spaces, symbols, and special characters.

Use encodeURIComponent before putting user input into a query string:

`/api/customers?search=${encodeURIComponent(searchTerm)}`

Could You Use a Library Instead?

Yes.

In a bigger app, you might use something like TanStack Query, SWR, or another data-fetching library. Those tools can help with caching, request state, retries, background refreshes, and more.

But even if you use a library later, it is still worth understanding this bug.

Because the root idea appears everywhere:

When async work finishes, make sure it is still relevant before updating the UI.

That applies to search boxes, file uploads, page filters, route changes, modal forms, and many other everyday features.

Final Takeaway

The bug is not that React is slow.

The bug is not that useEffect is broken.

The bug is that network responses can arrive in a different order than the requests were sent.

For search inputs, a practical fix is:

Debounce the input
+ Cancel outdated requests
+ Ignore expected abort errors
+ Reset state for empty input

That gives users a search box that feels stable, even when the network is not.

References

React docs: useEffect and race conditions
React docs: You Might Not Need an Effect
MDN: AbortController
MDN: AbortSignal

The Hidden Cost of Object Spread

Amrishkhan Sheik Abdullah — Thu, 09 Jul 2026 01:40:00 +0000

One of the most common pieces of JavaScript you'll find in modern codebases looks like this:

const nextState = {
  ...state,
  count: state.count + 1
}

React developers write it.

Redux developers write it.

Vue developers write it.

Angular developers write it.

Nearly every frontend framework encourages some variation of it.

It feels clean.

It feels immutable.

It feels modern.

It feels almost free.

But here's the uncomfortable truth:

Object spread is often far more expensive than most developers realize.

This doesn't mean object spread is bad.

It doesn't mean immutability is bad.

It doesn't mean you should stop using it.

But it does mean you should understand what it's actually doing.

Because once you understand the cost, you start making much better engineering decisions.

The Illusion

When developers see:

const nextState = {
  ...state,
  count: state.count + 1
}

they often mentally model it as:

Take state
Change count
Done

But that's not what happens.

JavaScript doesn't magically update the object.

Instead it performs something conceptually closer to:

const nextState = {}

for (const key in state) {
  nextState[key] = state[key]
}

nextState.count =
  state.count + 1

Notice the difference.

We're not updating.

We're copying.

Every property.

Every time.

What Actually Happens

Consider:

const user = {
  id: 1,
  name: "John",
  email: "john@example.com"
}

const updatedUser = {
  ...user,
  active: true
}

Internally:

Allocate New Object
↓
Copy id
↓
Copy name
↓
Copy email
↓
Add active

For three properties?

Nobody cares.

For thousands of properties?

You probably should.

The Cost Grows With Size

Imagine:

const hugeObject = {
  ...
}

containing:

10,000 properties

Now:

{
  ...hugeObject,
  updated: true
}

must:

Allocate New Object
+
Copy 10,000 Properties
+
Add One Property

Just to change one value.

That's not free.

The Famous Reduce Trap

This is one of the most common performance issues I see.

const usersById =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

Looks elegant.

Looks immutable.

Looks functional.

Looks expensive.

Let's see why.

Iteration 1

{}

Copy:

0 properties

Iteration 2

{
  1: user1
}

Copy:

1 property

Iteration 3

{
  1: user1,
  2: user2
}

Copy:

2 properties

Iteration 1000

Copy 999 properties

Total Work

What initially looks like:

O(n)

can become closer to:

O(n²)

because every iteration copies everything accumulated so far.

That is a very different performance profile.

The Loop Equivalent

Compare:

const usersById =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

with:

const usersById = {}

for (const user of users) {
  usersById[user.id] = user
}

The loop:

Creates One Object
Mutates One Object
Performs One Pass

No repeated copies.

No repeated allocations.

No repeated garbage collection.

Why React Popularized Object Spread

This is where things get interesting.

React didn't make object spread popular by accident.

React relies heavily on:

Reference Equality

Example:

if (
  previousState !== nextState
) {
  rerender()
}

This works beautifully when:

const nextState = {
  ...state,
  count: 1
}

because:

New Object
New Reference

React can instantly detect the change.

This is a great reason to use object spread.

But:

Useful
≠
Free

Deeply Nested Objects

This is where things get ugly.

Suppose:

const nextState = {
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: "Dubai"
    }
  }
}

You've probably written something similar.

Maybe many times.

Let's count.

Copy state
Copy user
Copy address
Update city

Multiple allocations.

Multiple copies.

For one change.

Why Immer Became Popular

This problem became so common that libraries emerged specifically to solve it.

One of the most popular is Immer.

Instead of:

const nextState = {
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: "Dubai"
    }
  }
}

Immer allows:

draft.user.address.city =
  "Dubai"

while still producing an immutable result.

This dramatically improves readability.

Garbage Collection Matters

Most developers focus on CPU.

But memory matters too.

Every spread operation creates:

Temporary Objects

Those objects eventually become:

Garbage

Which means:

Garbage Collection

must clean them.

The larger the application becomes:

More Allocations
↓
More Garbage
↓
More GC Work

Sometimes the bottleneck isn't computation.

It's memory churn.

The Hidden Cost In State Management

Consider:

return {
  ...state,
  loading: true
}

Looks harmless.

Now imagine:

100 updates per second

across:

Multiple Stores
Multiple Components
Large State Trees

Suddenly those allocations become measurable.

Not catastrophic.

Just measurable.

And that's the point.

When Object Spread Is Perfect

Let's be fair.

Object spread solves real problems.

Example:

const updatedUser = {
  ...user,
  active: true
}

Clear.

Readable.

Predictable.

For small objects:

Use it.

Without hesitation.

When You Should Be Careful

Pay attention when you see:

Large Collections

Large State Trees

Reducers Executing Frequently

Performance-Critical Loops

This is where spread begins to matter.

Benchmark Mentality

One of the biggest mistakes developers make is assuming:

Spread Is Slow

Spread Is Fast

Both are wrong.

The correct answer is:

It Depends

How many properties?

How often?

How frequently is the code executed?

How large are the objects?

Engineering is always contextual.

Real World Example: API Processing

Bad:

const result =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

Better:

const result = {}

for (const user of users) {
  result[user.id] = user
}

The second version scales significantly better.

Real World Example: React State

Good:

setUser({
  ...user,
  name: "John"
})

The object is small.

Readability wins.

Optimization would be pointless.

Real World Example: Deep Updates

Instead of:

{
  ...state,
  a: {
    ...state.a,
    b: {
      ...state.a.b,
      c: value
    }
  }
}

consider:

State normalization
Immer
Better state structure

Architecture often beats optimization.

Pros Of Object Spread

1. Readable

Intent is obvious.

2. Immutable

Reduces accidental mutations.

3. React-Friendly

Works perfectly with reference equality.

4. Predictable

Creates explicit state transitions.

5. Easy To Learn

Minimal cognitive overhead.

Cons Of Object Spread

1. Allocations

Every spread creates a new object.

2. Property Copying

The larger the object, the more expensive the copy.

3. Garbage Collection Pressure

Temporary objects accumulate.

4. Easy To Abuse In Reducers

Repeated spreads can become surprisingly expensive.

5. Deep Updates Become Ugly

Nested spreads quickly reduce readability.

The Real Lesson

The biggest mistake developers make with object spread is treating it as a free operation.

It isn't.

The second biggest mistake is treating it as a bad operation.

It isn't.

Object spread is a tool.

A very useful tool.

A very readable tool.

A very common tool.

But every immutable update has a cost.

The goal isn't avoiding object spread.

The goal is understanding when its benefits outweigh its costs.

Because once you understand the tradeoff, you stop blindly copying objects.

And start making deliberate engineering decisions.

What's Next?

In the next article we'll discuss:

Composability Is The Real Superpower

Because after exploring:

Reduce
Transducers
Functors
FlatMap
Monads
RxJS
Event Sourcing

you'll discover that all of them ultimately revolve around a single idea:

Composition

And that idea is far more important than any individual function.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Why Functional Code Can Be Slower

Amrishkhan Sheik Abdullah — Wed, 08 Jul 2026 04:22:00 +0000

Functional Programming has a marketing problem.

Or perhaps more accurately:

Functional Programming has a reality problem.

If you spend enough time reading articles about FP, you'll eventually encounter claims like:

More elegant

More composable

More predictable

More maintainable

And honestly?

Many of those claims are true.

I use functional patterns regularly.

I enjoy them.

I write about them.

This entire article series has been exploring concepts like:

Reduce
Transducers
Functors
Monads
RxJS
Event Sourcing

But there is a topic that rarely gets discussed honestly:

Functional code can be slower.

Sometimes dramatically slower.

And understanding why makes you a better engineer.

Because performance doesn't care how elegant your abstractions are.

The Myth

Many developers unconsciously assume:

More Functional
=
More Modern
=
More Efficient

This is not true.

Consider:

const usersById =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

Looks elegant.

Looks immutable.

Looks functional.

But it can also be incredibly expensive.

Why?

Because every iteration creates a brand-new object.

What Actually Happens

Suppose:

{
  a: 1,
  b: 2
}

becomes:

{
  ...obj,
  c: 3
}

JavaScript doesn't magically update the object.

It creates:

New Object
+
Copy Existing Properties
+
Add New Property

Every time.

Now imagine:

iterations.

You aren't just doing:

10000 writes

You're doing:

Thousands of object copies

which is a completely different cost.

The Loop Version

Compare:

const usersById = {}

for (const user of users) {
  usersById[user.id] = user
}

This mutates one object.

No copies.

No allocations.

No repeated spreads.

From a performance perspective:

The loop wins.

Almost every time.

Functional Doesn't Mean Free

Consider:

const result = users
  .map(transformA)
  .map(transformB)
  .map(transformC)

Looks clean.

But internally:

Array
↓
Array
↓
Array
↓
Array

Each map creates a new collection.

For:

items?

Nobody cares.

For:

items?

You probably should.

The Hidden Cost Of Immutability

One of the biggest performance tradeoffs in FP is immutability.

Example:

return {
  ...state,
  count: state.count + 1
}

versus:

state.count += 1
return state

The immutable version:

Allocates memory
Copies properties
Creates garbage

The mutable version:

Updates in place

Much cheaper.

Garbage Collection Is Not Free

Most performance discussions stop at CPU.

But memory matters too.

Every allocation creates work for:

Garbage Collector

Consider:

array
  .map(...)
  .filter(...)
  .map(...)
  .flatMap(...)

Each stage may create:

Temporary Objects
Temporary Arrays
Temporary Closures

Eventually:

GC Pause

must clean them.

Closures Have A Cost

Every callback:

x => x * 2

creates machinery.

Modern engines optimize aggressively.

But optimization is not magic.

Compare:

for (let i = 0; i < len; i++) {
  result[i] = data[i] * 2
}

with:

data.map(
  x => x * 2
)

The difference is often small.

But it exists.

And at scale:

Small differences accumulate.

Why Transducers Exist

Remember our Transducers article?

This problem is exactly why Transducers were invented.

Without Transducers:

data
  .filter(...)
  .map(...)
  .filter(...)
  .map(...)

Multiple passes.

Multiple arrays.

Multiple allocations.

With Transducers:

Single Pass
Single Reduction
No Intermediate Arrays

Same functionality.

Much better memory behavior.

Why RxJS Often Feels Fast

This surprises people.

RxJS can sometimes outperform traditional collection processing.

Why?

Because:

One Value
At A Time

Instead of:

Entire Collection

The pipeline processes:

Value
↓
Transform
↓
Next Value

Memory remains stable.

The V8 Factor

Modern JavaScript engines are incredibly smart.

But they have expectations.

For example:

{
  id: 1,
  name: "John"
}

and:

{
  name: "John",
  id: 1
}

may not be treated identically internally.

Hidden classes.

Inline caches.

Object shapes.

All influence performance.

Repeated object spreading can interfere with these optimizations.

Performance Is A Tradeoff

The mistake many developers make is assuming:

Readable
vs
Fast

is a binary choice.

It isn't.

Most systems spend their lives here:

Readable Enough
Fast Enough

That's the sweet spot.

A Practical Rule

For:

Small datasets
Normal APIs
Typical UI code

Choose clarity.

Always.

Nobody wins awards for micro-optimizing:

items.

When Performance Starts Mattering

Pay attention when:

Large datasets

Real-time processing

Streaming systems

Analytics

Data pipelines

Rendering loops

appear.

Now those abstractions become measurable.

The Most Expensive Functional Pattern

This pattern:

array.reduce(
  (acc, item) => ({
    ...acc,
    [item.id]: item
  }),
  {}
)

is probably responsible for more accidental JavaScript slowdowns than any other FP pattern.

It looks elegant.

It benchmarks terribly.

The Most Important Performance Lesson

Many developers ask:

Which is faster?

reduce()
or

for...of

Wrong question.

The real question is:

What work is being done?

Because:

reduce()

with mutation:

users.reduce(
  (acc, user) => {
    acc[user.id] = user
    return acc
  },
  {}
)

is very different from:

users.reduce(
  (acc, user) => ({
    ...acc,
    [user.id]: user
  }),
  {}
)

Same API.

Very different performance characteristics.

Pros Of Functional Code

1. Easier Composition

Functions combine naturally.

2. Easier Testing

Pure functions are predictable.

3. Better Abstractions

Patterns become reusable.

4. Less Shared Mutable State

Fewer side effects.

5. Better Reasoning

State transitions become explicit.

Cons Of Functional Code

1. More Allocations

Especially with immutable updates.

2. More Garbage Collection

Temporary objects accumulate.

3. Callback Overhead

Functions are not free.

4. Intermediate Collections

Repeated map/filter chains create extra work.

5. Can Hide Performance Problems

Elegant code often disguises expensive operations.

The Real Lesson

The biggest mistake developers make is turning programming paradigms into religions.

Functional Programming isn't better.

Object-Oriented Programming isn't better.

Procedural Programming isn't better.

They're tools.

And every tool has tradeoffs.

Functional patterns give us:

Composability

Predictability

Maintainability

But sometimes they cost:

Memory

CPU

Allocations

The best engineers understand both sides.

They know when to reach for:

map()
reduce()
flatMap()

And they know when a simple:

for...of

is exactly the right solution.

Because ultimately:

The goal isn't writing the most functional code.

The goal is writing the right code.

What's Next?

In the next article we'll discuss:

When a for...of Loop Is Better Than reduce()

Because after spending multiple articles exploring the power of reduce(), it's time to answer a question many developers quietly wonder:

Should I even be using reduce here?

And surprisingly often, the answer is:

No.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

When a `for...of` Loop Is Better Than `reduce()`

Amrishkhan Sheik Abdullah — Wed, 08 Jul 2026 01:28:00 +0000

A few years ago, I was obsessed with reduce().

Every problem looked like a reduction problem.

Need a lookup table?

users.reduce(...)

Need grouping?

users.reduce(...)

Need filtering?

users.reduce(...)

Need transformation?

users.reduce(...)

Need world peace?

Probably:

world.reduce(...)

Eventually I realized something.

The problem wasn't reduce().

The problem was me.

Because while reduce() is incredibly powerful, many developers eventually reach a stage where they start asking a more important question:

Should I even be using reduce() here?

And surprisingly often, the answer is:

No.

Sometimes a simple:

for...of

is easier to read.

Easier to debug.

Faster.

And ultimately the better engineering choice.

The Problem With Loving reduce() Too Much

Developers often discover:

reduce()

and suddenly realize:

It can do everything.

And that's true.

The problem is:

Can do everything

≠

Should do everything

Consider:

const usersById =
  users.reduce(
    (acc, user) => {
      acc[user.id] = user
      return acc
    },
    {}
  )

Reasonable.

Many teams would accept this.

Now consider:

const usersById = {}

for (const user of users) {
  usersById[user.id] = user
}

Question:

Which one is easier to understand?

For many developers:

The loop.

Cognitive Load Matters

Most discussions around reduce focus on:

Elegance

Composability

Functional Style

But software engineering has another important metric:

Cognitive Load

How much mental effort does it take to understand the code?

Reading A Loop

Most developers instantly understand:

const result = {}

for (const user of users) {
  result[user.id] = user
}

Mental model:

Create object

Loop

Add items

Done

Reading A Reduce

Now:

const result =
  users.reduce(
    (acc, user) => {
      acc[user.id] = user
      return acc
    },
    {}
  )

You must understand:

Accumulator

Initial State

Return Value

Reducer Contract

Not difficult.

But undeniably more concepts.

The "Everything Is Reduce" Trap

Consider:

const activeUserNames =
  users.reduce(
    (acc, user) => {
      if (user.active) {
        acc.push(user.name)
      }

      return acc
    },
    []
  )

Works.

But compare:

const activeUserNames = []

for (const user of users) {
  if (user.active) {
    activeUserNames.push(
      user.name
    )
  }
}

Which is clearer?

Many developers would argue:

The loop.

And that's okay.

The Hidden Mutation Problem

Ironically, many developers use reduce for functional purity.

Then immediately write:

acc.push(...)

or:

acc[user.id] = user

which mutates the accumulator.

Example:

users.reduce(
  (acc, user) => {
    acc.push(user.name)
    return acc
  },
  []
)

At this point:

You're already mutating.

So the purity argument disappears.

Now we're mainly comparing:

Reduce

vs

Loop

on readability and performance.

The Immutable Version Is Often Worse

Some developers try:

users.reduce(
  (acc, user) => [
    ...acc,
    user.name
  ],
  []
)

Looks functional.

But now:

New Array

Every Iteration

Which can become extremely expensive.

Especially on large datasets.

Debugging Matters

Imagine debugging:

users.reduce(
  (acc, user) => {
    ...
  },
  {}
)

versus:

for (const user of users) {
  ...
}

Where do most developers place breakpoints?

Usually:

Inside the loop.

Loops are naturally procedural.

Debuggers love procedural code.

Performance Matters Too

From the previous article:

Functional Code Can Be Slower

Many reduce implementations involve:

callbacks
closures
allocations
intermediate objects

Example:

users.reduce(
  (acc, user) => ({
    ...acc,
    [user.id]: user
  }),
  {}
)

This looks elegant.

But benchmarks terribly.

Compare:

const result = {}

for (const user of users) {
  result[user.id] = user
}

Usually much faster.

When reduce() Shines

This article is not anti-reduce.

Far from it.

There are scenarios where reduce is clearly superior.

Scenario 1: Mathematical Aggregation

const total =
  prices.reduce(
    (sum, price) =>
      sum + price,
    0
  )

Perfect.

Scenario 2: State Evolution

events.reduce(
  reducer,
  initialState
)

This is literally what reducers were designed for.

Scenario 3: Event Sourcing

From the previous article:

events.reduce(
  accountReducer,
  initialState
)

Excellent fit.

Scenario 4: Generic Reduction Logic

reduce()

expresses intent very clearly.

You're reducing many values into one.

When for...of Shines

Scenario 1: Building Objects

const map = {}

for (const item of items) {
  map[item.id] = item
}

Clear.

Fast.

Obvious.

Scenario 2: Complex Conditional Logic

for (const user of users) {
  if (...) {
    ...
  } else if (...) {
    ...
  }
}

Much easier to follow.

Scenario 3: Multiple Side Effects

for (const order of orders) {
  updateCache(order)
  logOrder(order)
  notify(order)
}

Trying to force this into reduce often becomes awkward.

Scenario 4: Early Exit

for (const user of users) {
  if (user.id === targetId) {
    break
  }
}

Reduce cannot naturally stop.

Loops can.

The Senior Developer Perspective

Junior developers often ask:

Which is better?

Senior developers ask:

Which is clearer?

Because maintainability usually dominates.

Not cleverness.

Not elegance.

Not theoretical purity.

The Most Important Rule

Don't optimize for:

Shortest Code

Optimize for:

Most Understandable Code

Future you will thank you.

Your teammates will thank you.

Your debugger will thank you.

Pros Of reduce()

1. Expresses Reduction Clearly

2. Great For State Evolution

3. Excellent For Event Processing

4. Composable

5. Powerful Abstraction

Cons Of reduce()

1. Higher Cognitive Load

2. Easy To Abuse

3. Can Hide Complexity

4. Harder To Debug

5. Often Slower Than Loops

Pros Of for...of

1. Extremely Readable

2. Easy To Debug

3. Supports Early Exit

4. Usually Faster

5. Lower Cognitive Overhead

Cons Of for...of

1. Less Declarative

2. Easier To Introduce Side Effects

3. More Boilerplate

4. Harder To Compose

5. Can Become Procedural Spaghetti

If misused.

The Real Lesson

The biggest mistake developers make with reduce() is treating it like a badge of sophistication.

It's not.

It's a tool.

A very powerful tool.

But still a tool.

Sometimes:

reduce()

is exactly right.

Sometimes:

for...of

is exactly right.

The best engineers don't pick sides.

They pick the clearest solution for the problem in front of them.

And surprisingly often, that solution looks a lot less clever than you might expect.

What's Next?

In the next article we'll discuss:

The Hidden Cost Of Object Spread

Because one innocent-looking pattern:

{
  ...obj,
  newValue
}

has probably caused more accidental JavaScript performance issues than most developers realize.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Composability Is The Real Superpower

Amrishkhan Sheik Abdullah — Thu, 25 Jun 2026 04:45:00 +0000

Over the last few articles, we've explored a surprising number of concepts:

reduce()
Transducers
Functors
FlatMap
Monads
RxJS
scan()
Event Sourcing
Performance tradeoffs
Object spread

At first glance, these seem like completely different topics.

Some are functional programming concepts.

Some are architecture patterns.

Some are JavaScript APIs.

Some are performance discussions.

But there is a common thread connecting all of them.

And it's not:

reduce()

It's not:

monads

It's not:

RxJS

The real superpower behind all of them is:

COMPOSITION

Because the best software systems aren't built from giant functions.

They're built from small pieces that work together.

And once you understand that idea, everything from React to Unix to Event Sourcing starts making a lot more sense.

The Biggest Mistake Developers Make

Many developers spend years learning functions.

Senior engineers spend years learning patterns.

The difference matters.

For example:

const usersById =
  users.reduce(...)

Interesting.

But not transformative.

The truly valuable question is:

How do I combine small pieces
into larger systems?

That question changes everything.

Because software is ultimately a composition problem.

Why Large Functions Rot

Let's start with something most developers have seen.

function processCheckout(
  order
) {
  validateOrder(order)

  calculateTax(order)

  applyDiscount(order)

  reserveInventory(order)

  generateInvoice(order)

  sendConfirmationEmail(order)

  updateAnalytics(order)

  createShipment(order)

  notifyWarehouse(order)

  updateCRM(order)
}

Looks harmless.

Now imagine this function after three years.

500 Lines

Multiple Conditions

Feature Flags

Edge Cases

Special Customers

Regional Logic

Eventually:

Nobody Wants To Touch It

The function becomes fragile.

Every change becomes risky.

Small Functions Scale Better

Instead:

const validateOrder =
  order => order

const calculateTax =
  order => order

const applyDiscount =
  order => order

const reserveInventory =
  order => order

Each function has:

One Responsibility

This matters because:

Small Pieces
↓
Are Easier To Understand
↓
Easier To Test
↓
Easier To Replace

That is composition.

Unix Understood This Decades Ago

One of the greatest examples of composability isn't JavaScript.

It's Unix.

Consider:

cat logs.txt |
grep ERROR |
sort |
uniq

Each command does one thing.

cat
↓
grep
↓
sort
↓
uniq

Individually:

Not impressive.

Together:

Extremely powerful.

Fifty years later:

We're still using this pattern.

That should tell us something.

React Won Because Of Composition

Many developers think React succeeded because of JSX.

Or hooks.

Or virtual DOM.

I don't think that's the real reason.

React succeeded because of composition.

<App>
  <Header />
  <Sidebar />
  <Dashboard />
</App>

Every component is:

Reusable
Composable
Replaceable

You don't build one giant UI.

You build pieces.

Then compose them.

RxJS Is Composition

Consider:

stream.pipe(
  filter(isValid),
  map(transform),
  scan(reducer, initialState)
)

At first glance:

This looks like operators.

But underneath:

Function
↓
Function
↓
Function

Each operator produces a new stream.

The real value isn't:

map()

The real value is:

The Ability To Combine Them

Again:

Composition.

Event Sourcing Is Composition

In the previous article we saw:

events.reduce(
  reducer,
  initialState
)

Now imagine:

Events
↓
Projection A

Projection B

Projection C

Projection D

The same event stream can generate:

Account Balances
Reports
Analytics
Audit Logs

Why?

Because reducers compose.

The architecture becomes flexible because the pieces are composable.

Microservices Done Right

Good microservices are not:

Many Services

Good microservices are:

Composable Services

Each service should be:

Independent
Replaceable
Focused

The goal isn't:

More Services

The goal is:

Better Composition

Unfortunately many teams create:

Distributed Monoliths

which have all the complexity and none of the benefits.

Composition Beats Inheritance

Consider classical inheritance.

class Animal {}

class Bird extends Animal {}

class FlyingBird extends Bird {}

Eventually:

FlyingSwimmingBird

appears.

Then:

FlyingSwimmingHuntingBird

And things become ridiculous.

Composition offers a different approach.

const canFly = {}

const canSwim = {}

const canHunt = {}

Combine capabilities.

Instead of inheriting everything.

This scales far better.

Building A Tiny Utility Library

One of the simplest examples of composition is pipe().

const pipe =
  (...fns) =>
  input =>
    fns.reduce(
      (acc, fn) =>
        fn(acc),
      input
    )

Usage:

const addOne =
  x => x + 1

const double =
  x => x * 2

const square =
  x => x * x

const process =
  pipe(
    addOne,
    double,
    square
  )

console.log(
  process(2)
)

Output:

Why?

2
↓
3
↓
6
↓
36

Small pieces.

Large result.

Real World Example: API Processing

Suppose we're building an API Studio.

Bad:

function processRequest(
  request
) {
  // 1000 lines
}

Better:

Parse
↓
Validate
↓
Authenticate
↓
Execute
↓
Transform
↓
Format
↓
Visualize

Each stage:

Independent.

Composable.

Replaceable.

Testable.

This architecture scales much better over time.

Real World Example: Payment Processing

Instead of:

function processPayment() {
  ...
}

Think:

Validate
↓
Fraud Check
↓
Charge Card
↓
Generate Receipt
↓
Notify User

Each step becomes reusable.

You can swap providers.

Add new logic.

Remove old logic.

Without rewriting the entire system.

Real World Example: CI/CD Pipelines

GitHub Actions.

GitLab CI.

Azure DevOps.

All rely heavily on composition.

Checkout
↓
Install
↓
Test
↓
Build
↓
Deploy

Independent stages.

Combined together.

Again:

Composition.

Why Composition Feels So Powerful

Because it gives us leverage.

Imagine:

100 Independent Functions

versus:

1 Giant Function

The first system creates:

Reuse
Flexibility
Scalability

The second creates:

Coupling
Complexity
Fragility

This is why composability appears everywhere.

The Hidden Connection Between Everything We've Learned

Let's revisit the series.

Reduce:

Composable State Transitions

Transducers:

Composable Transformations

Functors:

Composable Mapping

FlatMap:

Composable Container Operations

Monads:

Composable Computations

RxJS:

Composable Streams

Event Sourcing:

Composable Reducers

Different vocabulary.

Same underlying idea.

Pros Of Composable Systems

1. Easier To Test

Small units are easier to validate.

2. Easier To Reuse

Components can appear in multiple places.

3. Easier To Replace

Swap one piece without rewriting everything.

4. Better Scalability

Systems evolve naturally.

5. Better Team Collaboration

Multiple engineers can work independently.

Cons Of Composition

Let's be honest.

Composition is not free.

1. Too Many Small Functions

Overdoing it creates fragmentation.

2. Debugging Can Become Harder

Execution paths may span many layers.

3. Abstraction Overload

Not every problem needs twenty tiny functions.

4. Indirection

Following the flow can take time.

5. Overengineering Risk

Sometimes a simple function is enough.

The Real Lesson

The biggest lesson from this entire series isn't about:

reduce()

monads

RxJS

Those are merely tools.

The deeper lesson is:

Small Things
That Work Together
Beat
Big Things
That Do Everything

The most successful software systems aren't powerful because of individual functions.

They're powerful because those functions compose.

That's true for:

React
Unix
RxJS
Event Sourcing
Microservices
Modern Frontend Architectures
Functional Programming

Different ecosystems.

Same principle.

And once you start recognizing composition everywhere, you begin to understand why some systems remain maintainable for decades while others become unmanageable after a few months.

Because ultimately:

Composability is the real superpower.

What's Next?

In the next article we'll move from theory to practice:

Building Your Own Functional Utility Library

We'll implement:

pipe()
compose()
map()
filter()
reduce()
flatMap()
Transducer helpers

from scratch and explore what those implementations teach us about JavaScript itself.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Why Retry Is One Of The Most Dangerous Keywords In Software

Amrishkhan Sheik Abdullah — Sat, 13 Jun 2026 06:27:00 +0000

Few lines of code look more innocent than this:

retry(3)

It feels responsible.

Professional.

Resilient.

After all, networks fail.

Servers become unavailable.

Databases occasionally time out.

Retrying seems like the obvious solution.

And sometimes it is.

But after enough years building production systems, I've become convinced of something:

Retry is one of the most dangerous keywords in software.

Not because retries are bad.

Because retries amplify everything.

Good systems become more reliable.

Bad systems become disasters.

The problem is that many developers treat retries as a reliability feature when they're actually a distributed systems feature.

And distributed systems are where simple ideas go to become complicated.

Why Retries Exist

Imagine:

await fetch("/api/users");

The request fails.

Maybe:

Network hiccup
Temporary database issue
Load balancer restart
Service deployment

The operation might succeed if attempted again.

So we write:

retry(3)

Seems reasonable.

And in many cases:

It Works

Which is why retries become popular.

The Dangerous Assumption

Most developers unconsciously assume:

Failure
=
Operation Did Not Execute

Unfortunately that's not always true.

A request can:

Execute Successfully
↓
Response Never Arrives

From the client's perspective:

Failure

From the server's perspective:

Success

Now a retry becomes dangerous.

The Double Payment Problem

Imagine a payment service.

await chargeCard(order);

The card processor successfully charges:

$100

The response is lost due to a network issue.

Client sees:

Request Failed

and retries.

await chargeCard(order);

again.

Now:

Charge #1 = Success
Charge #2 = Success

The customer paid twice.

Nobody wrote bad logic.

The retry created the bug.

The Email Storm Problem

Consider:

await sendWelcomeEmail(user);

Email provider accepts the message.

Response times out.

Application retries.

await sendWelcomeEmail(user);

again.

Customer receives:

Welcome!
Welcome!
Welcome!
Welcome!

Support ticket created.

Marketing team confused.

The retry succeeded.

Too well.

Retries Amplify Side Effects

This is the core issue.

Pure operations:

2 + 2

can run forever.

Nothing changes.

Side effects are different.

Examples:

Charge Card
Create Order
Send Email
Book Seat
Reserve Inventory
Send SMS

Each execution changes reality.

Retries repeat reality.

And reality doesn't always appreciate repetition.

The Thundering Herd Problem

One failed request isn't scary.

Ten thousand retries are.

Imagine:

Service A

becomes slow.

Clients start retrying.

Traffic doubles.

Service becomes slower.

More retries occur.

Traffic doubles again.

Eventually:

Small Failure
↓
Massive Outage

This is known as:

The Thundering Herd Problem

And retries are often the cause.

When Retries Attack Databases

Suppose:

Database

is under heavy load.

Queries start timing out.

Application retries automatically.

Now:

More Queries
↓
More Load
↓
More Timeouts
↓
More Retries

You have accidentally built a denial-of-service attack against your own database.

Why Idempotency Matters

In the previous article we discussed:

Idempotency

This is where it becomes critical.

Without idempotency:

Retry
=
Repeat Side Effects

With idempotency:

Retry
=
Same Result

A retry becomes safe.

That's why reliable systems almost always combine:

Retries
+
Idempotency

rather than using retries alone.

Not Every Failure Should Be Retried

A common mistake:

retry(3)

for every error.

Consider:

400 Bad Request

Retrying won't help.

The request is invalid.

Or:

401 Unauthorized

Retrying won't magically authenticate the user.

Good retry policies distinguish between:

Transient Failures

and

Permanent Failures

Exponential Backoff Exists For A Reason

Bad:

Retry Immediately
Retry Immediately
Retry Immediately

Better:

1 Second
↓
2 Seconds
↓
4 Seconds
↓
8 Seconds

This is:

Exponential Backoff

and it prevents systems from overwhelming already struggling services.

Real World Example: Flight Booking

Imagine:

Reserve Seat

times out.

Client retries.

Without protection:

Seat Reserved Twice

or:

Two Different Seats Reserved

Now inventory becomes inconsistent.

Airlines spend enormous effort preventing these scenarios.

Because retries happen constantly.

Real World Example: Webhooks

Webhook providers often retry automatically.

For example:

Payment Completed

may arrive:

1 Time
2 Times
5 Times

depending on delivery conditions.

Systems that assume:

Exactly Once

processing usually fail eventually.

Systems that expect retries survive.

Real World Example: Message Queues

Kafka.

RabbitMQ.

SQS.

Azure Service Bus.

All assume:

Messages May Be Delivered Again

because reliability is more important than uniqueness.

Consumers must be designed accordingly.

Common Retry Mistakes

Retrying Everything

Not every failure is recoverable.

Retrying Immediately

Often makes outages worse.

Ignoring Idempotency

Creates duplicate side effects.

Infinite Retries

Eventually becomes infinite damage.

Hiding Failures

Retries should not become a substitute for monitoring.

Pros Of Retries

1. Better Reliability

Transient failures disappear.

2. Better User Experience

Temporary outages become invisible.

3. Improved Resilience

Systems tolerate instability.

4. Reduced Manual Intervention

Many failures self-heal.

5. Better Distributed Systems

Network failures become manageable.

Cons Of Retries

1. Duplicate Operations

Without idempotency.

2. Traffic Amplification

Can worsen outages.

3. Cascading Failures

One issue spreads across systems.

4. Increased Complexity

Backoff strategies become necessary.

5. Hidden Production Problems

Retries can mask deeper issues.

The Real Lesson

Most developers think retries exist to make software more reliable.

That's only partially true.

Retries don't eliminate failures.

They change failures.

Sometimes they transform:

Temporary Network Problem

into:

Duplicate Payment

Sometimes they transform:

Slow Database

into:

Full System Outage

That's why experienced engineers don't ask:

Should We Retry?

They ask:

What Happens If This Operation Executes Twice?

Because once retries enter the picture, duplicate execution is no longer an edge case.

It's a certainty.

And reliable systems are designed with that reality in mind.

What's Next?

In the next article we'll discuss:

The Myth Of Stateless Systems

Because many systems described as "stateless" are actually storing state somewhere else.

And that distinction turns out to be extremely important.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Idempotency Is More Important Than You Think

Amrishkhan Sheik Abdullah — Sat, 13 Jun 2026 06:21:00 +0000

Most developers don't think about idempotency until production breaks.

That's not because idempotency is an advanced concept. It's because everything works perfectly when requests succeed exactly once.

Unfortunately, real systems don't work that way.

Networks fail.

Browsers retry.

Mobile applications reconnect.

Users double-click buttons.

Webhooks arrive multiple times.

Message queues redeliver events.

And suddenly a simple operation that was supposed to happen once happens twice.

Or three times.

Or ten times.

At that moment, one of the most important concepts in software engineering becomes impossible to ignore:

An operation should produce the same result no matter how many times it is executed.

That's idempotency.

And it's one of the foundations of reliable software.

What Is Idempotency?

A function is idempotent if performing it multiple times produces the same final result as performing it once.

For example:

user.isActive = true;

Running this once:

user.isActive = true;

or a hundred times:

user.isActive = true;
user.isActive = true;
user.isActive = true;

produces the same outcome.

The user remains active.

This operation is idempotent.

Now compare that with:

user.balance += 100;

Running it once:

Balance = 100

Running it twice:

Balance = 200

Running it three times:

Balance = 300

This operation is not idempotent.

The result changes every time it executes.

Why This Matters More Than Most Developers Realize

Consider a simple payment API.

await chargeCard(order);

Looks harmless.

Now imagine this sequence:

Payment Request Sent
↓
Card Charged Successfully
↓
Response Lost Due To Network Failure
↓
Client Retries Request
↓
Card Charged Again

The payment system behaved correctly.

The network failed.

The client retried.

The customer got charged twice.

The bug isn't in the payment logic.

The bug is that the operation wasn't idempotent.

The Reality Of Distributed Systems

Most software developers think in terms of:

Request
↓
Response
↓
Done

Production systems look more like:

Request
↓
Timeout
↓
Retry
↓
Duplicate Request
↓
Partial Failure
↓
More Retries

The moment you have:

Networks
APIs
Queues
Mobile Apps
Multiple Servers

you have duplicates.

Not maybe.

Definitely.

The only question is whether your system handles them safely.

The Double-Click Problem

One of the simplest examples.

Imagine an e-commerce checkout page.

User clicks:

Place Order

Nothing happens for two seconds.

User clicks again.

Now two requests arrive.

Request A
Create Order

and

Request B
Create Order

If the backend simply executes both:

Order #1001
Order #1002

The customer now owns two orders.

This happens more often than many developers think.

Why HTTP Introduced Idempotent Methods

HTTP recognized this problem decades ago.

Consider:

GET /users/123

Calling it:

1 Time
10 Times
100 Times

doesn't change the system.

GET is idempotent.

Now consider:

POST /orders

Every call creates something new.

POST is generally not idempotent.

That's why retries become dangerous.

PUT Is Often Safer Than POST

Suppose we create a user.

POST:

POST /users

Multiple calls:

User A
User B
User C

Potentially multiple records.

Now:

PUT /users/123

Multiple calls:

Update User 123
Update User 123
Update User 123

Same final state.

This is one reason PUT is considered idempotent.

The Webhook Nightmare

Webhooks are one of the best examples of why idempotency matters.

Stripe.

GitHub.

PayPal.

Most webhook providers explicitly tell you:

Your endpoint must handle duplicate events.

Why?

Because delivery guarantees are difficult.

Imagine:

Payment Completed
↓
Webhook Sent
↓
Server Timeout
↓
Provider Retries

Now your endpoint receives:

Payment Completed
Payment Completed

twice.

If your system isn't idempotent:

Invoice Generated Twice
Email Sent Twice
Inventory Reserved Twice

Chaos follows.

Message Queues Assume Duplicates

Kafka.

RabbitMQ.

SQS.

Azure Service Bus.

Most messaging systems prioritize reliability.

That means:

At Least Once Delivery

instead of:

Exactly Once Delivery

Because exactly-once delivery is extremely difficult.

The implication is important.

Consumers must be prepared to process duplicate messages.

This is where idempotency becomes essential.

Event Sourcing Depends On It

In a previous article we discussed Event Sourcing.

Imagine an event stream:

OrderCreated
PaymentReceived
InventoryReserved

Now imagine:

PaymentReceived

arrives twice.

Without idempotency:

Balance += Payment
Balance += Payment

The projection becomes corrupted.

Reliable event processing requires idempotent handlers.

The Idempotency Key Pattern

One of the most common solutions is:

Idempotency Keys

Example:

POST /payments

Idempotency-Key:
abc123

Backend receives:

abc123

and stores:

Request
Result

If the same request arrives again:

abc123

the server returns the previous result instead of executing the operation again.

From the client's perspective:

Retry Safe

This pattern powers many payment systems.

Real World Example: Flight Bookings

Imagine booking a flight.

Customer submits payment.

Network times out.

Browser retries.

Without idempotency:

Two Payments
Two Bookings

Now support teams become involved.

With idempotency:

Same Booking
Same Payment
Same Result

No problem.

The retry becomes harmless.

Real World Example: API Studio

Suppose we're building an API testing platform.

User sends:

POST /create-user

five times accidentally.

Should the server create:

5 Users

or:

1 User

The answer depends on the business requirement.

Idempotency is not purely technical.

It's often a business decision.

Why Exactly-Once Is Mostly A Myth

Many developers initially aim for:

Exactly Once Processing

The problem is that distributed systems make this incredibly expensive.

Instead, many successful systems choose:

At Least Once Delivery
+
Idempotent Consumers

This is often simpler and more reliable.

Common Mistakes

Assuming Retries Are Safe

They aren't.

Retries amplify non-idempotent behavior.

Ignoring Duplicate Webhooks

Every major webhook provider warns about this.

Many developers still forget.

Using Auto-Increment IDs As Deduplication

Duplicates often arrive before the new record is visible.

Trusting The Network

Networks fail constantly.

Design accordingly.

Treating Idempotency As An Optimization

It's not.

It's a reliability requirement.

Pros Of Idempotent Systems

1. Safe Retries

Clients can retry without fear.

2. Better Reliability

Transient failures become easier to handle.

3. Simpler Distributed Systems

Duplicate messages stop being catastrophic.

4. Better User Experience

Double-clicks don't create duplicate operations.

5. More Resilient Event Processing

Replay and recovery become safer.

Cons Of Implementing Idempotency

Let's be honest.

Idempotency is not free.

1. Additional Storage

Keys and processed requests often need tracking.

2. More Complexity

Deduplication logic must exist somewhere.

3. Edge Cases

Determining whether two requests are truly identical can be difficult.

4. Operational Overhead

Retention and cleanup strategies become necessary.

5. Design Effort

You must think about failures upfront.

The Real Lesson

Most developers think software executes like this:

Request
↓
Success
↓
Done

Production systems look more like:

Request
↓
Timeout
↓
Retry
↓
Duplicate
↓
Retry
↓
Partial Failure
↓
Retry Again

Once you accept that reality, your design philosophy changes.

You stop asking:

Will This Request Succeed?

and start asking:

What Happens If It Runs Twice?

That single question prevents an enormous number of production incidents.

Because in distributed systems, duplicates are inevitable.

Reliable systems aren't the ones that avoid duplicates.

They're the ones that make duplicates harmless.

And that's exactly what idempotency gives you.

What's Next?

In the next article we'll discuss:

Why Retry Is One Of The Most Dangerous Keywords In Software

Because once you understand idempotency, you begin to realize something surprising:

retry(3)

might be one of the most dangerous lines of code in your entire system.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Why Abstractions Leak

Amrishkhan Sheik Abdullah — Fri, 12 Jun 2026 05:16:00 +0000

One of the most dangerous moments in a developer's career is when an abstraction works perfectly.

Not because success is bad.

But because perfect abstractions create an illusion.

The illusion is:

I don't need to know what's underneath.

For a while, that's true.

Then production happens.

Then scale happens.

Then edge cases happen.

Then reality happens.

And suddenly:

The abstraction leaks.

This idea is so common in software engineering that it has a name:

The Law of Leaky Abstractions

And once you see it, you'll notice it everywhere.

What Is An Abstraction?

An abstraction hides complexity.

Example:

fetch("/users")

Looks simple.

Behind that line:

DNS Lookup

TCP Connection

TLS Handshake

HTTP Request

Network Routing

Server Processing

Serialization

Response Parsing

Thousands of things happen.

The abstraction hides them.

That's the point.

Why We Need Abstractions

Imagine writing:

openSocket()
performTLSHandshake()
buildHTTPRequest()
serializeHeaders()
sendRequest()
readResponse()
parseJSON()

every time.

Nobody wants that.

Abstractions make software possible.

Without them:

Modern Software Would Not Exist

The Problem

The abstraction hides complexity.

It does not remove complexity.

That distinction matters.

Because eventually:

fetch("/users")

fails.

And suddenly:

You Need To Understand
The Things It Was Hiding

Example #1: ORMs

Developers love ORMs.

Example:

const users =
  await User.findAll()

Looks beautiful.

Looks simple.

Looks harmless.

Then somebody adds:

user.posts

inside a loop.

Suddenly:

100 Users

100 Queries

Database Meltdown

The famous:

N + 1 Query Problem

appears.

The ORM abstraction leaked.

Example #2: React

React hides DOM manipulation.

Instead of:

document.createElement(...)

we write:

<UserCard />

Wonderful.

Until:

5000 Components

Frequent Updates

Slow Rendering

Now you need to understand:

Reconciliation

Memoization

Reference Equality

Rendering Lifecycle

The abstraction leaked.

Example #3: Promise.all()

Looks simple.

await Promise.all(
  requests
)

Feels magical.

Until:

5000 Requests

hit production.

Now:

Rate Limits

Memory Pressure

Connection Pools

Timeouts

suddenly matter.

Again:

The abstraction leaked.

Example #4: Kubernetes

Developers often say:

Kubernetes Makes Deployment Easy

Until something breaks.

Then:

Pods

Services

Ingress

DNS

Networking

Volumes

Secrets

Scheduling

become your problem.

The abstraction leaked.

Example #5: Functional Programming

Even FP abstractions leak.

Consider:

users
  .map(...)
  .filter(...)
  .map(...)

Looks elegant.

Then:

1 Million Records

arrive.

Now:

Allocations

Garbage Collection

Intermediate Arrays

matter.

Suddenly:

You Need To Understand
The Implementation

The abstraction leaked.

The Reduce Example

Earlier in this series we discussed:

users.reduce(
  (acc, user) => ({
    ...acc,
    [user.id]: user
  }),
  {}
)

Looks elegant.

Looks immutable.

Looks functional.

At scale:

O(n²)

The abstraction leaked.

The implementation became important.

Why Leaks Are Inevitable

Many developers think:

Good Abstractions
Never Leak

This is impossible.

Because reality is more complex than any abstraction.

Always.

Eventually:

Performance

Memory

Concurrency

Networking

Storage

Scale

find a way through.

The Database Example

You can use:

User.findAll()

for years.

Then one day:

Database CPU 100%

Now suddenly:

SELECT *
FROM users

matters.

The SQL was always there.

The ORM simply hid it.

The Cloud Example

Many developers think:

Serverless Means
No Servers

It doesn't.

It means:

Someone Else's Servers

Eventually:

Cold Starts

Execution Limits

Concurrency Limits

appear.

The abstraction leaks.

Why Senior Engineers Feel Different

Junior engineers often trust abstractions.

Senior engineers respect abstractions.

Those are not the same thing.

A senior engineer sees:

fetch(...)

and mentally understands:

Network

Latency

Retries

Timeouts

Failures

even when they aren't visible.

That's experience.

The Best Developers Learn Both Layers

Bad approach:

Only Learn Frameworks

Also bad:

Only Learn Internals

The best developers learn:

Abstraction
+
Implementation

Both matter.

Real World Example: API Studio

Suppose we're building an API Studio.

We expose:

Send Request

as a button.

Simple.

Behind the scenes:

DNS

TLS

Headers

Body Serialization

Compression

Retries

Timeouts

Certificates

Users shouldn't see those details.

But we must understand them.

Because eventually:

A Bug Will Live There

Real World Example: Git

Git feels simple.

git commit

Until:

Merge Conflicts

Detached HEAD

Rebase Failures

Corrupted Refs

appear.

Then:

Objects

Trees

Blobs

Refs

Packfiles

suddenly matter.

The abstraction leaked.

The Hidden Connection To This Entire Series

Reduce leaked.

We learned Transducers.

Transducers leaked.

We learned composition.

RxJS leaked.

We learned streams.

Event Sourcing leaked.

We learned reducers.

Every article in this series is actually a story about abstractions leaking.

And that's not a bad thing.

That's how deeper understanding develops.

Pros Of Abstractions

1. Faster Development

Less code.

2. Better Productivity

Focus on business logic.

3. Lower Cognitive Load

Hide complexity.

4. Better Reusability

Shared solutions.

5. Better Collaboration

Common interfaces.

Cons Of Abstractions

1. Performance Surprises

The implementation is hidden.

2. Debugging Complexity

Problems occur below the abstraction.

3. Knowledge Gaps

Developers stop learning fundamentals.

4. Vendor Lock-In

Sometimes abstractions become cages.

5. Leaks

Eventually reality breaks through.

Always.

The Real Lesson

The biggest mistake developers make is assuming abstractions remove complexity.

They don't.

They move complexity.

That's a huge difference.

The complexity still exists.

It's simply hidden until something goes wrong.

And when that moment arrives, the engineers who understand both layers:

The Abstraction

and

The Implementation

are the ones who solve the problem.

That's why great engineers never stop at the API.

Eventually they look underneath.

Because every abstraction leaks.

And that's where the real learning begins.

What's Next?

In the next article we'll discuss:

The Two Hard Things In Computer Science

Because one famous joke contains an uncomfortable amount of truth:

There are only two hard things
in Computer Science:

Cache Invalidation

Naming Things

and Off-by-One Errors

And surprisingly, that joke explains a huge amount of software engineering.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Building Your Own Functional Utility Library

Amrishkhan Sheik Abdullah — Thu, 11 Jun 2026 04:51:00 +0000

One of the best ways to understand a programming concept is to build it yourself.

Over the last several articles we've discussed:

Reduce
Transducers
Functors
FlatMap
Monads
RxJS
Composition

And while those concepts sound sophisticated, something surprising happens when you start implementing them.

Most of them are tiny.

Really tiny.

In fact, many of the abstractions that power modern functional programming can be implemented in a few lines of JavaScript.

And once you build them yourself, they stop feeling magical.

They start feeling obvious.

So let's build a small functional utility library from scratch.

Not because you'll replace existing libraries.

But because the implementation teaches more than the API ever will.

Why Build Your Own?

Most developers use libraries like:

Lodash
Ramda
fp-ts
RxJS

without understanding the ideas underneath.

That's completely fine.

But implementing the primitives yourself teaches:

How Composition Works

How Reduce Works

How FlatMap Works

How Transducers Work

How Functional Pipelines Work

Which is far more valuable than memorizing APIs.

The Simplest Utility: Identity

Let's start with the most boring function imaginable.

const identity = x => x

Usage:

identity(5)

Output:

Not impressive.

But surprisingly useful.

Many FP abstractions rely on identity.

Implementing pipe()

One of the most useful utilities in any FP library.

const pipe =
  (...fns) =>
  input =>
    fns.reduce(
      (acc, fn) => fn(acc),
      input
    )

Usage:

const addOne =
  x => x + 1

const double =
  x => x * 2

const square =
  x => x * x

const process =
  pipe(
    addOne,
    double,
    square
  )

console.log(
  process(2)
)

Output:

Flow:

2
↓
3
↓
6
↓
36

This is composition in action.

Implementing compose()

Some developers prefer right-to-left composition.

const compose =
  (...fns) =>
  input =>
    fns.reduceRight(
      (acc, fn) => fn(acc),
      input
    )

Usage:

const process =
  compose(
    square,
    double,
    addOne
  )

Produces:

2
↓
3
↓
6
↓
36

Same result.

Different direction.

Building map()

Let's implement our own map.

const map =
  transform =>
  array =>
    array.map(transform)

Usage:

const double =
  map(x => x * 2)

double([1,2,3])

Output:

[2,4,6]

Notice something.

We made it:

Curried

which allows composition.

Building filter()

const filter =
  predicate =>
  array =>
    array.filter(predicate)

Usage:

const activeOnly =
  filter(
    user => user.active
  )

Again:

Composable.

Building reduce()

const reduce =
  (reducer, initial) =>
  array =>
    array.reduce(
      reducer,
      initial
    )

Usage:

const sum =
  reduce(
    (acc, n) => acc + n,
    0
  )

sum([1,2,3])

Output:

Creating Reusable Pipelines

Now things get interesting.

const processUsers =
  pipe(
    filter(
      user => user.active
    ),
    map(
      user => user.name
    )
  )

Usage:

processUsers(users)

This begins to feel like a miniature Ramda.

Building flatMap()

From an earlier article:

const flatMap =
  transform =>
  array =>
    array.flatMap(
      transform
    )

Usage:

flatMap(
  user => user.roles
)

Output:

[
  "admin",
  "editor",
  "viewer"
]

Again:

Tiny implementation.

Huge usefulness.

Implementing a Tiny Maybe Monad

Let's build a minimal Maybe type.

const Maybe = value => ({
  map(fn) {
    return value == null
      ? Maybe(null)
      : Maybe(fn(value))
  },

  flatMap(fn) {
    return value == null
      ? Maybe(null)
      : fn(value)
  },

  value() {
    return value
  }
})

Usage:

Maybe("John")
  .map(
    name =>
      name.toUpperCase()
  )
  .value()

Output:

JOHN

You've just built a Monad.

Without category theory.

Implementing Transducers

Let's revisit Transducers.

Map Transducer:

const mapping =
  fn =>
  reducer =>
  (acc, value) =>
    reducer(
      acc,
      fn(value)
    )

Filter Transducer:

const filtering =
  predicate =>
  reducer =>
  (acc, value) =>
    predicate(value)
      ? reducer(acc, value)
      : acc

Compose:

const transducer =
  filtering(
    x => x % 2 === 0
  )(
    mapping(
      x => x * 2
    )(
      (acc, value) => {
        acc.push(value)
        return acc
      }
    )
  )

Single pass.

No intermediate arrays.

Exactly as discussed earlier.

Building A Tiny Stream

Let's build a very small Observable.

const Stream = (
  subscribe
) => ({
  subscribe,

  map(fn) {
    return Stream(
      observer =>
        subscribe(
          value =>
            observer(
              fn(value)
            )
        )
    )
  }
})

Usage:

const stream =
  Stream(observer => {
    observer(1)
    observer(2)
    observer(3)
  })

stream
  .map(x => x * 2)
  .subscribe(
    console.log
  )

Output:

2
4
6

Tiny implementation.

Huge insight.

What We Learned

A surprising pattern emerges.

Most abstractions are:

Much Simpler
Than Their Names Suggest

Functors:

map()

Monads:

flatMap()

Transducers:

Composable Reducers

RxJS:

Composable Streams

Composition:

Functions Combined

The terminology sounds intimidating.

The implementations are often tiny.

Real World Example

Suppose we're processing API responses.

const processResponse =
  pipe(
    filter(
      item => item.active
    ),
    map(
      item => ({
        id: item.id,
        name: item.name
      })
    )
  )

Clean.

Composable.

Reusable.

Pros Of Building Your Own Utilities

1. Deep Understanding

You learn the underlying mechanics.

2. Better Debugging

Abstractions stop feeling magical.

3. Improved Architecture Skills

You begin designing composable systems.

4. Stronger JavaScript Knowledge

Language fundamentals become clearer.

5. Better Library Evaluation

You understand what libraries are actually doing.

Cons Of Building Your Own Utilities

1. Not Production Ready

Use mature libraries when appropriate.

2. Missing Edge Cases

Production libraries handle many corner cases.

3. Maintenance Cost

You now own the code.

4. Performance Optimizations

Libraries often contain years of tuning.

5. Reinventing The Wheel

Sometimes unnecessary.

The Real Lesson

The biggest surprise in functional programming isn't how complicated it is.

It's how simple most of the building blocks actually are.

The scary names:

Functor

Monad

Transducer

often hide tiny implementations.

The real value isn't the code.

The real value is the mindset.

Learning how to build these utilities teaches you how to think in composition.

And that skill transfers everywhere:

Frontend Development
Backend Systems
Event Processing
API Design
Architecture

Because ultimately:

Great software isn't built from giant frameworks.

It's built from small pieces that work together.

What's Next?

In the next article we'll tackle one of the most misunderstood concepts in software engineering:

Why Abstractions Leak

Because every abstraction eventually breaks down.

And understanding why helps you design better systems.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

Event Sourcing Is Just Reduce Over Time

Amrishkhan Sheik Abdullah — Sun, 07 Jun 2026 04:20:00 +0000

Event Sourcing has a reputation problem.

The moment someone mentions it, the conversation usually becomes:

Event Store
CQRS
Snapshots
Replay
Projections
Distributed Systems

And most developers immediately think:

This sounds complicated.

I used to think the same thing.

Then one day I realized something.

The core idea behind Event Sourcing is not complicated at all.

In fact, most JavaScript developers already know it.

They just know it by a different name.

reduce()

That's right.

The architecture behind some of the largest systems in the world can be explained using a function most developers learn in their first year of JavaScript.

Because Event Sourcing is really just:

Reduce applied to business events.

And once you see that, everything starts making sense.

The Traditional Way We Store State

Suppose we have a bank account.

Current balance:

{
  accountId: 1,
  balance: 125
}

Most systems store the current state.

When money is deposited:

125
↓
175

The old value disappears.

The database simply stores:

{
  accountId: 1,
  balance: 175
}

Simple.

But something important is lost.

What Actually Happened?

Imagine an auditor asks:

How did we reach 175?

The database cannot answer.

It only knows:

Current State

The history is gone.

Event Sourcing Stores Events Instead

Instead of storing:

{
  balance: 175
}

we store:

[
  {
    type: "DEPOSIT",
    amount: 100
  },
  {
    type: "DEPOSIT",
    amount: 100
  },
  {
    type: "WITHDRAW",
    amount: 25
  }
]

Notice something.

We no longer store state.

We store:

History

Reconstructing State

Now let's calculate the balance.

const accountReducer =
  (balance, event) => {
    switch (event.type) {
      case "DEPOSIT":
        return balance + event.amount

      case "WITHDRAW":
        return balance - event.amount

      default:
        return balance
    }
  }

const balance =
  events.reduce(
    accountReducer,
    0
  )

Output:

Look carefully.

That is Event Sourcing.

Literally.

The Formula Behind Everything

Every Event Sourced system follows:

Initial State
+
Event
=
Next State

Which should feel familiar.

Because that's exactly how reducers work.

(state, event) =>
  nextState

Same idea.

Different scale.

Redux Was Preparing You For This

Consider Redux.

const reducer = (
  state,
  action
) => {
  switch(action.type) {
    case "INCREMENT":
      return state + 1

    default:
      return state
  }
}

Actions:

[
  { type: "INCREMENT" },
  { type: "INCREMENT" },
  { type: "INCREMENT" }
]

Process them:

actions.reduce(
  reducer,
  0
)

Output:

Sound familiar?

It should.

Because Redux and Event Sourcing are siblings.

Both are:

State Evolution
Through Events

Why Event Sourcing Exists

The obvious question:

Why not just store the state?

Good question.

The answer is:

History has value.

Benefit #1: Audit Trail

Traditional database:

Balance = 175

Event Sourcing:

Deposit 100
Deposit 100
Withdraw 25

Now you know exactly how the state was produced.

Benefit #2: Time Travel

Want the account balance yesterday?

Simply replay events until yesterday.

eventsUntilYesterday.reduce(
  reducer,
  0
)

Done.

Benefit #3: Debugging

Imagine a production bug.

Traditional system:

State is wrong.

Why?

Nobody knows.

Event Sourcing:

Replay the events.

The bug becomes reproducible.

Benefit #4: Rebuild Everything

Imagine:

New Reporting System

needs historical data.

Traditional database:

Too late.

Event Sourcing:

Replay events.
Generate reports.

History becomes reusable.

Projections Are Just More Reducers

This is another concept that sounds scary.

A projection is simply:

A reducer that creates a view.

Example:

const ordersByCustomer =
  (state, event) => {
    if (
      event.type ===
      "ORDER_CREATED"
    ) {
      state[
        event.customerId
      ] ??= []

      state[
        event.customerId
      ].push(event)
    }

    return state
  }

Process events.

Build a customer report.

That's a projection.

CQRS Starts Making Sense

Most CQRS explanations make it sound mysterious.

Reality:

Commands
↓
Generate Events
↓
Reducers
↓
State

That's the heart of CQRS.

The terminology is harder than the concept.

Event Sourcing Meets RxJS

In the previous article we discussed:

scan()

Remember:

scan()
=
reduce()
+
time

Now imagine events arriving continuously.

Deposit 100

(wait)

Withdraw 25

(wait)

Deposit 50

Suddenly:

events$.pipe(
  scan(
    accountReducer,
    0
  )
)

becomes Event Sourcing in real time.

Real World Example: Shopping Cart

Events:

Add Item
Add Item
Remove Item

Reducer:

(cart, event) =>
  nextCart

Replay events.

Get cart state.

Event Sourcing.

Real World Example: Inventory

Events:

Stock Added
Stock Removed
Stock Returned

Reducer:

(inventory, event) =>
  nextInventory

Replay.

Current stock.

Event Sourcing.

Real World Example: User Activity

Events:

Login
Purchase
Logout

Store events forever.

Build analytics later.

No extra tracking tables required.

Why Event Sourcing Feels Difficult

Because people usually start here:

Event Store
CQRS
Snapshots
Distributed Systems

Instead of here:

events.reduce(
  reducer,
  initialState
)

The second explanation is far easier.

Because that's the core idea.

Everything else is optimization.

The Problem With Event Sourcing

Let's be fair.

Event Sourcing is not free.

1. More Complexity

A CRUD application is usually simpler.

2. Data Migration Becomes Harder

Events are history.

Changing history is dangerous.

3. Event Design Matters

Poorly designed events become technical debt.

4. Learning Curve

Teams must understand the model.

5. Not Every System Needs It

A simple blog probably doesn't need Event Sourcing.

Pros Of Event Sourcing

1. Complete Audit History

Nothing is lost.

2. Time Travel

State at any point in time.

3. Easier Debugging

Replay events.

Reproduce bugs.

4. Flexible Reporting

Build projections later.

5. Natural Fit For Distributed Systems

Events scale surprisingly well.

The Real Lesson

The biggest lesson I learned about Event Sourcing was that it wasn't really about architecture.

It was about a pattern I already knew.

Current State
+
Event
=
Next State

Which is:

(state, event) =>
  nextState

Which is:

Reduce

At its core, Event Sourcing is simply reducing business events into state.

The architecture becomes much less intimidating once you realize that.

And suddenly concepts like:

CQRS
Projections
Replay
Snapshots

start feeling like natural extensions rather than mysterious enterprise magic.

What's Next?

In the next article we'll discuss:

Why Functional Code Can Be Slower

Because after spending several articles discussing elegant abstractions, it's time to address a controversial reality:

Beautiful code
≠
Fast code

And understanding that tradeoff makes you a much better engineer.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

scan() Is Reduce For Infinite Data

Amrishkhan Sheik Abdullah — Sat, 06 Jun 2026 04:11:00 +0000

If you've used RxJS for any meaningful amount of time, you've probably encountered scan().

Maybe you've seen code like this:

interval(1000)
  .pipe(
    scan(
      (count) => count + 1,
      0
    )
  )

And maybe you've thought:

Okay...

It accumulates stuff.

Seems useful.

Then you moved on.

I did too.

For a long time, I treated scan() as just another RxJS operator.

One more thing to memorize.

Then I realized something.

scan() isn't a special RxJS operator.

It's simply reduce() adapted for data that never ends.

And once you understand that, a huge part of reactive programming suddenly becomes much easier.

The Limitation Of reduce()

Let's start with something familiar.

const total =
  [1, 2, 3, 4]
    .reduce(
      (sum, n) => sum + n,
      0
    )

console.log(total)

Output:

Simple.

The reducer processes:

and eventually produces:

But notice something important.

Reduce only works because:

The collection ends.

At some point:

Array Finished
↓
Emit Final Result

That is fundamental.

Reduce needs an ending.

What Happens When Data Never Ends?

Consider:

interval(1000)

Output:

When does it end?

Potentially never.

So if we tried:

reduce()

What would happen?

The answer:

Nothing.

Because reduce is waiting for completion.

And completion never arrives.

Enter scan()

RxJS introduced:

scan()

for exactly this problem.

Example:

interval(1000)
  .pipe(
    scan(
      (sum, value) =>
        sum + value,
      0
    )
  )

Output:

Interesting.

Instead of waiting until the end:

scan()
emits every intermediate state.

Visualizing The Difference

Reduce:

Scan:

Every intermediate state becomes visible.

The Formula Is Identical

Reduce:

(accumulator, value) =>
  nextAccumulator

Scan:

(accumulator, value) =>
  nextAccumulator

Same function signature.

Same concept.

Different timing.

That is why I like describing scan as:

Reduce for infinite data.

The Hidden Relationship To Redux

This is where things get interesting.

Suppose:

const reducer = (
  state,
  action
) => {
  switch (action.type) {
    case "INCREMENT":
      return state + 1

    default:
      return state
  }
}

Sound familiar?

That's Redux.

Now imagine actions arriving over time.

INCREMENT
INCREMENT
INCREMENT

What happens?

0
↓
1
↓
2
↓
3

That's scan.

Literally.

Redux is conceptually a scan over actions.

State Management Is Just scan()

Let's build a tiny state store.

const actions$ = new Subject()

Reducer:

const reducer = (
  state,
  action
) => {
  switch (action.type) {
    case "ADD":
      return state + action.value

    default:
      return state
  }
}

Store:

const state$ =
  actions$.pipe(
    scan(reducer, 0)
  )

Dispatch:

actions$.next({
  type: "ADD",
  value: 5
})

actions$.next({
  type: "ADD",
  value: 10
})

Output:

5
15

We just built reactive state management using scan.

Event Sourcing Is Also scan()

Consider a bank account.

Events:

Deposit 100
Deposit 50
Withdraw 25

Reducer:

const accountReducer =
  (balance, event) => {
    switch (event.type) {
      case "DEPOSIT":
        return balance +
          event.amount

      case "WITHDRAW":
        return balance -
          event.amount
    }
  }

Traditional:

events.reduce(
  accountReducer,
  0
)

Result:

Now imagine events arriving live.

Deposit 100
(wait)

Deposit 50
(wait)

Withdraw 25

Suddenly:

scan()

becomes the natural choice.

Event sourcing becomes a continuous reduction process.

Why scan() Feels Magical

Because it combines two powerful ideas.

First:

State

Second:

Time

The result:

State Evolution Over Time

Which is exactly what most applications are doing.

Real World Example: Shopping Cart

Actions:

Add Product
Add Product
Remove Product

Scan:

cartActions$
  .pipe(
    scan(
      cartReducer,
      []
    )
  )

Output:

Cart Version 1
Cart Version 2
Cart Version 3

Every state change emitted automatically.

Real World Example: Live Analytics

Visitors arrive.

Visitor
Visitor
Visitor
Visitor

Scan:

visitors$
  .pipe(
    scan(
      count => count + 1,
      0
    )
  )

Output:

1
2
3
4
5
...

Live metrics become trivial.

Real World Example: Game Score

Player scores:

10
20
50

Scan:

score$
  .pipe(
    scan(
      (total, score) =>
        total + score,
      0
    )
  )

Output:

10
30
80

Perfect for dashboards.

Performance Considerations

A common misconception:

scan()
stores all previous values

It doesn't.

Normally:

Previous State
+
Current Value
=
New State

Only the accumulator survives.

Memory usage remains constant.

Which makes scan suitable for:

Live streams
WebSockets
Telemetry
Monitoring
Analytics

Why Most Developers Misunderstand scan()

Because they learn:

Operator Names

instead of:

Underlying Concepts

When you memorize:

scan()

it feels random.

When you realize:

scan()
=
reduce()
+
time

it becomes obvious.

Pros Of scan()

1. Perfect For Infinite Streams

Works where reduce cannot.

2. Great For State Management

Redux-like patterns emerge naturally.

3. Constant Memory Usage

Only current state is required.

4. Easy To Compose

Works beautifully with RxJS pipelines.

5. Foundation Of Reactive Architecture

Many reactive systems are built around scan.

Cons Of scan()

1. Can Be Misused

Not every stream needs accumulated state.

2. State Logic Can Become Complex

Large reducers become difficult to maintain.

3. Debugging Deep Pipelines Can Be Hard

Especially when multiple scans exist.

4. Requires Thinking In Streams

Which takes time to learn.

5. Easy To Confuse With reduce()

The names are similar.

The behavior is not.

The Real Lesson

The biggest lesson I learned about scan() was that it wasn't really an RxJS operator.

Just like:

reduce

wasn't really about arrays.

And:

map

wasn't really about arrays either.

The real abstraction is:

Current State
+
New Value
=
Next State

Reduce applies that idea to finite collections.

Scan applies that idea to data that keeps arriving.

Once you understand that relationship, RxJS stops feeling like a collection of mysterious operators.

It starts feeling like a natural extension of concepts you already know.

And that is usually the moment reactive programming finally clicks.

What's Next?

In the next article we'll leave RxJS behind and move into software architecture:

Event Sourcing Is Just Reduce Over Time

Because once you understand:

reduce()
scan()
state evolution

you're only one step away from understanding the architecture behind some of the most scalable systems ever built.

About The Author

Hi, I'm Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I'm also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

DEV Community: Amrishkhan Sheik Abdullah

The Next.js Hydration Error Everyone Hits and How to Actually Fix It

The Real Problem

Why "use client" Does Not Mean "Only Runs in the Browser"

What Hydration Means in Plain English

The Bad Pattern

Fix 1: Start With a Safe Default, Then Read Browser Storage

Fix 2: Create a Reusable useMounted Hook

Fix 3: Build a Small useLocalStorageValue Hook

Fix 4: Use dynamic With ssr: false for Browser-Only Widgets

What About suppressHydrationWarning?

A Simple Debugging Checklist

The Mental Model

Final Takeaway

References

The React Search Bug That Shows Old Results and How to Fix It

The Real Problem

The Broken Version

Why This Happens

First Fix: Debounce the Input

The Proper Fix: Cancel the Old Request

What the Fixed Flow Looks Like

A Tiny Mock API for Testing

Common Mistakes to Avoid

Mistake 1: Only using debounce

Mistake 2: Showing an error when a request was canceled

Mistake 3: Forgetting empty input

Mistake 4: Not encoding the search term

Could You Use a Library Instead?

Final Takeaway

References

The Hidden Cost of Object Spread

The Illusion

What Actually Happens

The Cost Grows With Size

The Famous Reduce Trap

Iteration 1

Iteration 2

Iteration 3

Iteration 1000

Total Work

The Loop Equivalent

Why React Popularized Object Spread

Deeply Nested Objects

Why Immer Became Popular

Garbage Collection Matters

The Hidden Cost In State Management

When Object Spread Is Perfect

When You Should Be Careful

Benchmark Mentality

Real World Example: API Processing

Real World Example: React State

Real World Example: Deep Updates

Pros Of Object Spread

1. Readable

2. Immutable

3. React-Friendly

4. Predictable

5. Easy To Learn

Cons Of Object Spread

1. Allocations

2. Property Copying

3. Garbage Collection Pressure

4. Easy To Abuse In Reducers

5. Deep Updates Become Ugly

The Real Lesson

What's Next?

About The Author

Why Functional Code Can Be Slower

The Myth

What Actually Happens

The Loop Version

Functional Doesn't Mean Free

The Hidden Cost Of Immutability

Garbage Collection Is Not Free

Closures Have A Cost

Why Transducers Exist

Why RxJS Often Feels Fast

The V8 Factor

Performance Is A Tradeoff

Why `"use client"` Does Not Mean "Only Runs in the Browser"

Fix 2: Create a Reusable `useMounted` Hook

Fix 3: Build a Small `useLocalStorageValue` Hook

Fix 4: Use `dynamic` With `ssr: false` for Browser-Only Widgets

What About `suppressHydrationWarning`?