DEV Community: Amrishkhan Sheik Abdullah

RxJS Is Just Arrays Over Time

Amrishkhan Sheik Abdullah — Fri, 05 Jun 2026 04:06:00 +0000

RxJS has a reputation problem.

Mention RxJS in a JavaScript discussion and you'll usually get one of two reactions.

The first:

I love RxJS.

The second:

I have no idea what's going on.

There is rarely an in-between.

And honestly, I understand why.

Most RxJS tutorials immediately throw developers into a sea of operators:

map
filter
switchMap
mergeMap
concatMap
combineLatest
forkJoin
zip
scan

It feels like learning an entirely new programming language.

But what if I told you that most RxJS operators are concepts you already know?

What if the problem isn't RxJS?

What if the problem is how RxJS is taught?

Because once I understood one simple idea, RxJS suddenly became much easier:

RxJS is just Arrays over Time.

Not exactly.

But close enough that it dramatically simplifies how you think about Observables.

Start With Something Familiar

Consider an Array.

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

We can transform it.

const doubled = numbers.map(
  x => x * 2
)

console.log(doubled)

Output:

[2, 4, 6, 8]

We can filter it.

const even = numbers.filter(
  x => x % 2 === 0
)

Output:

[2, 4]

We can reduce it.

const total = numbers.reduce(
  (sum, x) => sum + x,
  0
)

Output:

Nothing surprising.

Every JavaScript developer understands this.

Now Imagine The Values Arrive Over Time

Instead of:

[1,2,3,4]

imagine:

1
(wait)
2
(wait)
3
(wait)
4

The values are the same.

The only difference is:

Space
↓

Time

That is the key insight.

Enter Observables

An Observable might emit:

over time.

Example:

import {
  interval
} from "rxjs"

interval(1000)

Output:

0
1
2
3
4
...

One value every second.

Instead of holding values simultaneously like an Array, an Observable delivers values gradually.

map() Works Exactly The Same

Array:

[1, 2, 3]
  .map(x => x * 2)

Observable:

interval(1000)
  .pipe(
    map(x => x * 2)
  )

Output:

0
2
4
6
8
...

The transformation is identical.

Only the timing differs.

filter() Works Exactly The Same

Array:

numbers.filter(
  x => x % 2 === 0
)

Observable:

interval(1000)
  .pipe(
    filter(
      x => x % 2 === 0
    )
  )

Output:

0
2
4
6
8
...

Again:

Same operation.

Different delivery mechanism.

scan() Is Reduce For Infinite Data

This is where many RxJS developers finally have their "aha" moment.

Arrays use:

reduce()

Example:

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

Output:

But Observables can be infinite.

They never finish.

So:

reduce()

often doesn't make sense.

Instead RxJS gives us:

scan()

Example:

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

Output:

This is:

Reduce
Over Time

And once you see that, scan becomes incredibly intuitive.

flatMap Exists Here Too

In the previous article we discussed:

flatMap()

Arrays:

users.flatMap(
  user => user.permissions
)

RxJS:

searchText$
  .pipe(
    mergeMap(
      text =>
        api.search(text)
    )
  )

Same problem.

Same solution.

The difference is:

Arrays
↓

Nested Collections

versus

Observables
↓

Nested Streams

switchMap, mergeMap and concatMap

These operators confuse almost everyone initially.

The reason is simple.

Arrays don't have time.

Observables do.

Suppose:

Search A
Search B
Search C

happen rapidly.

Now:

Which API calls should survive?

That is what these operators answer.

mergeMap

Run everything.

A
B
C

All continue.

concatMap

Queue everything.

A
↓

B
↓

C

switchMap

Cancel old work.

A ❌

B ❌

C ✅

Perfect for search boxes.

Why RxJS Feels Hard

Because developers often memorize operators.

Instead of understanding patterns.

If you think:

map
filter
scan
flatMap

then RxJS becomes much simpler.

Because you've already seen these concepts before.

In Arrays.

Real World Example: Search Autocomplete

User types:

a
ap
app
appl
apple

Without RxJS:

You manually manage:

timers
cancellation
race conditions

With RxJS:

search$
  .pipe(
    debounceTime(300),
    distinctUntilChanged(),
    switchMap(
      query =>
        api.search(query)
    )
  )

This is why RxJS exists.

It turns asynchronous complexity into composable transformations.

Real World Example: WebSocket Streams

Messages arrive continuously.

Message 1
Message 2
Message 3

Treating them as a stream allows:

messages$
  .pipe(
    filter(
      msg => msg.priority
    ),
    map(
      msg => msg.payload
    )
  )

Exactly like Arrays.

Except the values arrive over time.

Performance Considerations

Arrays:

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

may create intermediate arrays.

RxJS:

stream
  .pipe(
    map(...),
    filter(...)
  )

usually processes values incrementally.

One item at a time.

This can significantly reduce memory pressure for large streams.

Pros Of Thinking This Way

1. RxJS Becomes Easier

Most operators stop feeling magical.

2. Reuse Existing Knowledge

Array knowledge transfers directly.

3. Better Mental Models

Patterns become obvious.

4. Easier Debugging

You stop treating operators as black boxes.

5. Strong Foundation For Reactive Programming

Everything else builds on these concepts.

Cons Of The Analogy

1. Arrays Are Finite

Observables may be infinite.

2. Time Changes Everything

Cancellation becomes important.

3. Concurrency Doesn't Exist In Arrays

RxJS operators must handle it.

4. Error Handling Differs

Streams behave differently from collections.

5. The Analogy Eventually Breaks

At advanced levels.

But it remains extremely useful.

The Real Lesson

The biggest mistake people make with RxJS is treating it as something completely new.

It isn't.

Most of its core ideas already exist in JavaScript.

You've seen:

map()
filter()
reduce()
flatMap()

before.

RxJS simply applies those ideas to values that arrive over time.

And once you realize that:

Observable

≈

Array Over Time

the entire library becomes much less intimidating.

Not because the complexity disappeared.

But because you finally have a mental model that makes sense.

What's Next?

In the next article we'll revisit one of the most misunderstood operators in RxJS:

scan() Is Reduce For Infinite Data

Because understanding scan() unlocks:

RxJS state management
Redux-like patterns
Event sourcing
Reactive architectures

and ultimately connects everything back to the humble reduce() function where this series began.

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.

You've Been Using Monads Without Realizing It

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

Let's get the scary part out of the way.

The word:

Monad

has probably scared away more developers than any other term in programming.

The moment somebody mentions Monads, the conversation usually becomes:

Category Theory
Endofunctors
Monoids
Kleisli Composition
Higher-Kinded Types

Most developers immediately think:

This isn't for me.

Which is unfortunate.

Because Monads are actually one of the most practical abstractions in software engineering.

And if you've ever used:

Promise.then(...)

Array.flatMap(...)

RxJS switchMap(...)

then you've already been using Monads.

You just didn't know the name.

Why Developers Fear Monads

Monads suffer from a marketing problem.

Most concepts in programming are taught from examples.

For example:

const doubled =
  [1,2,3].map(
    x => x * 2
  )

Nobody starts by defining Arrays using abstract mathematics.

We start with examples.

Monads are often taught backwards.

The theory comes first.

The intuition comes last.

Let's fix that.

The Problem That Creates Monads

Imagine we have:

const users = [
  {
    id: 1,
    orders: [101, 102]
  },
  {
    id: 2,
    orders: [103]
  }
]

If we do:

users.map(
  user => user.orders
)

we get:

[
  [101, 102],
  [103]
]

Nested arrays.

We saw this in the previous article.

To solve it:

users.flatMap(
  user => user.orders
)

Result:

FlatMap removes the extra container layer.

The Same Problem Exists Everywhere

Arrays are not special.

Consider Promises.

Promise.resolve(10)
  .then(x => {
    return Promise.resolve(
      x * 2
    )
  })

What do we get?

Not:

Promise<Promise<number>>

Instead:

Promise<number>

The nesting disappears.

Why?

Because Promise.then behaves like FlatMap.

The Monad Recipe

Every Monad has two operations.

A way to put a value into the container:

Value
↓
Container<Value>

For Promises:

Promise.resolve(10)

For Arrays:

[10]

For RxJS:

of(10)

And a way to chain operations that return containers:

flatMap

or equivalent.

That is essentially the Monad pattern.

Arrays Are Monads

Most developers never hear this.

But Arrays are Monads.

Let's prove it.

Create a value:

const value = [10]

Chain computations:

const result =
  value.flatMap(
    x => [x * 2]
  )

Output:

[20]

Now chain again:

const result =
  [10]
    .flatMap(x => [x * 2])
    .flatMap(x => [x + 1])

Output:

[21]

Each step returns a container.

FlatMap composes them.

Monad behavior.

Promises Are Monads

This one surprises people.

Promise.resolve(10)
  .then(x =>
    Promise.resolve(
      x * 2
    )
  )
  .then(x =>
    Promise.resolve(
      x + 1
    )
  )

Result:

Promise<21>

Not:

Promise<
  Promise<
    Promise<21>
  >
>

Promises flatten automatically.

Which means Promises satisfy the same pattern.

Why Async/Await Feels Natural

Async/await became popular because it hides Monad plumbing.

This:

const user =
  await fetchUser()

const orders =
  await fetchOrders(
    user.id
  )

feels straightforward.

Underneath:

fetchUser()
  .then(user =>
    fetchOrders(user.id)
  )

is doing Monad composition.

JavaScript developers use Monads daily without realizing it.

RxJS Is Monad City

Consider:

searchText$
  .pipe(
    switchMap(
      text => api.search(text)
    )
  )

Without switchMap:

Observable<
  Observable<SearchResult>
>

With switchMap:

Observable<SearchResult>

The nesting disappears.

Again.

The same abstraction.

Why Monads Exist

Imagine a world without them.

Every operation returning a container would create another layer.

Array<Array<Array<T>>>

Promise<Promise<T>>

Observable<Observable<T>>

Composition would become painful.

Monads solve this.

They allow:

Container Operations
↓
Compose Naturally
↓
Without Nesting

That is their real purpose.

Not mathematics.

Not academic theory.

Composition.

Real World Example: Database Queries

Suppose:

getUser(id)

returns:

Promise<User>

And:

getOrders(userId)

returns:

Promise<Order[]>

Without flattening:

Promise<
  Promise<Order[]>
>

Everywhere.

With Promise.then:

getUser(id)
  .then(user =>
    getOrders(user.id)
  )

One clean chain.

This is why Monads matter.

Real World Example: API Pipelines

authenticate()
  .then(session =>
    fetchProfile(session)
  )
  .then(profile =>
    fetchPermissions(profile)
  )

Every step returns a Promise.

Yet the code remains flat.

Because Promise.then keeps flattening.

Monad Laws (Don't Panic)

Just like Functors have laws.

Monads have laws.

The good news?

They're surprisingly sensible.

Left Identity

Putting a value into a Monad and immediately chaining should behave the same as calling the function directly.

Conceptually:

Wrap
↓
Chain

=

Direct Call

Right Identity

Wrapping and unwrapping should not change behavior.

Associativity

This:

value
  .flatMap(f)
  .flatMap(g)

should behave like:

value.flatMap(
  x => f(x)
    .flatMap(g)
)

This consistency is what makes composition reliable.

Why Most Monad Tutorials Fail

Because they start with:

Monad
↓
Theory
↓
Examples

This article does the opposite.

Arrays
↓
Promises
↓
RxJS
↓
FlatMap
↓
Monad

By the time we reached the word Monad, you already understood the idea.

Pros Of Monads

1. Powerful Composition

Container-producing functions chain naturally.

2. Eliminate Nesting

Avoid:

Promise<Promise<T>>

Array<Array<T>>

Observable<Observable<T>>

3. Common Across Ecosystems

Arrays.

Promises.

RxJS.

Streams.

Functional libraries.

4. Predictable Behavior

The laws provide consistency.

5. Foundation Of Modern Async Programming

Promises rely heavily on Monad-like behavior.

Cons Of Monads

1. Terrible Terminology

The word scares people.

2. Often Explained Poorly

Many tutorials focus on theory before intuition.

3. Easy To Overcomplicate

Simple ideas become academic discussions.

4. Different Libraries Use Different Names

flatMap
then
switchMap
mergeMap
chain
bind

Same family.

Different vocabulary.

5. Can Feel Abstract Initially

Until you connect them to familiar tools.

The Real Lesson

The funny thing about Monads is that they're not particularly complicated.

The terminology is.

The mathematics can be.

The idea itself isn't.

If you've used:

Promise.then(...)

Array.flatMap(...)

switchMap(...)

you've already been using Monads.

You simply learned the practical version before learning the name.

And honestly, that's probably the best way to learn them.

What's Next?

In the next article we'll leave pure FP terminology behind and explore a topic that surprises almost every JavaScript developer:

RxJS Is Just Arrays Over Time

Because once you see that relationship, most RxJS operators become dramatically easier to understand.

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.

FlatMap Is More Important Than You Think

Amrishkhan Sheik Abdullah — Wed, 03 Jun 2026 04:51:00 +0000

Most developers learn map() and think they've figured it out.

You take a value.

Transform it.

Get a new value.

Simple.

const doubled = [1, 2, 3]
  .map(x => x * 2)

console.log(doubled)
// [2, 4, 6]

Life is good.

Until one day your transformation returns another container.

And suddenly everything breaks.

You start seeing:

[
  [1, 10],
  [2, 20],
  [3, 30]
]

instead of:

[1, 10, 2, 20, 3, 30]

Or:

Promise<Promise<User>>

instead of:

Promise<User>

Or nested Observables.

Or nested async workflows.

Or nested arrays.

Or nested state.

At that moment, you discover one of the most important abstractions in programming:

FlatMap.

And once you understand FlatMap, a lot of modern JavaScript suddenly makes sense.

The Problem With map()

Let's start with something innocent.

const numbers = [1, 2, 3]

const result = numbers.map(
  x => [x, x * 10]
)

console.log(result)

Output:

[
  [1, 10],
  [2, 20],
  [3, 30]
]

This is correct.

But what if we actually wanted:

[
  1, 10,
  2, 20,
  3, 30
]

The problem is:

map()
transformed each value

but preserved the container

Remember from the previous article:

Container<Value>
↓
Transform
↓
Container<NewValue>

The issue is that our transformation itself returned a container.

x => [x, x * 10]

Now we have:

Array
↓
map
↓
Array<Array>

Nested containers.

Enter flatMap()

JavaScript gives us:

const result = [1, 2, 3]
  .flatMap(
    x => [x, x * 10]
  )

console.log(result)

Output:

[
  1, 10,
  2, 20,
  3, 30
]

Exactly what we wanted.

Why?

Because FlatMap does two operations.

map
+
flatten

Hence the name:

FlatMap

Visualizing The Difference

Normal map:

[1,2,3]

↓

[
  [1,10],
  [2,20],
  [3,30]
]

FlatMap:

[1,2,3]

↓

[
  1,10,
  2,20,
  3,30
]

Same transformation.

Different result.

Why This Matters More Than Arrays

Most developers stop here.

That is a mistake.

Arrays are only the beginning.

The real importance of FlatMap appears when we look at Promises.

Promise.then() Is Basically FlatMap

Consider:

Promise.resolve(10)
  .then(x => x * 2)

Easy.

Now:

Promise.resolve(10)
  .then(x => {
    return Promise.resolve(
      x * 2
    )
  })

What should happen?

If Promise behaved like Array.map(), we would get:

Promise<Promise<number>>

That would be awful.

Instead we get:

Promise<number>

because Promises automatically flatten.

Which means:

Promise.then()
behaves like FlatMap

Not map.

FlatMap.

This is why async code feels natural.

Promises remove nesting automatically.

The Callback Hell Problem

Before Promises:

getUser(id, user => {
  getOrders(user.id, orders => {
    getPayments(
      orders,
      payments => {
        ...
      }
    )
  })
})

Deep nesting.

Hard to read.

Hard to maintain.

Promises solve this because they flatten.

getUser(id)
  .then(user =>
    getOrders(user.id)
  )
  .then(orders =>
    getPayments(orders)
  )

Flat structure.

Cleaner code.

That flattening behavior is FlatMap.

RxJS Makes This Explicit

RxJS has multiple versions:

mergeMap()
switchMap()
concatMap()
exhaustMap()

Notice something.

They all contain:

Map

Because they transform values.

And they all solve:

Nested Observables

Problem.

Example:

searchText$
  .pipe(
    switchMap(
      text => api.search(text)
    )
  )

Without switchMap:

Observable<
  Observable<SearchResult>
>

With switchMap:

Observable<SearchResult>

Again:

Map
+
Flatten

FlatMap.

Real World Example: User Permissions

Suppose:

const users = [
  {
    name: "John",
    permissions: [
      "read",
      "write"
    ]
  },
  {
    name: "Sarah",
    permissions: [
      "read",
      "delete"
    ]
  }
]

Using map:

const permissions =
  users.map(
    user => user.permissions
  )

Output:

[
  ["read", "write"],
  ["read", "delete"]
]

Using flatMap:

const permissions =
  users.flatMap(
    user => user.permissions
  )

Output:

[
  "read",
  "write",
  "read",
  "delete"
]

Often more useful.

Real World Example: API Aggregation

Suppose each team contains members.

const teams = [
  {
    name: "Frontend",
    members: ["John", "Sarah"]
  },
  {
    name: "Backend",
    members: ["Ahmed"]
  }
]

Map:

teams.map(
  team => team.members
)

Result:

[
  ["John", "Sarah"],
  ["Ahmed"]
]

FlatMap:

teams.flatMap(
  team => team.members
)

Result:

[
  "John",
  "Sarah",
  "Ahmed"
]

This pattern appears constantly in business applications.

FlatMap Is Really About Composition

The deeper idea isn't flattening.

The deeper idea is composition.

Imagine:

User
↓
fetchOrders
↓
Orders

Then:

Orders
↓
fetchPayments
↓
Payments

Without FlatMap:

Nested structures

With FlatMap:

Single pipeline

That is why FlatMap became one of the most important abstractions in software.

It allows computations that return containers to compose naturally.

The Hidden Relationship Between map() and FlatMap

Map:

Value
↓
Transform
↓
Value

FlatMap:

Value
↓
Transform
↓
Container<Value>
↓
Flatten

FlatMap handles the extra layer.

That is its entire purpose.

Performance Considerations

FlatMap is often more efficient than:

array
  .map(...)
  .flat()

because JavaScript can perform both operations together.

Instead of:

Map
↓
Allocate Array
↓
Flatten

it can combine the work.

Always benchmark for critical code paths.

But generally:

flatMap()

is preferable when that is exactly what you intend.

When Not To Use FlatMap

Sometimes nesting is meaningful.

Example:

const teamMembers =
  teams.map(
    team => team.members
  )

Result:

[
  ["John", "Sarah"],
  ["Ahmed"]
]

This preserves team boundaries.

Flattening would destroy that information.

So ask yourself:

Do I want hierarchy?

or

Do I want a single collection?

Choose accordingly.

Pros Of FlatMap

1. Eliminates Nested Structures

Avoids:

Array<Array<T>>
Promise<Promise<T>>
Observable<Observable<T>>

2. Improves Composition

Workflows become linear.

3. Cleaner Async Code

Promises rely heavily on FlatMap behavior.

4. Reduces Boilerplate

Less manual flattening.

5. Common Across Ecosystems

Arrays.

Promises.

RxJS.

Streams.

Functional libraries.

Cons Of FlatMap

1. Can Hide Complexity

Nested structures sometimes carry important meaning.

2. Overuse Can Reduce Clarity

Flattening everything is not always correct.

3. Some Developers Find It Less Intuitive

Especially when learning functional concepts.

4. Different Libraries Flatten Differently

RxJS operators have distinct behaviors.

Understanding them takes time.

5. Easy To Misuse

Flattening data that should remain hierarchical can create bugs.

The Real Lesson

Most developers think FlatMap exists to flatten arrays.

That is technically true.

But it is far too shallow.

The real purpose of FlatMap is:

Allowing computations that return containers to compose naturally.

That is why:

Array.flatMap()

exists.

That is why:

Promise.then()

works the way it does.

That is why:

switchMap()
mergeMap()
concatMap()

exist in RxJS.

The moment you understand FlatMap, you stop seeing it as an array utility.

You start seeing it as a composition tool.

And once you see that, modern JavaScript becomes much easier to understand.

What's Next?

In the next article we'll discuss:

You've Been Using Monads Without Realizing It

Because once you understand:

Functor
↓
Map

FlatMap
↓
Composition

you're already 90% of the way to understanding Monads.

The funny part?

You've probably been using them for years.

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.

You've Been Using Functors For Years

Amrishkhan Sheik Abdullah — Tue, 02 Jun 2026 04:30:00 +0000

The functional programming community has done a terrible job explaining Functors.

The moment the word appears, people start talking about:

Categories
Morphisms
Endofunctors
Higher-Kinded Types
Laws
Haskell

Most developers immediately close the tab.

And honestly, I don't blame them.

Because Functors are often introduced in the most complicated way possible.

Which is unfortunate because Functors are one of the simplest ideas in programming.

In fact, if you've ever written:

[1, 2, 3].map(x => x * 2)

then congratulations.

You've already used a Functor.

You just didn't know it.

The Functional Programming Trap

Most developers learn functional programming backwards.

They start with scary words.

Functor
Monad
Applicative
Category Theory

Then somebody attempts to explain those words using even scarier words.

Which leads to:

Confusion
↓
Frustration
↓
Closing the browser tab

I think the opposite approach works much better.

Instead of starting with the name, let's start with something every JavaScript developer already understands.

map().

Why Does map() Keep Appearing Everywhere?

Let's start with Arrays.

const result = [1, 2, 3]
  .map(x => x * 2)

console.log(result)
// [2, 4, 6]

Nothing surprising.

Now let's look at Promises.

Promise.resolve(10)
  .then(x => x * 2)

Now RxJS.

userStream.pipe(
  map(user => user.name)
)

And Option types.

Option.some(10)
  .map(x => x * 2)

Different libraries.

Different authors.

Different purposes.

Yet they all keep reinventing the same operation.

Why?

The Pattern Hidden Behind map()

Most developers think:

map()
=
Loop through an array

That's not actually what map does.

The deeper idea is:

Take a value
Transform it
Preserve its container

Let's look at Arrays.

Input:

[1, 2, 3]

Transformation:

x => x * 2

Output:

[2, 4, 6]

Notice something important.

The values changed.

The Array did not.

Array<Number>
↓
Transform
↓
Array<Number>

The container stayed intact.

Only the contents changed.

That is the real idea behind map.

Arrays Didn't Invent map()

Now let's revisit Promises.

Promise.resolve(10)
  .then(x => x * 2)

Input:

Promise<Number>

Output:

Promise<Number>

Again:

Container
↓
Transformation
↓
Same Container

The Promise remains a Promise.

Only the value changes.

That should feel familiar.

Because it is exactly the same pattern.

RxJS Is Doing The Same Thing

userStream.pipe(
  map(user => user.name)
)

Input:

Observable<User>

Output:

Observable<String>

Again:

Container
↓
Transformation
↓
Same Container

The Observable stays an Observable.

The values change.

Same idea.

Different implementation.

So What Is A Functor?

Here's the scary definition.

A Functor is:

A structure that can be mapped over.

That's it.

No category theory required.

No PhD required.

No Haskell required.

If a structure supports value transformation while preserving the structure itself, it behaves like a Functor.

Arrays do this.

Promises do this.

Observables do this.

Option types do this.

Result types do this.

You already use them every day.

The Formula

If the previous article taught us:

Reduce
=
State Evolution

Then this article teaches:

Functor
=
Transformation While Preserving Context

Or:

Container<Value>
↓
Transformation
↓
Container<NewValue>

That's the pattern.

A Practical Example

Suppose we receive:

const users = [
  {
    id: 1,
    name: "John"
  },
  {
    id: 2,
    name: "Sarah"
  }
]

We only need names.

const names = users.map(
  user => user.name
)

console.log(names)

Output:

[
  "John",
  "Sarah"
]

The Array remains an Array.

Only the contents changed.

Functor behavior.

Another Example: API Responses

Backend:

const countries = [
  {
    code: "AE",
    name: "United Arab Emirates"
  },
  {
    code: "IN",
    name: "India"
  }
]

Frontend dropdown:

const options = countries.map(
  country => ({
    label: country.name,
    value: country.code
  })
)

Output:

[
  {
    label: "United Arab Emirates",
    value: "AE"
  },
  {
    label: "India",
    value: "IN"
  }
]

Transform values.

Preserve container.

Same pattern.

React Developers Use Functors Daily

Most React developers never think about this.

function UserList({ users }) {
  return (
    <ul>
      {
        users.map(user => (
          <li key={user.id}>
            {user.name}
          </li>
        ))
      }
    </ul>
  )
}

Underneath:

Array<User>
↓
Transform
↓
Array<JSX>

Still the same idea.

The Hidden Relationship Between Functors and Software

Think about what software does all day.

Database rows become API responses.

Rows
↓
Transform
↓
JSON

API responses become UI models.

JSON
↓
Transform
↓
View Model

View models become UI.

Model
↓
Transform
↓
Component

Software is mostly transformation.

Which is why Functors keep appearing everywhere.

Functor Laws (The Only Theory We'll Discuss)

Now that you already understand Functors, we can talk about the famous laws.

Don't panic.

They're surprisingly reasonable.

Law #1: Identity

If you transform nothing:

container.map(x => x)

the result should equal:

container

Example:

[1, 2, 3]
  .map(x => x)

Output:

[1, 2, 3]

Makes sense.

Law #2: Composition

This:

container
  .map(f)
  .map(g)

should be equivalent to:

container.map(
  x => g(f(x))
)

Example:

const double = x => x * 2
const square = x => x * x

Version 1:

[1, 2, 3]
  .map(double)
  .map(square)

Version 2:

[1, 2, 3]
  .map(x =>
    square(double(x))
  )

Same result.

Libraries depend on these guarantees.

Why JavaScript Developers Should Care

Not because you'll suddenly become a functional programming enthusiast.

Not because you'll start writing Haskell.

Because understanding Functors helps explain APIs that you already use.

Once you see:

Array.map()
Promise.then()
Observable.map()

as the same abstraction, many libraries start making more sense.

You stop memorizing APIs.

You start recognizing patterns.

That is where real learning happens.

Performance Considerations

Let's be honest.

This:

array
  .map(...)
  .map(...)
  .map(...)
  .map(...)

creates intermediate arrays.

Each map allocates memory.

For small datasets:

No problem.

For large datasets:

Potential issue.

Example:

const result = users
  .map(...)
  .map(...)
  .map(...)

Internally:

Array
↓
Array
↓
Array
↓
Array

Multiple allocations.

Multiple passes.

Loops Still Matter

A simple loop:

const result = []

for (const user of users) {
  result.push(
    user.name.toUpperCase()
  )
}

is often:

Faster
Easier to debug
Easier to profile

That does not make map bad.

It simply means tradeoffs exist.

map()
↓
Clarity
Composability

versus

for...of
↓
Control
Performance

Choose appropriately.

Pros Of Functors

1. Predictable

The container stays the same.

Only the value changes.

2. Composable

Transformations chain naturally.

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

3. Reusable

Transformations become portable.

4. Common Across Ecosystems

Arrays.

Promises.

RxJS.

Streams.

Options.

Results.

Same idea.

5. Easier To Reason About

Transform value.

Preserve context.

Simple mental model.

Cons Of Functors

1. Terrible Naming

The word "Functor" scares people unnecessarily.

2. Easy To Over-Academize

Many explanations make a simple idea look difficult.

3. Not Always Optimal

Repeated mapping can create allocations.

4. Can Encourage Over-Chaining

Huge transformation pipelines become difficult to follow.

5. Sometimes A Loop Is Better

Not every transformation needs a functional abstraction.

The Real Lesson

The funny thing about Functors is that they're not difficult.

The word is difficult.

The idea is simple.

If you've ever used:

array.map(...)

promise.then(...)

observable.pipe(map(...))

you've already been using Functors.

The only thing this article changed was giving a name to a pattern you already understood.

And once you start recognizing patterns instead of memorizing APIs, software suddenly becomes much easier to learn.

What's Next?

In the next article, we'll discuss something even more important:

FlatMap Is More Important Than You Think

Because once developers understand map(), the next natural question becomes:

What happens when my transformation
returns another container?

And that question leads us directly to:

flatMap()
Monads
Composition

without the usual confusion.

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 `map()` Exists Everywhere

Amrishkhan Sheik Abdullah — Mon, 01 Jun 2026 04:30:00 +0000

Most developers think map() is an array method.

It isn't.

Just like most developers think reduce() is an array method.

It isn't either.

In a previous article, I argued that reduce() has almost nothing to do with arrays.

Arrays are simply where most developers first encounter the idea.

The same thing is true for map().

Most developers learn it here:

const doubled = [1, 2, 3]
  .map(x => x * 2)

console.log(doubled)
// [2, 4, 6]

Then they move on.

But something strange starts happening as your career progresses.

You begin seeing map() everywhere.

Not just in arrays.

In:

Promises
RxJS
React
Functional libraries
Streams
Option types
Result types
Immutable data structures

Different APIs.

Different libraries.

Different ecosystems.

Yet they all keep reinventing map().

Why?

Surely that can't be a coincidence.

The answer is that map() is not really an array operation.

It is a transformation pattern.

And once you understand that pattern, you start seeing it throughout software engineering.

The Weird Question Nobody Asks

Consider these examples.

Array:

const result = [1, 2, 3]
  .map(x => x * 2)

Promise:

Promise.resolve(10)
  .then(x => x * 2)

RxJS:

userStream.pipe(
  map(user => user.name)
)

Option:

Option.some(10)
  .map(x => x * 2)

These APIs were created by different people.

For different purposes.

At different times.

Yet they all contain the same operation.

Why?

What map() Actually Does

Most developers think:

map()
=
Loop over array

That is not what map does.

The deeper idea is:

Take a value
Apply a transformation
Preserve the container

Let's look at an array.

Input:

[1, 2, 3]

Transformation:

x => x * 2

Output:

[2, 4, 6]

Notice something important.

The container stayed the same.

Array
↓
Transformation
↓
Array

The values changed.

The structure did not.

That is the real abstraction.

map() Preserves Context

This is the part most tutorials never explain.

When you use:

array.map(...)

the array remains an array.

const users = [
  { name: "John" },
  { name: "Sarah" }
]

const names = users.map(
  user => user.name
)

Input:

Array<User>

Output:

Array<String>

The values changed.

The container remained.

That is what makes map() special.

Arrays Didn't Invent map()

Let's look at Promises.

Promise.resolve(10)
  .then(x => x * 2)

Input:

Promise<Number>

Output:

Promise<Number>

Again:

Container
↓
Transformation
↓
Same Container

The Promise remains a Promise.

Only the value inside changes.

This should feel familiar.

Because it is exactly what map() does.

In fact, many functional programming libraries literally implement Promise transformations as map().

RxJS Does The Same Thing

Let's look at Observables.

userStream.pipe(
  map(user => user.name)
)

Input:

Observable<User>

Output:

Observable<String>

Again:

Container
↓
Transformation
↓
Same Container

The Observable remains an Observable.

Only the data changes.

Same pattern.

Different environment.

The Pattern Behind Everything

At this point we have seen:

Array:

Array<A>
↓
map
↓
Array<B>

Promise:

Promise<A>
↓
map
↓
Promise<B>

Observable:

Observable<A>
↓
map
↓
Observable<B>

Same shape.

Different container.

This is why map keeps appearing everywhere.

Because software is full of containers.

And containers frequently need transformations.

Real World Example: API Responses

Suppose an API returns:

const users = [
  {
    id: 1,
    name: "John"
  },
  {
    id: 2,
    name: "Sarah"
  }
]

Most UIs only need:

const names = users.map(
  user => user.name
)

console.log(names)

Output:

[
  "John",
  "Sarah"
]

This is one of the most common uses of map().

Transform data.

Preserve structure.

Real World Example: UI Dropdowns

Backend response:

const countries = [
  {
    code: "AE",
    name: "UAE"
  },
  {
    code: "IN",
    name: "India"
  }
]

UI needs:

const options = countries.map(
  country => ({
    label: country.name,
    value: country.code
  })
)

Output:

[
  {
    label: "UAE",
    value: "AE"
  },
  {
    label: "India",
    value: "IN"
  }
]

This is map at its best.

Real World Example: React Components

function UserList({ users }) {
  return (
    <ul>
      {
        users.map(user => (
          <li key={user.id}>
            {user.name}
          </li>
        ))
      }
    </ul>
  )
}

React developers use map() every day.

But the underlying idea is still:

Data
↓
Transformation
↓
UI Representation

Why map() Feels So Natural

Because most business applications are transformation engines.

Think about what software does.

Input:

Database Records

Transform.

Output:

API Response

Input:

API Response

Transform.

Output:

UI State

Input:

UI State

Transform.

Output:

Rendered Components

Most software is simply:

State
↓
Transformation
↓
State

And map() embodies that idea.

The Hidden Relationship Between map() and reduce()

In the previous article, we discussed how reduce represents:

Current State
+
Input
=
Next State

Map is different.

Map represents:

Value
↓
Transformation
↓
Value

Reduce evolves state.

Map transforms values.

Together they describe a huge percentage of software.

Performance Considerations

Let's talk about the elephant in the room.

Many developers write:

array
  .map(...)
  .map(...)
  .map(...)
  .map(...)

This is readable.

But it creates intermediate arrays.

Example:

const result = users
  .map(...)
  .map(...)
  .map(...)

Internally:

Array
↓
Array
↓
Array
↓
Array

Each step creates a new collection.

For small datasets:

No problem.

For large datasets:

Potential issue.

The Loop Comparison

This:

const result = []

for (const user of users) {
  result.push(
    user.name.toUpperCase()
  )
}

is often:

Faster
Simpler
Easier to debug

So why not always use loops?

Because loops are usually less composable.

This is the tradeoff.

Loop
↓
Performance

versus

Map
↓
Composability

Neither is universally correct.

Context matters.

The Problem With Over-Chaining

This:

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

can become difficult to reason about.

Especially when transformations are complex.

At that point:

for...of

might actually be clearer.

Senior engineering is not about choosing one pattern.

It is about choosing the right pattern.

Why Functional Developers Love map()

Because it is predictable.

Input:

Array<User>

Output:

Array<UserDto>

Input:

Promise<User>

Output:

Promise<UserDto>

Input:

Observable<User>

Output:

Observable<UserDto>

The container never changes.

Only the value changes.

That predictability makes software easier to compose.

The Scary Word: Functor

At this point, some FP developers will say:

Congratulations.

You just described a Functor.

And they're right.

A Functor is simply:

Something that can be mapped over.

That sounds intimidating.

But you've already been using Functors for years.

Arrays are Functors.

Promises are Functors.

Observables are Functors.

You already understand the concept.

You just didn't know the name.

Pros Of map()

1. Easy To Read

users.map(
  user => user.name
)

Extremely clear.

2. Composable

Transformations can be chained.

3. Predictable

Container remains unchanged.

4. Encourages Declarative Code

You describe the transformation.

Not the mechanics.

5. Works Across Many Abstractions

Arrays.

Promises.

Observables.

Streams.

And many more.

Cons Of map()

1. Intermediate Allocations

Every map creates a new collection.

2. Can Become Over-Chained

Long pipelines become difficult to follow.

3. Not Always Fastest

Loops often outperform chained maps.

4. Can Hide Complexity

A small callback is great.

A 50-line callback is not.

5. Not Every Transformation Is A map()

Sometimes:

reduce()

for...of

is the better tool.

The Real Lesson

The biggest lesson I learned about map() was that it had very little to do with arrays.

Arrays merely introduced me to the idea.

The real idea was:

Container<Value>
↓
Transformation
↓
Container<NewValue>

Once you understand that pattern, you start seeing map() everywhere.

In Promises.

In RxJS.

In React.

In functional programming.

In software architecture.

And suddenly the question changes.

Instead of asking:

How do I loop over this?

you start asking:

How do I transform this value
while preserving its context?

That shift in thinking is far more valuable than the map() function 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.

The Myth Of Stateless Systems

Amrishkhan Sheik Abdullah — Sat, 30 May 2026 18:47:23 +0000

One of the most common phrases in modern software architecture is:

Our service is stateless.

You'll hear it everywhere.

Cloud architecture discussions.

Microservices presentations.

System design interviews.

Kubernetes deployments.

Backend engineering meetings.

Somewhere along the way, "stateless" became synonymous with:

Scalable

Modern

Cloud Native

Good Architecture

The problem is:

Most stateless systems aren't actually stateless.

They simply moved the state somewhere else.

And understanding that distinction can completely change how you design software.

What Does Stateless Actually Mean?

A truly stateless system does not retain information between requests.

Consider:

GET /health

Request arrives.

Response is generated.

Request disappears.

No memory.

No history.

No persistence.

The system doesn't care whether you've called it:

1 Time

10 Times

1 Million Times

Every request is independent.

This is the purest form of statelessness.

Why Developers Love Stateless Systems

Stateless systems are attractive because they're easy to scale.

Imagine:

Server A

handling a request.

The next request can go to:

Server B

or:

Server C

because none of them need historical context.

Load balancing becomes simple.

Auto-scaling becomes simple.

Infrastructure becomes simpler.

At least on paper.

The Authentication Example

Let's examine one of the most common claims.

Suppose someone says:

We Use JWTs

Our API Is Stateless

At first glance:

They're right.

The server doesn't store a session.

Everything needed is inside:

JWT Token

Problem solved?

Not quite.

Consider:

User Gets Banned

How do you invalidate the token?

Now suddenly:

Revocation Lists

Token Blacklists

User State

Permissions

appear.

The state didn't disappear.

It moved.

Stateless Usually Means "State Elsewhere"

This is one of the most important observations in distributed systems.

When engineers say:

Stateless Service

they often mean:

State Exists

But Not Inside This Service

The state might live in:

PostgreSQL
Redis
Kafka
Browser Storage
JWT Tokens
External APIs

But it still exists.

And someone still has to manage it.

Databases Are State

This sounds obvious.

Yet it's easy to forget.

Imagine:

GET /users/123

returns:

{
  "id": 123,
  "name": "John"
}

Where did that information come from?

State.

Specifically:

Database State

Your application may be stateless.

Your system is not.

Redis Is State

A common pattern:

API
↓
Redis Cache
↓
Database

The API appears stateless.

Redis now contains:

Sessions

Locks

Rate Limits

Cached Data

The state moved.

Nothing disappeared.

The Browser Is State

Frontend developers often hear:

Single Page Applications

described as stateless clients.

Then we discover:

localStorage

sessionStorage

IndexedDB

Cookies

Memory

The browser is carrying enormous amounts of state.

The application simply delegated responsibility.

Kubernetes Doesn't Remove State

Many developers associate containers with statelessness.

Container:

Stateless

Database:

Stateful

Seems straightforward.

Until:

Configuration

Secrets

Volumes

Persistent Storage

Service Discovery

enter the picture.

Even containerized systems are surrounded by state.

The Shopping Cart Problem

Imagine an e-commerce platform.

Customer:

Adds Product To Cart

Where is that cart?

Options:

Database

Redis

Browser

Session

Cookie

Pick any location.

The moment a cart exists:

State Exists

The question isn't whether the system has state.

The question is:

Where Does It Live?

The Retry Connection

In the previous article we discussed retries.

Suppose:

Create Order

times out.

Client retries.

How does the system know:

This Request Already Happened

Because somewhere:

State Exists

Without state:

Idempotency becomes impossible.

The Event Sourcing Perspective

Event Sourcing makes this explicit.

Instead of storing:

Current State

it stores:

Events

Example:

AccountCreated

MoneyDeposited

MoneyWithdrawn

Current state is reconstructed from history.

The state still exists.

It's simply represented differently.

Stateless APIs Still Depend On State

A common architecture:

Load Balancer
↓
Stateless APIs
↓
Database

People often focus on:

Stateless APIs

The real challenge usually lives in:

Database Consistency

because that's where the state actually resides.

Why State Is Hard

State creates:

Synchronization Problems

Caching Problems

Concurrency Problems

Consistency Problems

Time Problems

Notice something.

Most articles in this series eventually return to state.

That's not an accident.

State is where complexity lives.

Real World Example: Flight Booking

Imagine:

Seat Available

Customer begins booking.

Before payment completes:

Another Customer Reserves Same Seat

Now the system must answer:

Who Owns The Seat?

That's a state problem.

Not a networking problem.

Not a framework problem.

A state problem.

Real World Example: API Studio

Suppose we're building an API Studio.

Questions appear:

Which Workspace Is Active?

Which Environment Is Selected?

Which Git Branch Is Checked Out?

Which Request Was Last Opened?

Which Collection Is Cached?

These are all forms of state.

The software's complexity comes from managing them correctly.

The Hidden Truth

Most architecture discussions focus on:

Frameworks

Containers

Cloud Platforms

Languages

The real challenge is often:

State Management

Because every system ultimately needs to answer:

What Is True Right Now?

And that is fundamentally a state question.

Pros Of Stateless Services

1. Easier Horizontal Scaling

Requests can be distributed freely.

2. Simpler Deployments

No local state migration.

3. Better Fault Tolerance

Instances can be replaced easily.

4. Simpler Load Balancing

Any server can handle any request.

5. Better Cloud Compatibility

Works well with modern infrastructure.

Cons Of Chasing Statelessness

1. State Doesn't Disappear

It moves.

2. Complexity Moves Elsewhere

Usually databases or caches.

3. Debugging Becomes Harder

State is distributed.

4. Consistency Challenges Increase

Multiple systems now share responsibility.

5. Architecture Can Become Misleading

Teams may underestimate where complexity truly lives.

The Real Lesson

One of the most valuable questions in software engineering is:

Where Is The State?

Whenever you encounter:

Retries
Authentication
Caching
Event Sourcing
Distributed Systems
Concurrency

ask that question.

Because state rarely disappears.

It simply changes location.

And many architectural mistakes happen when teams assume:

State Eliminated

when reality is:

State Relocated

The most successful engineers understand this difference.

Because there are very few stateless systems.

There are only systems that are honest about where the state lives.

What's Next?

In the next article we'll discuss:

Everything Is A Queue Eventually

Because after enough scale, enough traffic, and enough complexity, you'll discover a surprising truth:

Everything
Eventually
Waits In Line

And software is no exception.

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.

Reduce Has Nothing To Do With Arrays

Amrishkhan Sheik Abdullah — Sat, 30 May 2026 11:22:59 +0000

Most developers think they understand reduce().

They don't.

And to be fair, I didn't either for a long time.

Like many JavaScript developers, I learned reduce() through examples like this:

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

console.log(total)
// 10

Then I saw examples for:

grouping arrays
transforming arrays
creating lookup tables
counting occurrences

Eventually I came to the conclusion that:

Reduce is the Swiss Army Knife of array operations.

And while that statement is technically true, it completely misses the point.

Because the biggest misunderstanding about reduce() is this:

reduce() has almost nothing to do with arrays.

Arrays are merely where most developers first encounter the idea.

The real idea behind reduce() is much deeper.

Once you understand it, you start seeing the exact same pattern everywhere:

Redux
React's useReducer
RxJS scan
Event Sourcing
CQRS
State Machines
Financial Ledgers
Audit Logs
Domain Events

The same abstraction keeps appearing.

And it appears because reduce() is not fundamentally about arrays.

It is about state transformation.

The Misleading Name

The name itself causes confusion.

When developers hear "reduce", they naturally think:

Many things
↓
Reduced into one thing

For example:

const total = [10, 20, 30]
  .reduce((sum, n) => sum + n, 0)

const longestWord = words.reduce(...)

const max = numbers.reduce(...)

All of these examples reinforce the idea that reduce is about collapsing a collection into a single value.

That is not wrong.

But it is incomplete.

Let's look at a different example.

This Doesn't Look Like Reduction

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

What exactly is being reduced here?

Nothing is being summed.

Nothing is being minimized.

Nothing is being collapsed.

Instead, something else is happening.

We are evolving state.

Each user changes the current state.

Current State
+
User
=
Next State

That formula is the real abstraction.

And once you see it, everything changes.

Reduce Is A State Evolution Function

Forget arrays for a moment.

Let's define a reducer.

A reducer takes:

Current State
+
Input
=
Next State

In code:

(state, input) => nextState

That's it.

That is the entire idea.

The reducer itself does not care whether:

input came from an array
input came from a stream
input came from a websocket
input came from a user action
input came from a database event

The reducer only knows:

State + Input = New State

Everything else is implementation detail.

Redux Was Telling Us This All Along

Redux literally puts the word reducer in its API.

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

    case "DECREMENT":
      return state - 1

    default:
      return state
  }
}

Now let's process some actions.

const actions = [
  { type: "INCREMENT" },
  { type: "INCREMENT" },
  { type: "DECREMENT" }
]

const result = actions.reduce(
  reducer,
  0
)

console.log(result)
// 1

Look closely.

Redux's core architecture is simply:

Current State
+
Action
=
Next State

Which is exactly:

(state, action) => nextState

Which is exactly a reducer.

Redux isn't inspired by reduce.

Redux is reduce.

React's useReducer Doesn't Even Hide It

React developers use this every day.

const [state, dispatch] =
  useReducer(reducer, initialState)

The React team could have named it anything.

They could have called it:

useStateMachine
useStore
useTransition
useActionState

But they didn't.

They called it:

useReducer

Because that's exactly what it is.

React isn't introducing a new idea.

It is exposing the same abstraction.

Current State
+
Action
=
Next State

Again.

State Machines Are Just Reducers

Let's build a traffic light.

States:

RED
GREEN
YELLOW

Events:

NEXT

Reducer:

function reducer(state, event) {
  switch (state) {
    case "RED":
      return "GREEN"

    case "GREEN":
      return "YELLOW"

    case "YELLOW":
      return "RED"
  }
}

Process events:

const events = [
  "NEXT",
  "NEXT",
  "NEXT"
]

const finalState =
  events.reduce(
    reducer,
    "RED"
  )

console.log(finalState)
// RED

Congratulations.

You just built a state machine using reduce.

Event Sourcing Is Just Reduce Over Time

This is where things get interesting.

Suppose we have a bank account.

Events:

const events = [
  {
    type: "DEPOSIT",
    amount: 100
  },
  {
    type: "DEPOSIT",
    amount: 50
  },
  {
    type: "WITHDRAW",
    amount: 25
  }
]

Reducer:

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

    case "WITHDRAW":
      return balance - event.amount

    default:
      return balance
  }
}

Current balance:

const balance =
  events.reduce(
    accountReducer,
    0
  )

console.log(balance)
// 125

Most developers would call this:

A reduce operation

An Event Sourcing architect would call this:

State reconstruction

They are the same thing.

Event Sourcing is simply:

Replay events
through a reducer
to reconstruct state.

That's it.

The entire architecture is built on the same abstraction.

CQRS Is The Same Story

CQRS often sounds intimidating.

Commands.
Events.
Projections.

But underneath:

Command
↓
Event
↓
Reducer
↓
State

A projection is simply another reducer.

For example:

function ordersByCustomer(
  state,
  orderCreated
) {
  const {
    customerId
  } = orderCreated

  state[customerId] ??= []

  state[customerId].push(
    orderCreated
  )

  return state
}

Process events.

Build state.

Same pattern.

Again.

RxJS scan() Is Reduce For Infinite Data

This realization blew my mind the first time I encountered it.

Normal reduce:

[1, 2, 3, 4]
  .reduce(...)

requires all data to exist upfront.

But streams never end.

So RxJS introduced:

scan()

Example:

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

Output:

What happened?

The stream is reducing continuously.

The state evolves forever.

A better description is:

scan() is reduce for infinite sequences.

Which means:

Reduce
↓
State Evolution
↓
scan()

Same idea.

Different environment.

The Formula That Keeps Reappearing

At this point we have seen:

Arrays
Redux
React
Event Sourcing
CQRS
State Machines
RxJS

All using the same abstraction.

Because underneath everything sits one formula:

Current State
+
Input
=
Next State

Or:

(state, input) => nextState

That is the reducer pattern.

Everything else is implementation detail.

Why I Actually Use Reduce Less Nowadays

This might sound strange after everything I've written.

But understanding reduce deeply made me use it less.

Not more.

Because I now understand what it is for.

Many developers discover reduce and start replacing everything with it.

array.reduce(...)

for every transformation.

I did that too.

Then I stopped.

Because for most day-to-day code:

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

is clearer.

Often faster.

Usually easier to debug.

Example:

const usersById = {}

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

versus:

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

Both work.

The loop is arguably easier to read.

And that is okay.

The goal is not to use reduce everywhere.

The goal is to understand the abstraction behind it.

Performance Considerations

Let's address a common argument.

Many developers claim:

Reduce is slower than loops.

In many cases, they are correct.

A simple loop often wins.

Why?

Because:

Loop
↓
Less callback overhead
↓
Less abstraction
↓
Less work

There is also another common mistake.

This:

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

creates a new object every iteration.

That can become extremely expensive.

Compare that to:

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

The second version mutates a local accumulator and is usually much more efficient.

Functional-looking code is not automatically performant code.

Always measure.

Pros Of Thinking In Reducers

1. Predictable State Changes

Every state transition is explicit.

2. Easy To Test

state + action = nextState

Pure functions are simple to verify.

3. Event Replay

You can reconstruct state from history.

4. Time Travel Debugging

Redux DevTools exists because reducers are deterministic.

5. Scales To Complex Systems

Works for:

Redux
CQRS
Event Sourcing
Streams
State Machines

Cons Of Overusing Reducers

1. Cognitive Overhead

Not every transformation needs a reducer.

2. Can Become Unreadable

Huge reducers quickly become difficult to maintain.

3. Loops Are Often Simpler

Sometimes the simplest solution is the best one.

4. Functional Purity Can Hurt Performance

Excessive copying can become expensive.

5. Teams Must Understand The Pattern

Otherwise reducers become magic instead of architecture.

The Real Lesson

The biggest lesson I learned about reduce was that it had very little to do with arrays.

Arrays merely introduced me to the idea.

The real idea was this:

Current State
+
Input
=
Next State

Once you understand that formula, you start seeing reduce everywhere.

In Redux.

In React.

In RxJS.

In Event Sourcing.

In CQRS.

In State Machines.

In distributed systems.

In financial ledgers.

In software architecture itself.

And ironically, once you truly understand reduce, you stop asking:

How do I update this object?

and start asking:

What transformed this state?

That shift in thinking is far more valuable than the reduce() function 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.

Transducers in JavaScript: When `reduce()` Is Not the End of the Story

Amrishkhan Sheik Abdullah — Sat, 30 May 2026 10:35:42 +0000

In my previous article, I wrote about one of the most underestimated functions in JavaScript: reduce().

That article triggered a very fair discussion. Some developers agreed that reduce() is powerful. Some pushed back. And honestly, the pushback was valid.

Because reduce() is one of those functions that can be either beautiful or terrible depending on how it is used. A simple reduce() can express a clean state transformation. A bad reduce() can become unreadable very quickly.

So before talking about transducers, let me say this clearly:

I do not think reduce() should replace simple loops everywhere.

In many cases, a plain for...of loop is more readable, more debuggable, and often faster.

const result = []

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

This is not "less functional". This is just clear code. And clarity matters.

But there is another interesting idea hiding behind reduce().

That idea is not just:

Use reduce() more.

The deeper idea is:

What if reducers themselves could be composed?

That is where transducers come in.

The Problem With `map().filter().reduce()`

Let's start with a normal JavaScript pipeline.

const result = users
  .filter(user => user.active)
  .map(user => user.name)
  .filter(name => name.length > 3)

This is readable. But internally, JavaScript creates intermediate arrays.

users
  → filtered users array
  → mapped names array
  → filtered names array

For small arrays, this is perfectly fine. For UI code, this is usually fine. But for large data pipelines, logs, analytics, imports, file processing, or repeated transformations, this can create unnecessary work.

You could rewrite it using reduce():

const result = users.reduce((acc, user) => {
  if (!user.active) return acc

  const name = user.name

  if (name.length <= 3) return acc

  acc.push(name)
  return acc
}, [])

Now we have one pass. No intermediate arrays. But we lost pipeline readability. The logic is now packed into one reducer. That is the tradeoff.

The Real Question

The question is not:

Should we use reduce() instead of map() and filter()?

The better question is:

Can we get the composability of map() and filter() with the single-pass behavior of reduce()?

That is exactly what transducers try to solve.

What Is a Transducer?

A reducer has this shape:

(acc, value) => acc

A transducer has this shape:

reducer => reducer

That is the key. A transducer is a function that takes a reducer and returns a new reducer.

In simple terms:

A transducer is a composable transformation for reducers.

Or even simpler:

Transducers let us compose map, filter, take, and other transformations without creating intermediate arrays.

Normal Reducer

const append = (acc, value) => {
  acc.push(value)
  return acc
}

This reducer knows how to add a value into an array. Now let's build a transducer.

`map` as a Transducer

const mapping = transform => reducer => {
  return (acc, value) => {
    return reducer(acc, transform(value))
  }
}

Usage:

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

const result = [1, 2, 3].reduce(
  double(append),
  []
)

console.log(result)
// [2, 4, 6]

The mapping function does not know anything about arrays. It only says:

Before passing the value to the reducer, transform it.

`filter` as a Transducer

const filtering = predicate => reducer => {
  return (acc, value) => {
    if (predicate(value)) {
      return reducer(acc, value)
    }

    return acc
  }
}

Usage:

const onlyEven = filtering(x => x % 2 === 0)

const result = [1, 2, 3, 4].reduce(
  onlyEven(append),
  []
)

console.log(result)
// [2, 4]

The filtering transducer says:

Only call the reducer if the value passes the condition.

Composing Transducers

Now we can compose transformations.

const compose = (...fns) => input => {
  return fns.reduceRight((value, fn) => fn(value), input)
}

Now:

const pipeline = compose(
  filtering(user => user.active),
  mapping(user => user.name),
  filtering(name => name.length > 3)
)

const result = users.reduce(
  pipeline(append),
  []
)

This gives us:

filter active users
→ map user to name
→ filter name length
→ append result

But it runs as one reduction pipeline. No intermediate arrays.

Creating a `transduce()` Helper

To make this cleaner:

const transduce = (transducer, reducer, initialValue, collection) => {
  return collection.reduce(
    transducer(reducer),
    initialValue
  )
}

Usage:

const result = transduce(
  compose(
    filtering(user => user.active),
    mapping(user => user.name),
    filtering(name => name.length > 3)
  ),
  append,
  [],
  users
)

This reads as:

Apply this transformation pipeline,
using this reducer,
starting with this initial value,
over this collection.

Why This Is More Than `reduce()`

A normal reducer usually mixes three things:

Filtering logic
Mapping logic
Accumulation logic

Example:

const result = users.reduce((acc, user) => {
  if (!user.active) return acc

  acc.push(user.name)

  return acc
}, [])

A transducer separates them.

const activeUserNames = compose(
  filtering(user => user.active),
  mapping(user => user.name)
)

Then the final reducer decides the output.

Array output:

const names = transduce(
  activeUserNames,
  append,
  [],
  users
)

String output:

const joinNames = (text, name) => {
  return text === "" ? name : `${text}, ${name}`
}

const namesText = transduce(
  activeUserNames,
  joinNames,
  "",
  users
)

Same transformation. Different output. That is the real unlock.

Transducers Are Input-Independent

Normal map() and filter() are array methods. Transducers are not tied to arrays. They can work with anything that can be reduced or iterated.

Let's make transduce() work with any iterable.

const transduce = (transducer, reducer, initialValue, iterable) => {
  const transformedReducer = transducer(reducer)

  let acc = initialValue

  for (const value of iterable) {
    acc = transformedReducer(acc, value)
  }

  return acc
}

Now this works with an array:

transduce(pipeline, append, [], [1, 2, 3, 4])

And with a Set:

transduce(pipeline, append, [], new Set([1, 2, 3, 4]))

And with a generator:

function* numbers() {
  yield 1
  yield 2
  yield 3
  yield 4
}

const result = transduce(
  compose(
    filtering(x => x % 2 === 0),
    mapping(x => x * 10)
  ),
  append,
  [],
  numbers()
)

console.log(result)
// [20, 40]

That is why transducers are powerful. They separate:

where data comes from
how data is transformed
where data goes

A Practical Example: API Data Normalization

const products = [
  { id: "p1", name: "Keyboard", price: 120, inStock: true },
  { id: "p2", name: "Mouse", price: 50, inStock: false },
  { id: "p3", name: "Monitor", price: 300, inStock: true }
]

We want:

only in-stock products
add discounted price
index by product id

const productPipeline = compose(
  filtering(product => product.inStock),
  mapping(product => ({
    ...product,
    discountedPrice: product.price * 0.9
  }))
)

const indexById = (acc, product) => {
  acc[product.id] = product
  return acc
}

const productsById = transduce(
  productPipeline,
  indexById,
  {},
  products
)

console.log(productsById)

Output:

{
  p1: {
    id: "p1",
    name: "Keyboard",
    price: 120,
    inStock: true,
    discountedPrice: 108
  },
  p3: {
    id: "p3",
    name: "Monitor",
    price: 300,
    inStock: true,
    discountedPrice: 270
  }
}

No intermediate arrays. One pass. Composable transformation.

A Practical Example: Permission Mapping

const permissions = [
  { screen: "sales", action: "view", allowed: true },
  { screen: "sales", action: "edit", allowed: true },
  { screen: "inventory", action: "delete", allowed: false },
  { screen: "inventory", action: "view", allowed: true }
]

We want only allowed permissions, grouped by screen.

const allowedOnly = filtering(permission => permission.allowed)

const buildPermissionMap = (acc, permission) => {
  if (!acc[permission.screen]) {
    acc[permission.screen] = {}
  }

  acc[permission.screen][permission.action] = true

  return acc
}

const permissionMap = transduce(
  allowedOnly,
  buildPermissionMap,
  {},
  permissions
)

console.log(permissionMap)

Output:

{
  sales: {
    view: true,
    edit: true
  },
  inventory: {
    view: true
  }
}

This is a good use case because the final output is not an array. We are transforming a list into a lookup structure.

A Practical Example: Log Processing

const logs = [
  { level: "info", message: "Server started" },
  { level: "error", message: "Database failed" },
  { level: "warn", message: "High memory usage" },
  { level: "error", message: "Payment failed" }
]

Pipeline:

const errorPipeline = compose(
  filtering(log => log.level === "error"),
  mapping(log => ({
    ...log,
    message: log.message.toUpperCase()
  }))
)

const errors = transduce(
  errorPipeline,
  append,
  [],
  logs
)

console.log(errors)

Output:

[
  { level: "error", message: "DATABASE FAILED" },
  { level: "error", message: "PAYMENT FAILED" }
]

Useful for:

logs
analytics
monitoring
event pipelines
imports
large JSON processing

Early Termination With `take`

One powerful use case is stopping early.

Let's implement reduced.

const reduced = value => ({
  __reduced: true,
  value
})

const isReduced = value => {
  return value && value.__reduced === true
}

Update transduce():

const transduce = (transducer, reducer, initialValue, iterable) => {
  const transformedReducer = transducer(reducer)

  let acc = initialValue

  for (const value of iterable) {
    acc = transformedReducer(acc, value)

    if (isReduced(acc)) {
      return acc.value
    }
  }

  return acc
}

Now implement take.

const taking = limit => reducer => {
  let count = 0

  return (acc, value) => {
    if (count >= limit) {
      return reduced(acc)
    }

    count++

    const nextAcc = reducer(acc, value)

    if (count >= limit) {
      return reduced(nextAcc)
    }

    return nextAcc
  }
}

Usage:

const result = transduce(
  compose(
    filtering(x => x % 2 === 0),
    mapping(x => x * 10),
    taking(2)
  ),
  append,
  [],
  [1, 2, 3, 4, 5, 6, 8]
)

console.log(result)
// [20, 40]

This matters when working with:

huge arrays
generators
streams
expensive transformations
search results
file parsing

But What About `for...of`?

This is important. A well-written for...of loop is often the clearest and fastest solution.

const result = []

for (const user of users) {
  if (!user.active) continue

  const name = user.name

  if (name.length <= 3) continue

  result.push(name)
}

This has:

no intermediate arrays
no reducer callback overhead
no abstraction cost
very clear control flow

So why not always use this? Because sometimes you want reusable transformation logic. With a loop, the transformation is usually locked inside that specific block. With transducers, the transformation can be named, composed, reused, and applied to different outputs.

So the real comparison is not:

transducer vs for loop

It is:

one-off transformation → use for...of
reusable transformation pipeline → consider transducers

Performance: Be Honest

Transducers can avoid intermediate arrays. That can be a serious performance win for large pipelines. But they are not magic.

A plain for loop or for...of loop will often beat both reduce() and transducers in raw speed because there is less function-call overhead.

Also, bad reducer implementations can be very slow.

This is especially problematic:

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

This recreates the object on every iteration. For large arrays, this can become extremely expensive.

A mutation-based accumulator is usually much better:

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

Some people dislike mutation in reducers. That is understandable. But in many practical JavaScript scenarios, mutating a local accumulator is a reasonable optimization.

The important thing is this:

Do not confuse functional-looking code with efficient code.

This:

return { ...acc, [key]: value }

may look elegant. But for large collections, it can be much worse than a controlled local mutation.

Naming Matters

Another fair criticism of many reduce() examples is bad parameter naming.

This is poor:

items.reduce((a, c) => {
  a[c.id] = c
  return a
}, {})

This is better:

items.reduce((itemsById, item) => {
  itemsById[item.id] = item
  return itemsById
}, {})

If we use reducers or transducers, names matter even more. Bad names increase cognitive overhead. Good names reduce it.

const buildUsersById = (usersById, user) => {
  usersById[user.id] = user
  return usersById
}

This is much clearer.

Transducers With Async Data

JavaScript applications often deal with data that does not arrive all at once.

Examples:

paginated API results
file streams
database cursors
event queues
async generators

We can create an async version.

const asyncTransduce = async (
  transducer,
  reducer,
  initialValue,
  asyncIterable
) => {
  const transformedReducer = transducer(reducer)

  let acc = initialValue

  for await (const value of asyncIterable) {
    acc = await transformedReducer(acc, value)

    if (isReduced(acc)) {
      return acc.value
    }
  }

  return acc
}

Example:

async function* fetchUsers() {
  yield { id: 1, name: "Aisha", active: true }
  yield { id: 2, name: "Rahul", active: false }
  yield { id: 3, name: "Meera", active: true }
}

Async reducer:

const asyncAppend = async (acc, value) => {
  acc.push(value)
  return acc
}

Usage:

const activeUsers = await asyncTransduce(
  filtering(user => user.active),
  asyncAppend,
  [],
  fetchUsers()
)

console.log(activeUsers)

Output:

[
  { id: 1, name: "Aisha", active: true },
  { id: 3, name: "Meera", active: true }
]

This is useful when you want sequential async processing.

But remember:

This does not automatically create parallelism.

If you need concurrency, batching, throttling, or parallel API calls, you need a different design.

Full Mini Transducer Toolkit

Here is a small working implementation.

const compose = (...fns) => input => {
  return fns.reduceRight((value, fn) => fn(value), input)
}

const reduced = value => ({
  __reduced: true,
  value
})

const isReduced = value => {
  return value && value.__reduced === true
}

const transduce = (transducer, reducer, initialValue, iterable) => {
  const transformedReducer = transducer(reducer)

  let acc = initialValue

  for (const value of iterable) {
    acc = transformedReducer(acc, value)

    if (isReduced(acc)) {
      return acc.value
    }
  }

  return acc
}

const mapping = transform => reducer => {
  return (acc, value) => {
    return reducer(acc, transform(value))
  }
}

const filtering = predicate => reducer => {
  return (acc, value) => {
    if (predicate(value)) {
      return reducer(acc, value)
    }

    return acc
  }
}

const taking = limit => reducer => {
  let count = 0

  return (acc, value) => {
    if (count >= limit) {
      return reduced(acc)
    }

    count++

    const nextAcc = reducer(acc, value)

    if (count >= limit) {
      return reduced(nextAcc)
    }

    return nextAcc
  }
}

const append = (acc, value) => {
  acc.push(value)
  return acc
}

Usage:

const pipeline = compose(
  filtering(x => x % 2 === 0),
  mapping(x => x * 10),
  taking(3)
)

const result = transduce(
  pipeline,
  append,
  [],
  [1, 2, 3, 4, 5, 6, 7, 8]
)

console.log(result)
// [20, 40, 60]

Pros of Transducers

1. No Intermediate Arrays

They avoid unnecessary arrays created by long map/filter chains.

2. Single-Pass Processing

Multiple transformations can happen in one pass.

3. Reusable Pipelines

You can define transformation logic once and apply it in multiple places.

4. Input-Independent

The same pipeline can work with arrays, sets, generators, async iterables, or custom sources.

5. Output-Independent

The final reducer decides whether the result becomes an array, object, number, string, map, set, or something else.

6. Good for Data Pipelines

They fit well when processing logs, analytics, API responses, permissions, imports, or streaming-like data.

Cons of Transducers

1. Cognitive Overhead

Most JavaScript developers understand map, filter, and loops faster than transducers.

2. Not Native to JavaScript

You need helpers or a library.

3. Not Always Faster

For small arrays, the performance difference may not matter. For raw performance, a plain loop may still win.

4. Harder to Debug Initially

The flow is wrapped in reducer-transforming functions.

5. Can Be Over-Engineering

Do not use transducers for simple one-off transformations.

This is enough:

const names = users.map(user => user.name)

No need to make it fancy.

When I Would Use Transducers

I would consider transducers when:

the dataset is large
transformation chains are long
the pipeline is reused
intermediate arrays are expensive
the output format changes depending on use case
the input might be an array today and a stream tomorrow
early termination matters
I am building internal utilities for data processing

When I Would Not Use Transducers

I would avoid them when:

the code is simple
the team is not familiar with the concept
map() and filter() are already clear
a for...of loop is easier to understand
performance is already fine
the transformation is used only once

The goal is not to be clever. The goal is to write code that is clear, correct, and appropriate for the situation.

Final Thought

reduce() is powerful. But it is also easy to misuse. A for...of loop is often clearer. A normal map/filter chain is often good enough.

A transducer is useful when you need something more specific:

composable transformations without intermediate collections.

That is the real lesson.

Not "always use reduce". Not "always avoid reduce". Not "transducers are always faster".

The better lesson is:

Understand the tools deeply enough to know when not to use them.

For me, transducers are worth learning not because we should use them everywhere, but because they reveal a deeper idea:

Data processing = source + transformation + accumulation

Most code mixes these together. Transducers separate them. And once you see that separation, you start designing data pipelines more intentionally.

About Aruvix

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

Promise.all() Is Not Parallelism — And It Can Break Your System

Amrishkhan Sheik Abdullah — Sat, 09 May 2026 06:56:00 +0000

Promise.all() looks innocent.

It is one of those JavaScript features most developers learn early and start using everywhere.

Fetch multiple APIs? Use Promise.all().

Insert multiple rows? Use Promise.all().

Upload multiple files? Use Promise.all().

Call GitHub API for many blobs? Use Promise.all().

At first, it feels clean.

await Promise.all(items.map(item => processItem(item)));

One line. Beautiful. Fast. Modern.

But here is the uncomfortable truth:

Promise.all() is not a performance strategy. It is a concurrency trigger.

And if you use it blindly, it can quietly break your system.

The Problem Is Not Promise.all() Itself

Promise.all() is not bad.

It is useful, powerful, and perfectly fine when the number of promises is small and controlled.

The problem starts when developers use it like this:

await Promise.all(users.map(user => sendEmail(user)));

Looks harmless.

But what if users.length is:

Now the same line behaves very differently.

That one line can suddenly create:

1,000 API requests
1,000 database queries
1,000 file operations
1,000 network connections
1,000 memory allocations

All at once.

That is where systems start to fail.

Promise.all() Does Not Mean “Run Safely in Parallel”

This is the biggest misunderstanding.

A lot of developers think:

“Promise.all() runs things in parallel.”

Not exactly.

JavaScript does not magically create safe parallel execution for your workload.

What actually happens is:

all async operations are started immediately
JavaScript keeps references to all promises
the runtime waits until all resolve
if one rejects, Promise.all() rejects immediately

That means Promise.all() does not control load.

It does not limit concurrency.

It does not respect API rate limits.

It does not care about your database pool.

It does not protect your server memory.

It simply starts everything.

The Hidden Cost of Starting Everything at Once

Let’s say you are processing 5,000 records.

await Promise.all(
  records.map(record => processRecord(record))
);

This may look efficient.

But internally, you might be doing:

async function processRecord(record: RecordItem) {
  const user = await db.user.findUnique({
    where: { id: record.userId }
  });

  const response = await externalApi.send(user);

  await db.auditLog.create({
    data: response
  });
}

Now multiply that by 5,000.

Suddenly you are not just running 5,000 promises.

You may be creating:

5,000 DB reads
5,000 external API calls
5,000 audit log writes
thousands of objects in memory
thousands of open sockets

This is not optimization.

This is a traffic accident.

1. Concurrency Explosions

A concurrency explosion happens when your code starts more async work than the system can safely handle.

The dangerous part is that the code often looks clean.

await Promise.all(files.map(uploadFile));

But if there are 2,000 files, you just started 2,000 uploads.

A better question is not:

“Can JavaScript run this?”

The better question is:

“Can every system behind this operation handle it?”

Because your code may depend on:

database pool limits
third-party API limits
CPU availability
memory capacity
disk I/O
network stability
cloud provider throttling

Promise.all() ignores all of that.

2. Rate Limiting Problems

Third-party APIs usually do not like sudden request spikes.

If you call an API 500 times at once, you may hit:

429 Too Many Requests
temporary bans
request throttling
degraded responses
random timeouts

Example:

await Promise.all(
  users.map(user => paymentProvider.createCustomer(user))
);

This may work in development with 5 users.

Then fail badly in production with 5,000 users.

The code did not change.

The data size did.

That is why Promise.all() bugs often appear only under real traffic.

3. Memory Spikes

Promise.all() keeps track of all promises and their results.

If each result is small, that is fine.

But if each operation returns a large object, file buffer, API response, or parsed payload, memory usage can spike quickly.

Example:

const results = await Promise.all(
  largeFiles.map(file => readAndParseFile(file))
);

If each parsed file is 20 MB and you process 100 files, you may suddenly hold gigabytes of data in memory.

That can lead to:

slow garbage collection
process crashes
container restarts
server instability
out-of-memory errors

Sometimes the safer solution is to process data in batches or streams instead of loading everything together.

4. Database Connection Exhaustion

This one is extremely common.

Most databases use connection pools.

For example, your app may have a pool limit of 10, 20, or 50 connections.

Now imagine doing this:

await Promise.all(
  orders.map(order =>
    db.order.update({
      where: { id: order.id },
      data: order
    })
  )
);

If orders.length is 1,000, your code tries to schedule 1,000 DB operations immediately.

But your database pool may only support 20 active connections.

The rest wait.

Then things start piling up.

You may see:

connection timeout
slow queries
locked rows
deadlocks
pool exhaustion
failed transactions

Again, Promise.all() is not aware of your database limit.

It will happily overload it.

5. API Throttling and Socket Errors

I faced a real version of this while working with GitHub APIs.

Creating blobs through the GitHub API looked simple at first.

The tempting version was:

await Promise.all(
  files.map(file => github.createBlob(file))
);

Clean, yes. Safe, no.

With many files, this could trigger network instability, throttling, or random failures such as:

socket hang up
write EPIPE
ECONNRESET
request timeout
temporary GitHub API failures

The fix was not to “make Promise.all better.”

The fix was to stop launching everything at once.

Instead, the safer approach was:

limit concurrency
process files in small batches
retry only retryable failures
fail fast for validation errors
avoid retrying 400 Bad Request
use exponential backoff
reduce concurrent blob creation

That changed the mindset completely.

The goal was no longer:

“How do I make this as parallel as possible?”

The goal became:

“How do I make this fast enough without destroying reliability?”

That is the real engineering question.

6. Retries Can Make the Problem Worse

Retries sound like a solution.

But careless retries can multiply the damage.

Imagine this:

await Promise.all(
  requests.map(request =>
    retry(() => callApi(request))
  )
);

If 500 requests fail due to rate limiting, and each one retries 3 times, you may have created 1,500 more requests.

Now your retry logic is attacking the same system that already asked you to slow down.

Retries need discipline.

Good retry logic should consider:

which errors are retryable
how many times to retry
how long to wait
whether to use exponential backoff
whether to add jitter
whether the API returned 429
whether the operation is idempotent

Not every error deserves a retry.

if (error.status === 400) {
  throw error;
}

Retrying bad requests only wastes time and increases load.

7. Partial Failures Are Harder Than They Look

Another issue with Promise.all() is failure behavior.

If one promise rejects, Promise.all() rejects.

await Promise.all([
  uploadFile(file1),
  uploadFile(file2),
  uploadFile(file3),
]);

If file2 fails, the entire Promise.all() rejects.

But what about file1 and file3?

They may have already completed.

Now your system is in a partial success state.

This matters when you are doing things like:

payment operations
database writes
file uploads
email sending
inventory updates
GitHub commits
external integrations

You need to ask:

“If 7 out of 10 operations succeed, what should happen?”

Should you rollback?

Should you retry only failed items?

Should you show partial success?

Should you store failed records for later?

Promise.all() does not answer those questions.

Your architecture has to.

Promise.allSettled() Is Better for Partial Results

When you care about every result, use Promise.allSettled().

const results = await Promise.allSettled(
  files.map(file => uploadFile(file))
);

Then separate success and failure.

const successful = results.filter(
  result => result.status === "fulfilled"
);

const failed = results.filter(
  result => result.status === "rejected"
);

This gives you a complete picture.

But remember:

Promise.allSettled() solves visibility. It does not solve concurrency.

It still starts everything at once.

The Better Pattern: Limit Concurrency

Instead of launching everything together, process with a concurrency limit.

async function processInBatches<T, R>(
  items: T[],
  batchSize: number,
  handler: (item: T) => Promise<R>
): Promise<R[]> {
  const results: R[] = [];

  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);

    const batchResults = await Promise.all(
      batch.map(item => handler(item))
    );

    results.push(...batchResults);
  }

  return results;
}

Usage:

const results = await processInBatches(
  files,
  5,
  uploadFile
);

Now instead of 1,000 uploads at once, you run 5 at a time.

That is slower than unlimited concurrency.

But it is much safer.

And in production, safe usually wins.

Queue Patterns Are Even Better for Heavy Workloads

For large or long-running workloads, batching may still not be enough.

A queue-based approach is often better.

A queue gives you:

controlled concurrency
retry policies
delayed jobs
observability
pause/resume behavior
backpressure
better recovery

Instead of:

await Promise.all(items.map(processItem));

You can push jobs into a queue:

for (const item of items) {
  await queue.add("process-item", item);
}

Then workers process with controlled concurrency:

const worker = new Worker(
  "process-item",
  async job => {
    await processItem(job.data);
  },
  {
    concurrency: 5,
  }
);

That is a much healthier model for serious workloads.

When Promise.all() Is Actually Fine

This article is not saying never use Promise.all().

It is perfectly fine when:

the number of items is small
the workload is predictable
there are no strict rate limits
memory usage is low
failures should fail the whole operation
all operations are independent

Example:

const [user, settings, permissions] =
  await Promise.all([
    getUser(userId),
    getSettings(userId),
    getPermissions(userId),
  ]);

This is a good use case.

The danger starts when the number of promises is dynamic and unbounded.

A Simple Rule I Follow Now

Before using Promise.all(), I ask:

“How many promises can this create in production?”

If the answer is:

3
5
10

Fine.

If the answer is:

unknown
hundreds
thousands
depends on user input
depends on database size

Then I stop and redesign.

Because at that point, I do not need raw Promise.all().

I need one of these:

batching
concurrency limiting
queue processing
streaming
pagination
retry strategy
backpressure handling
partial failure tracking

The Real Lesson

Promise.all() is not dangerous because it is broken.

It is dangerous because it is too easy.

It makes risky concurrency look elegant.

It hides operational complexity behind a beautiful one-liner.

But production systems do not care how clean your code looks.

They care about:

load
limits
memory
failure modes
retries
recovery
reliability

The best engineers do not just ask:

“Can I run these together?”

They ask:

“How much concurrency can this system safely handle?”

That is the difference between writing async code and designing resilient systems.

Final Thought

Promise.all() is a tool.

A very useful one.

But it should not be your default answer for every async workload.

Sometimes the fastest code is the code that finishes first in development.

But the best code is the code that survives production.

Use Promise.all() when the work is small and controlled.

Use queues, batches, and concurrency limits when the system matters.

Because Promise.all() is not parallelism.

It is pressure.

And if you do not control that pressure, your system eventually will.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

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

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Why I’m Building Local-First Developer Tools

Amrishkhan Sheik Abdullah — Fri, 08 May 2026 15:26:21 +0000

The Industry Is Quietly Rebalancing Toward Local-First Applications

There’s a strange irony happening in software right now.

The Industry Is Quietly Rebalancing Toward Local-First Applications

There’s a strange irony happening in software right now.

For years, the industry pushed everything toward the cloud.

Cloud IDEs. Cloud databases. Cloud storage. Cloud AI. Cloud editors. Cloud collaboration. Cloud “smart” everything.

Somewhere along the way, we normalized sending enormous amounts of personal, sensitive, and often unnecessary data across the internet for even the smallest tasks.

Need to format JSON? Upload it.

Need to compare two files? Upload them.

Need to test an API? Upload the request history.

Need AI help? Send your codebase.

Need productivity? Give another app permanent access to your life.

And most developers accepted this because, honestly, we got used to convenience.

But over the last few years, I started noticing something: the more “cloud-native” our tools became, the slower, heavier, more invasive, and more expensive they started feeling.

That realization is one of the biggest reasons I started building local-first developer tools. Not because it sounds trendy, but because I genuinely think the industry is starting to realize that cloud-everything might not actually be the ideal future we imagined.

What “Local-First” Actually Means

A lot of people misunderstand local-first architecture.

It does not mean:

no internet
outdated desktop software
isolated systems
anti-cloud ideology

Local-first simply means:

Your device becomes the primary place where computation happens.

The browser. Your machine. Your storage. Your CPU. Your memory.

The cloud becomes optional infrastructure, not the center of your entire digital existence. That changes everything.

The Browser Became Far More Powerful Than Most People Realize

Modern browsers are ridiculously capable now.

Today, browsers can:

process massive JSON files
run databases
execute AI models
compress files
render large editors
stream data
run WASM applications
perform encryption
manipulate media
cache huge datasets
work offline
run local transformations

In many cases, browsers are now powerful enough to replace entire categories of backend-heavy applications.

But many tools still behave like it’s 2014. Every button triggers a network request. Every feature requires an API. Every interaction depends on a server somewhere.

And that creates problems developers are finally starting to feel.

Cloud-Everything Has a Cost Nobody Talks About

Cloud architecture solved many important problems, but it also introduced a completely different set of problems we rarely discuss openly.

Many modern systems genuinely require:

distributed infrastructure
observability
collaboration
auditability
synchronization
enterprise orchestration

But we’ve also normalized using cloud infrastructure for workflows that often don’t benefit from it at all. That distinction matters.

Privacy Became an Afterthought

This is one of the biggest issues.

Developers routinely paste:

production payloads
API keys
customer data
logs
authentication tokens
internal configs
business documents

...into random online tools.

Not because they’re careless. Because the industry normalized it.

But once your data leaves your machine, you lose a level of control over it. Even if a service claims:

“We do not store your data”

The data was still transmitted. That matters.

Especially for:

enterprise systems
healthcare
finance
aviation
internal tooling
government systems

One of the core ideas behind local-first tooling is simple:

Many developer tasks never needed the cloud in the first place.

Formatting JSON should not require uploading private payloads. Diffing files should not require transmission. Testing APIs should not require syncing your entire workspace to a remote account.

Local-first applications do not automatically make software “secure,” but they do minimize unnecessary exposure surfaces. In many workflows, that’s a meaningful improvement.

Performance Is Quietly Getting Worse

Many modern applications feel slower than older software despite massive hardware improvements.

Why?

Because modern apps often depend on:

authentication layers
analytics tracking
remote synchronization
telemetry
server-side processing
feature flags
subscriptions
multiple API chains

Sometimes a simple interaction travels halfway across the world before returning to your screen. That creates avoidable latency.

For many single-user workflows, local-first applications eliminate that overhead completely. No upload step. No waiting for server processing. No unnecessary round trips.

The difference becomes especially obvious with developer tooling. A large JSON formatter is a perfect example: uploading massive payloads to a server just to reformat text is often slower than processing directly in the browser. The browser already has the data. Why move it?

Offline Capability Is Massively Underrated

We built an industry where software often stops functioning the moment connectivity drops. That’s a surprisingly fragile model.

Developers work:

on flights
in trains
inside unstable networks
in VPN-heavy environments
during outages
inside restricted enterprise systems

Yet many modern applications become unusable offline.

Local-first apps flip that model. The application works first. Connectivity enhances it. That distinction matters.

Offline capability is not just about convenience. It’s about:

resilience
continuity
graceful degradation
reliability

The best tools should not collapse entirely because a server became unavailable.

AI Is Quietly Making Local Processing More Important

This is the part I think most people are underestimating.

AI changes the economics of software dramatically.

Every unnecessary cloud operation now has:

compute cost
token cost
latency cost
inference cost

And developers are starting to notice it.

Many AI workflows today are incredibly wasteful. Huge payloads get sent to LLMs when only tiny transformations were actually needed.

People are burning tokens on:

formatting data
restructuring objects
validating syntax
converting formats
cleaning logs
filtering payloads

...for operations that should often happen locally before AI is even involved.

This is where local-first architecture becomes extremely powerful.

Imagine:

local preprocessing
local parsing
local filtering
local compression
local semantic chunking

before AI requests even happen.

You reduce:

token usage
API costs
response times
hallucination surfaces
unnecessary context size

Local-first preprocessing does not replace cloud AI, but it dramatically improves how efficiently AI gets used. In the AI era, that becomes an economic advantage.

Browser-Native Processing Is the Future

I genuinely believe we’re entering an era where the browser becomes the operating system for a huge class of applications.

Not because servers disappear, but because browsers became capable enough to own far more responsibility.

The old model was:

Browser → Server → Processing → Response

The emerging model is:

Browser → Local Processing → Optional Cloud Enhancement

That shift changes product architecture completely.

Not every workload belongs in the browser, but far more workloads can now run there efficiently than most applications currently allow.

Real Examples of Where Local-First Makes Sense

JSON Formatting

Traditional flow:

upload payload
process on server
return formatted response

Local-first flow:

process entirely in browser
no upload
instant feedback
no privacy concerns

API Testing

Instead of syncing everything to the cloud:

request history can stay local
collections can stay encrypted locally
sync can become optional

AI Workflows

Instead of sending raw noisy payloads directly to AI:

preprocess locally
filter irrelevant data
compress context
chunk intelligently

Then send only meaningful information to the model.

That reduces:

token waste
AI costs
latency
context overload

Local-First Does NOT Mean Anti-Cloud

This part is important.

I’m not anti-cloud.

The cloud is incredible for:

collaboration
backups
synchronization
distributed systems
scalable APIs
team workflows
shared state
large-scale AI inference

But not every operation deserves cloud involvement.

The future probably isn’t fully cloud or fully local. It’s hybrid.

Smart systems will decide:

what should stay local
what should sync
what should process remotely
what should never leave the device

That’s where things get exciting.

Developers Are Starting to Care Again

You can already see the shift happening.

Developers increasingly care about:

ownership
privacy
low-latency tooling
offline workflows
AI efficiency
minimalism
local control

People are getting tired of:

unnecessary subscriptions
forced accounts
cloud lock-in
telemetry overload
bloated apps
“AI-enhanced” features nobody asked for

There’s a growing desire for tools that simply:

open fast, work fast, respect privacy, and stay out of the way.

That’s not nostalgia. That’s good engineering.

Why This Became My Direction

When building tools like:

JSON formatters
API utilities
diff tools
transformers
developer workflows

...I kept asking myself:

“Does this operation truly need a server?”

In many cases, the answer was no.

That question slowly evolved into a philosophy. A local-first mindset.

A belief that developer tools should:

respect the user’s machine
minimize unnecessary transmission
reduce dependency chains
process data where it already exists
optimize for responsiveness
preserve ownership

That philosophy now shapes almost everything I build.

The Industry Isn’t Moving Backward — It’s Rebalancing

I don’t think the future is less connected. I think the future is becoming more intentional about connectivity.

We spent years pushing computation away from users.

Now we’re starting to realize: modern devices are incredibly powerful, modern browsers are incredibly capable, and users increasingly want more control back.

Local-first applications are not a step backward. They’re the next correction.

And honestly, I think we’re only at the beginning of that shift.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

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: Read More

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Final Thoughts

The future isn’t cloud-only. The future is intentional computing.

Faster where possible. Local where meaningful. Cloud where necessary.

The Most Underestimated Function in JavaScript: `reduce()`

Amrishkhan Sheik Abdullah — Fri, 08 May 2026 06:01:54 +0000

Most Developers Meet `reduce()` at the Wrong Time

Usually, it happens through some terrifying one-liner like this:

const result = arr.reduce((a, b) => a + b, 0)

And the immediate reaction is:

"Why not just use a loop?"

Fair question.

Because honestly, most tutorials completely fail to explain what reduce() actually is.

They usually teach:

sum of array values
average calculation
maybe grouping

But they never explain the real thing.

reduce() is not a math utility.

It is one of the most powerful state transformation primitives in JavaScript.

Once you truly understand it, you start seeing it everywhere:

Redux reducers
React state management
parsers
compilers
async pipelines
aggregation systems
permission engines
data normalization
event processing

This article is not another "sum array values" tutorial.

We are going deep into:

how reduce() actually works internally
why developers struggle with it
how it differs from map(), forEach(), and loops
simple examples
advanced real-world patterns
performance considerations
readability tradeoffs
when not to use it

By the end, reduce() will stop feeling magical and start feeling obvious.

What `reduce()` Actually Means

Forget syntax for a second.

The real meaning is:

Take many values and progressively transform them into one value.

That "one value" can be anything:

object
array
tree
promise chain
lookup map
grouped structure
state machine
cache
HTML
SQL query
dependency graph

The important part is this:

reduce() evolves state step by step.

That is the key mental model.

How `reduce()` Actually Works

array.reduce((accumulator, currentItem) => {
  return updatedAccumulator
}, initialValue)

Let’s slow this down properly.

Visualizing the Flow

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

const total = numbers.reduce((sum, current) => {
  return sum + current
}, 0)

Iteration flow:

// Initial state
sum = 0

// Iteration 1
current = 1
sum = 0 + 1 // 1

// Iteration 2
current = 2
sum = 1 + 2 // 3

// Iteration 3
current = 3
sum = 3 + 3 // 6

// Iteration 4
current = 4
sum = 6 + 4 // 10

Final result:

What Makes `reduce()` Different?

The accumulator survives between iterations.

That is the entire magic.

Unlike map() or forEach(), reduce() carries evolving state forward.

That makes it fundamentally more powerful.

`reduce()` vs `map()`

`map()`

map() transforms items independently.

const doubled = [1, 2, 3].map(x => x * 2)
// [2, 4, 6]

Each item has no awareness of previous items.

`reduce()`

reduce() remembers previous iterations.

const runningTotal = [1, 2, 3].reduce((sum, x) => {
  return sum + x
}, 0)
// 6

The result depends on previous state.

That is a completely different concept.

`reduce()` vs `forEach()`

`forEach()`

forEach() is side-effect oriented.

const result = []

users.forEach(user => {
  result.push(user.name)
})

You mutate external state.

`reduce()`

reduce() keeps transformation self-contained.

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

That becomes:

more composable
more predictable
easier to refactor
easier to test

Why Developers Fear `reduce()`

Because most examples are terrible.

For example:

arr.reduce((a, b) => ({ ...a, [b.id]: b }), {})

This is:

hard to read
allocates objects repeatedly
hides intent
looks academic

So developers conclude:

"reduce is unreadable"

No. Bad reducers are unreadable.

Good reducers are incredibly expressive.

The Golden Rule of `reduce()`

The accumulator should represent evolving state clearly.

Bad:

(a, b)

Good:

(usersById, user)

Naming changes everything.

Simple Real-World Example: Grouping Data

Suppose you have:

const users = [
  { name: "John", role: "admin" },
  { name: "Sarah", role: "user" },
  { name: "Mike", role: "admin" }
]

You want:

{
  admin: [
    { name: "John", role: "admin" },
    { name: "Mike", role: "admin" }
  ],
  user: [
    { name: "Sarah", role: "user" }
  ]
}

Traditional Loop

const grouped = {}

for (const user of users) {
  if (!grouped[user.role]) {
    grouped[user.role] = []
  }

  grouped[user.role].push(user)
}

Using `reduce()`

const grouped = users.reduce((groups, user) => {
  if (!groups[user.role]) {
    groups[user.role] = []
  }

  groups[user.role].push(user)
  return groups
}, {})

The intent becomes:

Transform users into a grouped structure.

That is much more declarative.

Why This Scales Better Mentally

In large applications, most code is not business logic.

Most code is about:

reshaping APIs
transforming data
aggregating state
building structures

reduce() becomes extremely useful there.

Advanced Example: Permission Engine

Imagine RBAC permissions.

Input:

const permissions = [
  { screen: "sales", action: "view" },
  { screen: "sales", action: "edit" },
  { screen: "inventory", action: "delete" }
]

Desired output:

{
  sales: {
    view: true,
    edit: true
  },
  inventory: {
    delete: true
  }
}

Using reduce():

const permissionMap = permissions.reduce((map, permission) => {
  if (!map[permission.screen]) {
    map[permission.screen] = {}
  }

  map[permission.screen][permission.action] = true
  return map
}, {})

Now permission checks become:

permissionMap.sales.edit

Which is:

extremely fast
scalable
easy to cache

This is where senior engineers start appreciating reducers deeply.

`reduce()` Can Build Trees

Example input:

const categories = [
  { id: 1, parent: null, name: "Electronics" },
  { id: 2, parent: 1, name: "Phones" },
  { id: 3, parent: 1, name: "Laptops" }
]

You can reduce this into a hierarchical structure.

This is how many CMS systems work internally.

Async Power: Sequential Promise Execution

One of the coolest reduce() patterns:

tasks.reduce(async (previousTask, currentTask) => {
  await previousTask
  return currentTask()
}, Promise.resolve())

This forces tasks to execute sequentially.

Useful for:

rate-limited APIs
database migrations
ordered workflows
queue systems

Most developers never realize reduce() can do this.

The Biggest Misconception

People think:

"reduce is just a shorter loop"

No.

That is not the point.

The point is:

reduce() centralizes transformation logic into a predictable state evolution flow.

That is a huge architectural difference.

Performance Discussion

Is `reduce()` Faster?

Not automatically.

Sometimes a plain loop is faster.

For example:

for (let i = 0; i < arr.length; i++) {
  // work
}

can outperform:

arr.reduce(...)

in tight benchmarks.

But real-world engineering is not usually microbenchmark-driven.

The real advantages are:

composability
maintainability
predictability
transformation clarity

Where `reduce()` Becomes Extremely Useful

1. Single-pass transformations

Instead of:

arr.filter(...).map(...).sort(...)

you can sometimes do:

arr.reduce(...)

in one pass.

Less iteration. Less memory allocation.

2. Avoiding temporary arrays

map() creates arrays.

filter() creates arrays.

reduce() can avoid that.

3. Data normalization

Huge backend and frontend systems constantly normalize data.

Reducers are excellent for this.

But Don’t Abuse It

This is critical.

Not everything should become a reducer.

Bad:

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

Cleaner:

const names = users.map(user => user.name)

Use the simplest tool possible.

Senior developers do not worship reduce().

They respect where it fits.

A Good Rule of Thumb

Use reduce() when:

the output shape differs from the input
the transformation depends on previous state
you are building lookup structures
you are aggregating data
you are composing workflows

Avoid it when:

map() is clearer
filter() is clearer
a loop is simpler
readability suffers

Why Senior Engineers Love It

Because eventually you realize:

Most software engineering is state transformation.

And reduce() is one of the cleanest abstractions for expressing state evolution.

That is why reducers appear everywhere:

React reducers
Redux
compiler passes
parsers
stream processing
aggregation engines
event sourcing
CQRS systems

Even databases conceptually perform reduction-like operations internally.

Final Thoughts

reduce() is underestimated because developers are introduced to it too early and explained too poorly.

People memorize syntax before understanding the idea.

Once you understand this:

reduce() evolves state across a sequence

everything changes.

You stop seeing it as:

confusing syntax
functional programming gimmick
"smart developer code"

and start seeing it for what it really is:

A foundational data transformation primitive.

And honestly? Once it clicks, you begin noticing reducers everywhere in software architecture.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

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: Read More

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Why I Built Aruvix — One Local-First Toolkit for Every Developer Workflow

Amrishkhan Sheik Abdullah — Thu, 07 May 2026 07:08:08 +0000

A privacy-first, offline-first toolkit for JSON formatting, API testing, schema generation, frontend workflows, QA tooling, and developer productivity.

Official Website: https://www.aruvix.com

Aruvix is a powerful, privacy-first, browser-based suite of developer tools designed to keep your workflows fast, secure, and entirely local. Built for developers who are tired of juggling dozens of disconnected online utilities, Aruvix brings everything into one unified workspace.

Whether you are formatting complex JSON, testing APIs, comparing payloads, generating schemas, converting formats, or debugging responses, Aruvix helps you do it faster without sacrificing privacy or performance.

And most importantly: don't waste your AI tokens for simple deterministic tasks.

Formatting JSON, decoding JWTs, converting XML, testing regex, or generating schemas should not require sending payloads to expensive LLMs. Aruvix handles these operations instantly inside your browser with zero uploads and zero token consumption.

Why Aruvix? Better than the Alternatives
JSON Formatter
JSON Compare
API Client
Visualize
Schema Generator
Query (JSONPath)
Code Translator
Converter Tools
Dev Tools
Frontend & CSS Tools
QA Tools
Who Is Aruvix For?

Why Aruvix? Better than the Alternatives

Unlike many existing online tools — which often upload sensitive payloads to remote servers — or heavyweight desktop applications that consume massive resources for simple workflows, Aruvix follows an offline-first, browser-local architecture.

Modern developer workflows are fragmented.

One tab for JSON formatting.

Another for API testing.

Another for JWT decoding.

Another for Base64.

Another for YAML conversion.

Another for regex testing.

Eventually your browser becomes a collection of disconnected utilities with inconsistent UX, privacy concerns, ads, rate limits, and slow processing.

Aruvix was built to solve exactly that problem:

One unified toolkit. One consistent workflow. Everything local-first.

What makes it better

Absolute Privacy: Your JSON, API responses, tokens, configs, schemas, and debugging payloads never leave your browser. No hidden uploads. No unnecessary backend processing.
Speed & Efficiency: Most tools execute instantly with zero server round trips. Large payloads are processed locally using optimized browser-native techniques for maximum responsiveness.
Unified Workspace: No need to juggle 15 different websites for formatting, JWT decoding, Base64 encoding, API testing, schema generation, and conversions. Everything exists inside one cohesive environment.
Cost-Effective: Save your AI tokens for actual problem solving instead of wasting them on deterministic formatting and conversion tasks.

Use AI where intelligence is actually needed.

Let tooling handle tooling.

JSON Formatter

🔗 Tool Link: https://www.aruvix.com/json-formatter

The JSON Formatter is the heart of Aruvix, designed to help developers clean, validate, repair, inspect, and minify JSON effortlessly.

Features

Beautify and format JSON
Minify payloads
Validate JSON syntax
Repair malformed structures
Syntax-highlighted editing

Options Available

Tree View for nested exploration
Table View for arrays
Type View for inferred structures
Raw text editing mode

The Aruvix Advantage

Most online JSON formatters struggle with large payloads, freeze on malformed structures, or require uploading sensitive data to external servers.

Aruvix focuses heavily on:

Large payload usability
Responsiveness
Local execution
Repair capabilities
Smooth editing workflows

Everything happens directly inside your browser.

Whether you are debugging API responses, inspecting production logs, validating webhook payloads, or cleaning third-party integrations, the formatter is designed to keep large JSON payloads readable and manageable without slowing down your browser.

Malformed payloads are common when dealing with legacy systems or manually edited responses. Instead of failing immediately, Aruvix attempts to help developers recover and repair invalid structures quickly.

Try the JSON Formatter here:

👉 https://www.aruvix.com/json-formatter

JSON Compare

🔗 Tool Link: https://www.aruvix.com/json-diff

A side-by-side comparison workspace to quickly identify changed values, missing keys, nested differences, and structural mismatches between JSON objects.

Features

Side-by-side editors
Automatic structural comparison
Path-level difference inspection
Difference summaries

Options Available

Added/removed/changed node summaries
Minified vs formatted comparison support
Deep nested object comparison

The Aruvix Advantage

Traditional text diff tools often highlight formatting changes instead of actual data changes.

Aruvix parses JSON structurally and highlights semantic differences only, helping developers identify meaningful changes faster.

This becomes especially useful when comparing:

API responses across environments
Before/after transformation outputs
Webhook payload changes
Configuration differences
Regression testing snapshots

Instead of manually scanning thousands of lines, developers can focus directly on meaningful structural changes.

Try the JSON Compare tool here:

👉 https://www.aruvix.com/json-diff

API Client

🔗 Tool Link: https://www.aruvix.com/api-tester

A lightweight yet powerful REST API client running entirely inside your browser.

Features

Send HTTP requests
Inspect headers, status, and responses
Import cURL commands
Generate OpenAPI documentation
Pre-request and post-request scripting

Options Available

Environment variables
Request collections
Reusable variables
Proxy support for local testing

The Aruvix Advantage

For quick API testing, developers often do not need a massive Electron-based application consuming huge amounts of memory.

Aruvix provides a lightweight alternative focused on:

Speed
Simplicity
Local workflows
Minimal resource usage

Perfect for:

Quick endpoint testing
Internal API debugging
Webhook validation
Authentication testing
Local development workflows
Lightweight request inspection

The goal is not to replace enterprise collaboration platforms, but to provide an extremely fast and focused API workflow for day-to-day engineering tasks.

Aruvix also works great as a lightweight Postman alternative for developers who prefer fast local-first tooling over heavyweight desktop applications.

Try the API Client here:

👉 https://www.aruvix.com/api-tester

Visualize

🔗 Tool Link: https://www.aruvix.com/visualize

Explore deeply nested JSON objects visually through interactive structures and graph-based inspection.

Features

Interactive node graph views
Search across keys and values
JSONPath inspection
Zoom and pan navigation

Options Available

Export/share visual views
Path tracing
Collapsible nested structures

The Aruvix Advantage

Large nested payloads become difficult to understand in raw text form.

The Visualizer transforms deeply nested hierarchies into intuitive visual structures that are significantly easier to inspect and debug.

When payloads become deeply nested, traditional text editors force developers into endless collapsing, scrolling, and searching.

Visualization makes relationships between nodes, arrays, and structures immediately understandable.

Try the Visualizer here:

👉 https://www.aruvix.com/visualize

Schema Generator

🔗 Tool Link: https://www.aruvix.com/schema

Generate JSON Schema definitions directly from sample payloads.

Features

Generate starter schemas
Validate JSON against schemas
Inspect validation failures
Edit generated schemas

Options Available

Copy/download schemas
Validation reports
Rule customization

The Aruvix Advantage

Instead of manually writing large schema definitions, developers can instantly generate standardized contracts from real payload data.

This accelerates:

API documentation
Validation workflows
Contract-first development

This is especially useful when working with:

Frontend/backend contracts
Validation middleware
API documentation
Mock servers
Automated testing pipelines

Developers can bootstrap schema definitions within seconds instead of manually building large validation structures from scratch.

Try the Schema Generator here:

👉 https://www.aruvix.com/schema

Query (JSONPath)

🔗 Tool Link: https://www.aruvix.com/query

Search, filter, and extract values from deeply nested JSON structures using JSONPath expressions.

Features

Run JSONPath queries
Filter arrays
Extract nested values
Inspect matched paths

Options Available

Live query testing
Match highlighting
Result previews
One-click copy support

The Aruvix Advantage

Developers can visually test JSONPath queries against real payloads before integrating them into production systems.

This significantly reduces debugging time and query trial/error cycles.

Useful for extracting:

Nested IDs
Filtered arrays
Deeply buried attributes
Analytics fields
Transformed API responses

Live query testing dramatically reduces iteration time when building backend transformations or frontend selectors.

Try JSONPath Query here:

👉 https://www.aruvix.com/query

Code Translator

🔗 Tool Link: https://www.aruvix.com/code-translator

Convert JavaScript into TypeScript starter code directly inside the browser.

Features

JS → TS conversion
Type inference
Warning generation
Starter migration assistance

Options Available

Auto-run translation
Editable output
Copy/download support

The Aruvix Advantage

The entire conversion process happens locally, ensuring proprietary code never leaves your machine while still accelerating TypeScript migrations.

The translator is designed as a migration accelerator rather than a perfect one-click replacement.

It helps developers move faster during large JavaScript → TypeScript transitions by generating a reliable starting point for refinement.

Try the Code Translator here:

👉 https://www.aruvix.com/code-translator

Converter Tools

🔗 Tool Link: https://www.aruvix.com/json-to-csv

A comprehensive suite for converting between multiple developer-friendly data formats.

Features

JSON ↔ XML
JSON ↔ YAML
CSV conversion
JSONL conversion
Dart conversion
TOON conversion

Options Available

Auto-convert on paste
Source validation
Download output
Copy to clipboard

The Aruvix Advantage

Instead of opening multiple ad-heavy converter websites, developers can handle all transformations locally inside a single workflow.

Fast. Consistent. Private.

Developers frequently work with multiple formats across APIs, databases, integrations, logs, and export systems.

Aruvix simplifies these transitions without requiring separate conversion platforms for every format.

Explore Converter Tools here:

👉 https://www.aruvix.com/json-to-csv

Dev Tools

🔗 Tool Link: https://www.aruvix.com/dev-tools

A dedicated collection of utilities for debugging, inspection, and payload analysis.

Included Tools

JWT Decoder
Base64 Encoder/Decoder
URL Encoder/Decoder
Regex Tester
Duplicate Key Finder
Timestamp Scanner
JSON Merge
JSON Patch
Structure Analyzer

The Aruvix Advantage

Instead of opening random utilities across the web, Aruvix centralizes the entire debugging workflow into a single consistent interface.

Decode tokens, test regex patterns, inspect payload structures, and analyze responses without leaving the ecosystem.

Small debugging operations consume surprising amounts of developer time throughout the day.

Aruvix centralizes these repetitive micro-workflows into a single environment so engineers can stay focused instead of context switching across tabs.

Explore Developer Utilities here:

👉 https://www.aruvix.com/dev-tools

Frontend & CSS Tools

🔗 Tool Link: https://www.aruvix.com/color-picker

Everything frontend developers need to accelerate UI workflows.

Included Tools

Color Picker
CSS to Tailwind Converter
Design Token Generator
HTML/SVG to JSX Converter
CSS Formatter
CSS Specificity Calculator
Box Shadow Generator
Gradient Generator
Flexbox/Grid Generators

The Aruvix Advantage

Frontend developers constantly rely on fragmented generators and conversion websites during daily workflows.

Aruvix consolidates those repetitive utilities into a single streamlined experience with consistent UX and local execution.

Frontend development often involves repetitive experimentation with layouts, spacing, gradients, color systems, and utility conversions.

Aruvix helps speed up these workflows while keeping everything accessible from one consistent workspace.

Instead of searching for isolated CSS generators, frontend engineers can iterate directly within the same ecosystem used for APIs, payloads, and debugging.

Explore Frontend & CSS Tools here:

👉 https://www.aruvix.com/color-picker

QA Tools

🔗 Tool Link: https://www.aruvix.com/test-data-generator

A dedicated toolkit for QA engineers and testers to validate faster and generate better reports.

Included Tools

Test Data Generator
Bug Report Generator
API Assertion Generator
HAR Viewer
UUID Generator
Fake User/Data Generator

Options Available

CSV/SQL/JSON export
Configurable row counts
Jira/GitHub markdown formatting
Structured regression reporting

The Aruvix Advantage

QA teams should not need separate utilities for generating test data, formatting reports, validating APIs, and inspecting payloads.

Aruvix centralizes these workflows while keeping all generated data local and private.

QA engineers frequently need to generate large amounts of realistic test data while maintaining privacy and consistency across environments.

Aruvix enables rapid dataset generation directly inside the browser without external dependencies.

This becomes particularly useful during regression testing, staging validation, and automated test preparation.

Explore QA Tools here:

👉 https://www.aruvix.com/test-data-generator

Who Is Aruvix For?

Aruvix is designed for:

Backend developers
Frontend engineers
QA teams
API developers
DevOps engineers
Full-stack developers
Developers working with large JSON payloads
Teams looking for privacy-first workflows

Whether you are debugging APIs, formatting JSON, generating schemas, testing regex, converting formats, or building frontend workflows — Aruvix keeps everything fast, local-first, and privacy-focused.

Final Thoughts

Aruvix is built around a simple philosophy:

Developer tools should feel fast.
Your data should remain yours.
Simple tasks should not consume AI tokens.
And workflows should stay unified instead of fragmented across dozens of disconnected tools.

One toolkit.
One workflow.
Everything local-first.

Build faster.
Debug smarter.
Waste fewer tokens.

Explore Aruvix

🌐 Official Website: https://www.aruvix.com

JSON Formatter → https://www.aruvix.com/json-formatter
JSON Compare → https://www.aruvix.com/json-diff
API Client → https://www.aruvix.com/api-tester
Schema Generator → https://www.aruvix.com/schema
Visualizer → https://www.aruvix.com/visualize

Build faster.
Debug smarter.
Waste fewer tokens.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan