DEV Community: Amrishkhan Sheik Abdullah

Composability Is The Real Superpower

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

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

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

At first glance, these seem like completely different topics.

Some are functional programming concepts.

Some are architecture patterns.

Some are JavaScript APIs.

Some are performance discussions.

But there is a common thread connecting all of them.

And it's not:

reduce()

It's not:

monads

It's not:

RxJS

The real superpower behind all of them is:

COMPOSITION

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

They're built from small pieces that work together.

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

The Biggest Mistake Developers Make

Many developers spend years learning functions.

Senior engineers spend years learning patterns.

The difference matters.

For example:

const usersById =
  users.reduce(...)

Interesting.

But not transformative.

The truly valuable question is:

How do I combine small pieces
into larger systems?

That question changes everything.

Because software is ultimately a composition problem.

Why Large Functions Rot

Let's start with something most developers have seen.

function processCheckout(
  order
) {
  validateOrder(order)

  calculateTax(order)

  applyDiscount(order)

  reserveInventory(order)

  generateInvoice(order)

  sendConfirmationEmail(order)

  updateAnalytics(order)

  createShipment(order)

  notifyWarehouse(order)

  updateCRM(order)
}

Looks harmless.

Now imagine this function after three years.

500 Lines

Multiple Conditions

Feature Flags

Edge Cases

Special Customers

Regional Logic

Eventually:

Nobody Wants To Touch It

The function becomes fragile.

Every change becomes risky.

Small Functions Scale Better

Instead:

const validateOrder =
  order => order

const calculateTax =
  order => order

const applyDiscount =
  order => order

const reserveInventory =
  order => order

Each function has:

One Responsibility

This matters because:

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

That is composition.

Unix Understood This Decades Ago

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

It's Unix.

Consider:

cat logs.txt |
grep ERROR |
sort |
uniq

Each command does one thing.

cat
↓
grep
↓
sort
↓
uniq

Individually:

Not impressive.

Together:

Extremely powerful.

Fifty years later:

We're still using this pattern.

That should tell us something.

React Won Because Of Composition

Many developers think React succeeded because of JSX.

Or hooks.

Or virtual DOM.

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

React succeeded because of composition.

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

Every component is:

Reusable
Composable
Replaceable

You don't build one giant UI.

You build pieces.

Then compose them.

RxJS Is Composition

Consider:

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

At first glance:

This looks like operators.

But underneath:

Function
↓
Function
↓
Function

Each operator produces a new stream.

The real value isn't:

map()

The real value is:

The Ability To Combine Them

Again:

Composition.

Event Sourcing Is Composition

In the previous article we saw:

events.reduce(
  reducer,
  initialState
)

Now imagine:

Events
↓
Projection A

Projection B

Projection C

Projection D

The same event stream can generate:

Account Balances
Reports
Analytics
Audit Logs

Why?

Because reducers compose.

The architecture becomes flexible because the pieces are composable.

Microservices Done Right

Good microservices are not:

Many Services

Good microservices are:

Composable Services

Each service should be:

Independent
Replaceable
Focused

The goal isn't:

More Services

The goal is:

Better Composition

Unfortunately many teams create:

Distributed Monoliths

which have all the complexity and none of the benefits.

Composition Beats Inheritance

Consider classical inheritance.

class Animal {}

class Bird extends Animal {}

class FlyingBird extends Bird {}

Eventually:

FlyingSwimmingBird

appears.

Then:

FlyingSwimmingHuntingBird

And things become ridiculous.

Composition offers a different approach.

const canFly = {}

const canSwim = {}

const canHunt = {}

Combine capabilities.

Instead of inheriting everything.

This scales far better.

Building A Tiny Utility Library

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

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

Usage:

const addOne =
  x => x + 1

const double =
  x => x * 2

const square =
  x => x * x

const process =
  pipe(
    addOne,
    double,
    square
  )

console.log(
  process(2)
)

Output:

Why?

2
↓
3
↓
6
↓
36

Small pieces.

Large result.

Real World Example: API Processing

Suppose we're building an API Studio.

Bad:

function processRequest(
  request
) {
  // 1000 lines
}

Better:

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

Each stage:

Independent.

Composable.

Replaceable.

Testable.

This architecture scales much better over time.

Real World Example: Payment Processing

Instead of:

function processPayment() {
  ...
}

Think:

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

Each step becomes reusable.

You can swap providers.

Add new logic.

Remove old logic.

Without rewriting the entire system.

Real World Example: CI/CD Pipelines

GitHub Actions.

GitLab CI.

Azure DevOps.

All rely heavily on composition.

Checkout
↓
Install
↓
Test
↓
Build
↓
Deploy

Independent stages.

Combined together.

Again:

Composition.

Why Composition Feels So Powerful

Because it gives us leverage.

Imagine:

100 Independent Functions

versus:

1 Giant Function

The first system creates:

Reuse
Flexibility
Scalability

The second creates:

Coupling
Complexity
Fragility

This is why composability appears everywhere.

The Hidden Connection Between Everything We've Learned

Let's revisit the series.

Reduce:

Composable State Transitions

Transducers:

Composable Transformations

Functors:

Composable Mapping

FlatMap:

Composable Container Operations

Monads:

Composable Computations

RxJS:

Composable Streams

Event Sourcing:

Composable Reducers

Different vocabulary.

Same underlying idea.

Pros Of Composable Systems

1. Easier To Test

Small units are easier to validate.

2. Easier To Reuse

Components can appear in multiple places.

3. Easier To Replace

Swap one piece without rewriting everything.

4. Better Scalability

Systems evolve naturally.

5. Better Team Collaboration

Multiple engineers can work independently.

Cons Of Composition

Let's be honest.

Composition is not free.

1. Too Many Small Functions

Overdoing it creates fragmentation.

2. Debugging Can Become Harder

Execution paths may span many layers.

3. Abstraction Overload

Not every problem needs twenty tiny functions.

4. Indirection

Following the flow can take time.

5. Overengineering Risk

Sometimes a simple function is enough.

The Real Lesson

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

reduce()

monads

RxJS

Those are merely tools.

The deeper lesson is:

Small Things
That Work Together
Beat
Big Things
That Do Everything

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

They're powerful because those functions compose.

That's true for:

React
Unix
RxJS
Event Sourcing
Microservices
Modern Frontend Architectures
Functional Programming

Different ecosystems.

Same principle.

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

Because ultimately:

Composability is the real superpower.

What's Next?

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

Building Your Own Functional Utility Library

We'll implement:

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

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

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

Why Retry Is One Of The Most Dangerous Keywords In Software

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

Few lines of code look more innocent than this:

retry(3)

It feels responsible.

Professional.

Resilient.

After all, networks fail.

Servers become unavailable.

Databases occasionally time out.

Retrying seems like the obvious solution.

And sometimes it is.

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

Retry is one of the most dangerous keywords in software.

Not because retries are bad.

Because retries amplify everything.

Good systems become more reliable.

Bad systems become disasters.

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

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

Why Retries Exist

Imagine:

await fetch("/api/users");

The request fails.

Maybe:

Network hiccup
Temporary database issue
Load balancer restart
Service deployment

The operation might succeed if attempted again.

So we write:

retry(3)

Seems reasonable.

And in many cases:

It Works

Which is why retries become popular.

The Dangerous Assumption

Most developers unconsciously assume:

Failure
=
Operation Did Not Execute

Unfortunately that's not always true.

A request can:

Execute Successfully
↓
Response Never Arrives

From the client's perspective:

Failure

From the server's perspective:

Success

Now a retry becomes dangerous.

The Double Payment Problem

Imagine a payment service.

await chargeCard(order);

The card processor successfully charges:

$100

The response is lost due to a network issue.

Client sees:

Request Failed

and retries.

await chargeCard(order);

again.

Now:

Charge #1 = Success
Charge #2 = Success

The customer paid twice.

Nobody wrote bad logic.

The retry created the bug.

The Email Storm Problem

Consider:

await sendWelcomeEmail(user);

Email provider accepts the message.

Response times out.

Application retries.

await sendWelcomeEmail(user);

again.

Customer receives:

Welcome!
Welcome!
Welcome!
Welcome!

Support ticket created.

Marketing team confused.

The retry succeeded.

Too well.

Retries Amplify Side Effects

This is the core issue.

Pure operations:

2 + 2

can run forever.

Nothing changes.

Side effects are different.

Examples:

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

Each execution changes reality.

Retries repeat reality.

And reality doesn't always appreciate repetition.

The Thundering Herd Problem

One failed request isn't scary.

Ten thousand retries are.

Imagine:

Service A

becomes slow.

Clients start retrying.

Traffic doubles.

Service becomes slower.

More retries occur.

Traffic doubles again.

Eventually:

Small Failure
↓
Massive Outage

This is known as:

The Thundering Herd Problem

And retries are often the cause.

When Retries Attack Databases

Suppose:

Database

is under heavy load.

Queries start timing out.

Application retries automatically.

Now:

More Queries
↓
More Load
↓
More Timeouts
↓
More Retries

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

Why Idempotency Matters

In the previous article we discussed:

Idempotency

This is where it becomes critical.

Without idempotency:

Retry
=
Repeat Side Effects

With idempotency:

Retry
=
Same Result

A retry becomes safe.

That's why reliable systems almost always combine:

Retries
+
Idempotency

rather than using retries alone.

Not Every Failure Should Be Retried

A common mistake:

retry(3)

for every error.

Consider:

400 Bad Request

Retrying won't help.

The request is invalid.

Or:

401 Unauthorized

Retrying won't magically authenticate the user.

Good retry policies distinguish between:

Transient Failures

and

Permanent Failures

Exponential Backoff Exists For A Reason

Bad:

Retry Immediately
Retry Immediately
Retry Immediately

Better:

1 Second
↓
2 Seconds
↓
4 Seconds
↓
8 Seconds

This is:

Exponential Backoff

and it prevents systems from overwhelming already struggling services.

Real World Example: Flight Booking

Imagine:

Reserve Seat

times out.

Client retries.

Without protection:

Seat Reserved Twice

or:

Two Different Seats Reserved

Now inventory becomes inconsistent.

Airlines spend enormous effort preventing these scenarios.

Because retries happen constantly.

Real World Example: Webhooks

Webhook providers often retry automatically.

For example:

Payment Completed

may arrive:

1 Time
2 Times
5 Times

depending on delivery conditions.

Systems that assume:

Exactly Once

processing usually fail eventually.

Systems that expect retries survive.

Real World Example: Message Queues

Kafka.

RabbitMQ.

SQS.

Azure Service Bus.

All assume:

Messages May Be Delivered Again

because reliability is more important than uniqueness.

Consumers must be designed accordingly.

Common Retry Mistakes

Retrying Everything

Not every failure is recoverable.

Retrying Immediately

Often makes outages worse.

Ignoring Idempotency

Creates duplicate side effects.

Infinite Retries

Eventually becomes infinite damage.

Hiding Failures

Retries should not become a substitute for monitoring.

Pros Of Retries

1. Better Reliability

Transient failures disappear.

2. Better User Experience

Temporary outages become invisible.

3. Improved Resilience

Systems tolerate instability.

4. Reduced Manual Intervention

Many failures self-heal.

5. Better Distributed Systems

Network failures become manageable.

Cons Of Retries

1. Duplicate Operations

Without idempotency.

2. Traffic Amplification

Can worsen outages.

3. Cascading Failures

One issue spreads across systems.

4. Increased Complexity

Backoff strategies become necessary.

5. Hidden Production Problems

Retries can mask deeper issues.

The Real Lesson

Most developers think retries exist to make software more reliable.

That's only partially true.

Retries don't eliminate failures.

They change failures.

Sometimes they transform:

Temporary Network Problem

into:

Duplicate Payment

Sometimes they transform:

Slow Database

into:

Full System Outage

That's why experienced engineers don't ask:

Should We Retry?

They ask:

What Happens If This Operation Executes Twice?

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

It's a certainty.

And reliable systems are designed with that reality in mind.

What's Next?

In the next article we'll discuss:

The Myth Of Stateless Systems

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

And that distinction turns out to be extremely important.

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

Idempotency Is More Important Than You Think

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

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

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

Unfortunately, real systems don't work that way.

Networks fail.

Browsers retry.

Mobile applications reconnect.

Users double-click buttons.

Webhooks arrive multiple times.

Message queues redeliver events.

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

Or three times.

Or ten times.

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

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

That's idempotency.

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

What Is Idempotency?

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

For example:

user.isActive = true;

Running this once:

user.isActive = true;

or a hundred times:

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

produces the same outcome.

The user remains active.

This operation is idempotent.

Now compare that with:

user.balance += 100;

Running it once:

Balance = 100

Running it twice:

Balance = 200

Running it three times:

Balance = 300

This operation is not idempotent.

The result changes every time it executes.

Why This Matters More Than Most Developers Realize

Consider a simple payment API.

await chargeCard(order);

Looks harmless.

Now imagine this sequence:

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

The payment system behaved correctly.

The network failed.

The client retried.

The customer got charged twice.

The bug isn't in the payment logic.

The bug is that the operation wasn't idempotent.

The Reality Of Distributed Systems

Most software developers think in terms of:

Request
↓
Response
↓
Done

Production systems look more like:

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

The moment you have:

Networks
APIs
Queues
Mobile Apps
Multiple Servers

you have duplicates.

Not maybe.

Definitely.

The only question is whether your system handles them safely.

The Double-Click Problem

One of the simplest examples.

Imagine an e-commerce checkout page.

User clicks:

Place Order

Nothing happens for two seconds.

User clicks again.

Now two requests arrive.

Request A
Create Order

and

Request B
Create Order

If the backend simply executes both:

Order #1001
Order #1002

The customer now owns two orders.

This happens more often than many developers think.

Why HTTP Introduced Idempotent Methods

HTTP recognized this problem decades ago.

Consider:

GET /users/123

Calling it:

1 Time
10 Times
100 Times

doesn't change the system.

GET is idempotent.

Now consider:

POST /orders

Every call creates something new.

POST is generally not idempotent.

That's why retries become dangerous.

PUT Is Often Safer Than POST

Suppose we create a user.

POST:

POST /users

Multiple calls:

User A
User B
User C

Potentially multiple records.

Now:

PUT /users/123

Multiple calls:

Update User 123
Update User 123
Update User 123

Same final state.

This is one reason PUT is considered idempotent.

The Webhook Nightmare

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

Stripe.

GitHub.

PayPal.

Most webhook providers explicitly tell you:

Your endpoint must handle duplicate events.

Why?

Because delivery guarantees are difficult.

Imagine:

Payment Completed
↓
Webhook Sent
↓
Server Timeout
↓
Provider Retries

Now your endpoint receives:

Payment Completed
Payment Completed

twice.

If your system isn't idempotent:

Invoice Generated Twice
Email Sent Twice
Inventory Reserved Twice

Chaos follows.

Message Queues Assume Duplicates

Kafka.

RabbitMQ.

SQS.

Azure Service Bus.

Most messaging systems prioritize reliability.

That means:

At Least Once Delivery

instead of:

Exactly Once Delivery

Because exactly-once delivery is extremely difficult.

The implication is important.

Consumers must be prepared to process duplicate messages.

This is where idempotency becomes essential.

Event Sourcing Depends On It

In a previous article we discussed Event Sourcing.

Imagine an event stream:

OrderCreated
PaymentReceived
InventoryReserved

Now imagine:

PaymentReceived

arrives twice.

Without idempotency:

Balance += Payment
Balance += Payment

The projection becomes corrupted.

Reliable event processing requires idempotent handlers.

The Idempotency Key Pattern

One of the most common solutions is:

Idempotency Keys

Example:

POST /payments

Idempotency-Key:
abc123

Backend receives:

abc123

and stores:

Request
Result

If the same request arrives again:

abc123

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

From the client's perspective:

Retry Safe

This pattern powers many payment systems.

Real World Example: Flight Bookings

Imagine booking a flight.

Customer submits payment.

Network times out.

Browser retries.

Without idempotency:

Two Payments
Two Bookings

Now support teams become involved.

With idempotency:

Same Booking
Same Payment
Same Result

No problem.

The retry becomes harmless.

Real World Example: API Studio

Suppose we're building an API testing platform.

User sends:

POST /create-user

five times accidentally.

Should the server create:

5 Users

or:

1 User

The answer depends on the business requirement.

Idempotency is not purely technical.

It's often a business decision.

Why Exactly-Once Is Mostly A Myth

Many developers initially aim for:

Exactly Once Processing

The problem is that distributed systems make this incredibly expensive.

Instead, many successful systems choose:

At Least Once Delivery
+
Idempotent Consumers

This is often simpler and more reliable.

Common Mistakes

Assuming Retries Are Safe

They aren't.

Retries amplify non-idempotent behavior.

Ignoring Duplicate Webhooks

Every major webhook provider warns about this.

Many developers still forget.

Using Auto-Increment IDs As Deduplication

Duplicates often arrive before the new record is visible.

Trusting The Network

Networks fail constantly.

Design accordingly.

Treating Idempotency As An Optimization

It's not.

It's a reliability requirement.

Pros Of Idempotent Systems

1. Safe Retries

Clients can retry without fear.

2. Better Reliability

Transient failures become easier to handle.

3. Simpler Distributed Systems

Duplicate messages stop being catastrophic.

4. Better User Experience

Double-clicks don't create duplicate operations.

5. More Resilient Event Processing

Replay and recovery become safer.

Cons Of Implementing Idempotency

Let's be honest.

Idempotency is not free.

1. Additional Storage

Keys and processed requests often need tracking.

2. More Complexity

Deduplication logic must exist somewhere.

3. Edge Cases

Determining whether two requests are truly identical can be difficult.

4. Operational Overhead

Retention and cleanup strategies become necessary.

5. Design Effort

You must think about failures upfront.

The Real Lesson

Most developers think software executes like this:

Request
↓
Success
↓
Done

Production systems look more like:

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

Once you accept that reality, your design philosophy changes.

You stop asking:

Will This Request Succeed?

and start asking:

What Happens If It Runs Twice?

That single question prevents an enormous number of production incidents.

Because in distributed systems, duplicates are inevitable.

Reliable systems aren't the ones that avoid duplicates.

They're the ones that make duplicates harmless.

And that's exactly what idempotency gives you.

What's Next?

In the next article we'll discuss:

Why Retry Is One Of The Most Dangerous Keywords In Software

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

retry(3)

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

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

Why Abstractions Leak

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

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

Not because success is bad.

But because perfect abstractions create an illusion.

The illusion is:

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

For a while, that's true.

Then production happens.

Then scale happens.

Then edge cases happen.

Then reality happens.

And suddenly:

The abstraction leaks.

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

The Law of Leaky Abstractions

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

What Is An Abstraction?

An abstraction hides complexity.

Example:

fetch("/users")

Looks simple.

Behind that line:

DNS Lookup

TCP Connection

TLS Handshake

HTTP Request

Network Routing

Server Processing

Serialization

Response Parsing

Thousands of things happen.

The abstraction hides them.

That's the point.

Why We Need Abstractions

Imagine writing:

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

every time.

Nobody wants that.

Abstractions make software possible.

Without them:

Modern Software Would Not Exist

The Problem

The abstraction hides complexity.

It does not remove complexity.

That distinction matters.

Because eventually:

fetch("/users")

fails.

And suddenly:

You Need To Understand
The Things It Was Hiding

Example #1: ORMs

Developers love ORMs.

Example:

const users =
  await User.findAll()

Looks beautiful.

Looks simple.

Looks harmless.

Then somebody adds:

user.posts

inside a loop.

Suddenly:

100 Users

100 Queries

Database Meltdown

The famous:

N + 1 Query Problem

appears.

The ORM abstraction leaked.

Example #2: React

React hides DOM manipulation.

Instead of:

document.createElement(...)

we write:

<UserCard />

Wonderful.

Until:

5000 Components

Frequent Updates

Slow Rendering

Now you need to understand:

Reconciliation

Memoization

Reference Equality

Rendering Lifecycle

The abstraction leaked.

Example #3: Promise.all()

Looks simple.

await Promise.all(
  requests
)

Feels magical.

Until:

5000 Requests

hit production.

Now:

Rate Limits

Memory Pressure

Connection Pools

Timeouts

suddenly matter.

Again:

The abstraction leaked.

Example #4: Kubernetes

Developers often say:

Kubernetes Makes Deployment Easy

Until something breaks.

Then:

Pods

Services

Ingress

DNS

Networking

Volumes

Secrets

Scheduling

become your problem.

The abstraction leaked.

Example #5: Functional Programming

Even FP abstractions leak.

Consider:

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

Looks elegant.

Then:

1 Million Records

arrive.

Now:

Allocations

Garbage Collection

Intermediate Arrays

matter.

Suddenly:

You Need To Understand
The Implementation

The abstraction leaked.

The Reduce Example

Earlier in this series we discussed:

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

Looks elegant.

Looks immutable.

Looks functional.

At scale:

O(n²)

The abstraction leaked.

The implementation became important.

Why Leaks Are Inevitable

Many developers think:

Good Abstractions
Never Leak

This is impossible.

Because reality is more complex than any abstraction.

Always.

Eventually:

Performance

Memory

Concurrency

Networking

Storage

Scale

find a way through.

The Database Example

You can use:

User.findAll()

for years.

Then one day:

Database CPU 100%

Now suddenly:

SELECT *
FROM users

matters.

The SQL was always there.

The ORM simply hid it.

The Cloud Example

Many developers think:

Serverless Means
No Servers

It doesn't.

It means:

Someone Else's Servers

Eventually:

Cold Starts

Execution Limits

Concurrency Limits

appear.

The abstraction leaks.

Why Senior Engineers Feel Different

Junior engineers often trust abstractions.

Senior engineers respect abstractions.

Those are not the same thing.

A senior engineer sees:

fetch(...)

and mentally understands:

Network

Latency

Retries

Timeouts

Failures

even when they aren't visible.

That's experience.

The Best Developers Learn Both Layers

Bad approach:

Only Learn Frameworks

Also bad:

Only Learn Internals

The best developers learn:

Abstraction
+
Implementation

Both matter.

Real World Example: API Studio

Suppose we're building an API Studio.

We expose:

Send Request

as a button.

Simple.

Behind the scenes:

DNS

TLS

Headers

Body Serialization

Compression

Retries

Timeouts

Certificates

Users shouldn't see those details.

But we must understand them.

Because eventually:

A Bug Will Live There

Real World Example: Git

Git feels simple.

git commit

Until:

Merge Conflicts

Detached HEAD

Rebase Failures

Corrupted Refs

appear.

Then:

Objects

Trees

Blobs

Refs

Packfiles

suddenly matter.

The abstraction leaked.

The Hidden Connection To This Entire Series

Reduce leaked.

We learned Transducers.

Transducers leaked.

We learned composition.

RxJS leaked.

We learned streams.

Event Sourcing leaked.

We learned reducers.

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

And that's not a bad thing.

That's how deeper understanding develops.

Pros Of Abstractions

1. Faster Development

Less code.

2. Better Productivity

Focus on business logic.

3. Lower Cognitive Load

Hide complexity.

4. Better Reusability

Shared solutions.

5. Better Collaboration

Common interfaces.

Cons Of Abstractions

1. Performance Surprises

The implementation is hidden.

2. Debugging Complexity

Problems occur below the abstraction.

3. Knowledge Gaps

Developers stop learning fundamentals.

4. Vendor Lock-In

Sometimes abstractions become cages.

5. Leaks

Eventually reality breaks through.

Always.

The Real Lesson

The biggest mistake developers make is assuming abstractions remove complexity.

They don't.

They move complexity.

That's a huge difference.

The complexity still exists.

It's simply hidden until something goes wrong.

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

The Abstraction

and

The Implementation

are the ones who solve the problem.

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

Eventually they look underneath.

Because every abstraction leaks.

And that's where the real learning begins.

What's Next?

In the next article we'll discuss:

The Two Hard Things In Computer Science

Because one famous joke contains an uncomfortable amount of truth:

There are only two hard things
in Computer Science:

Cache Invalidation

Naming Things

and Off-by-One Errors

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

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

Building Your Own Functional Utility Library

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

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

Over the last several articles we've discussed:

Reduce
Transducers
Functors
FlatMap
Monads
RxJS
Composition

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

Most of them are tiny.

Really tiny.

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

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

They start feeling obvious.

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

Not because you'll replace existing libraries.

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

Why Build Your Own?

Most developers use libraries like:

Lodash
Ramda
fp-ts
RxJS

without understanding the ideas underneath.

That's completely fine.

But implementing the primitives yourself teaches:

How Composition Works

How Reduce Works

How FlatMap Works

How Transducers Work

How Functional Pipelines Work

Which is far more valuable than memorizing APIs.

The Simplest Utility: Identity

Let's start with the most boring function imaginable.

const identity = x => x

Usage:

identity(5)

Output:

Not impressive.

But surprisingly useful.

Many FP abstractions rely on identity.

Implementing pipe()

One of the most useful utilities in any FP library.

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

Usage:

const addOne =
  x => x + 1

const double =
  x => x * 2

const square =
  x => x * x

const process =
  pipe(
    addOne,
    double,
    square
  )

console.log(
  process(2)
)

Output:

Flow:

2
↓
3
↓
6
↓
36

This is composition in action.

Implementing compose()

Some developers prefer right-to-left composition.

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

Usage:

const process =
  compose(
    square,
    double,
    addOne
  )

Produces:

2
↓
3
↓
6
↓
36

Same result.

Different direction.

Building map()

Let's implement our own map.

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

Usage:

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

double([1,2,3])

Output:

[2,4,6]

Notice something.

We made it:

Curried

which allows composition.

Building filter()

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

Usage:

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

Again:

Composable.

Building reduce()

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

Usage:

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

sum([1,2,3])

Output:

Creating Reusable Pipelines

Now things get interesting.

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

Usage:

processUsers(users)

This begins to feel like a miniature Ramda.

Building flatMap()

From an earlier article:

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

Usage:

flatMap(
  user => user.roles
)

Output:

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

Again:

Tiny implementation.

Huge usefulness.

Implementing a Tiny Maybe Monad

Let's build a minimal Maybe type.

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

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

  value() {
    return value
  }
})

Usage:

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

Output:

JOHN

You've just built a Monad.

Without category theory.

Implementing Transducers

Let's revisit Transducers.

Map Transducer:

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

Filter Transducer:

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

Compose:

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

Single pass.

No intermediate arrays.

Exactly as discussed earlier.

Building A Tiny Stream

Let's build a very small Observable.

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

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

Usage:

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

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

Output:

2
4
6

Tiny implementation.

Huge insight.

What We Learned

A surprising pattern emerges.

Most abstractions are:

Much Simpler
Than Their Names Suggest

Functors:

map()

Monads:

flatMap()

Transducers:

Composable Reducers

RxJS:

Composable Streams

Composition:

Functions Combined

The terminology sounds intimidating.

The implementations are often tiny.

Real World Example

Suppose we're processing API responses.

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

Clean.

Composable.

Reusable.

Pros Of Building Your Own Utilities

1. Deep Understanding

You learn the underlying mechanics.

2. Better Debugging

Abstractions stop feeling magical.

3. Improved Architecture Skills

You begin designing composable systems.

4. Stronger JavaScript Knowledge

Language fundamentals become clearer.

5. Better Library Evaluation

You understand what libraries are actually doing.

Cons Of Building Your Own Utilities

1. Not Production Ready

Use mature libraries when appropriate.

2. Missing Edge Cases

Production libraries handle many corner cases.

3. Maintenance Cost

You now own the code.

4. Performance Optimizations

Libraries often contain years of tuning.

5. Reinventing The Wheel

Sometimes unnecessary.

The Real Lesson

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

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

The scary names:

Functor

Monad

Transducer

often hide tiny implementations.

The real value isn't the code.

The real value is the mindset.

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

And that skill transfers everywhere:

Frontend Development
Backend Systems
Event Processing
API Design
Architecture

Because ultimately:

Great software isn't built from giant frameworks.

It's built from small pieces that work together.

What's Next?

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

Why Abstractions Leak

Because every abstraction eventually breaks down.

And understanding why helps you design better systems.

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

Event Sourcing Is Just Reduce Over Time

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

Event Sourcing has a reputation problem.

The moment someone mentions it, the conversation usually becomes:

Event Store
CQRS
Snapshots
Replay
Projections
Distributed Systems

And most developers immediately think:

This sounds complicated.

I used to think the same thing.

Then one day I realized something.

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

In fact, most JavaScript developers already know it.

They just know it by a different name.

reduce()

That's right.

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

Because Event Sourcing is really just:

Reduce applied to business events.

And once you see that, everything starts making sense.

The Traditional Way We Store State

Suppose we have a bank account.

Current balance:

{
  accountId: 1,
  balance: 125
}

Most systems store the current state.

When money is deposited:

125
↓
175

The old value disappears.

The database simply stores:

{
  accountId: 1,
  balance: 175
}

Simple.

But something important is lost.

What Actually Happened?

Imagine an auditor asks:

How did we reach 175?

The database cannot answer.

It only knows:

Current State

The history is gone.

Event Sourcing Stores Events Instead

Instead of storing:

{
  balance: 175
}

we store:

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

Notice something.

We no longer store state.

We store:

History

Reconstructing State

Now let's calculate the balance.

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

      case "WITHDRAW":
        return balance - event.amount

      default:
        return balance
    }
  }

const balance =
  events.reduce(
    accountReducer,
    0
  )

Output:

Look carefully.

That is Event Sourcing.

Literally.

The Formula Behind Everything

Every Event Sourced system follows:

Initial State
+
Event
=
Next State

Which should feel familiar.

Because that's exactly how reducers work.

(state, event) =>
  nextState

Same idea.

Different scale.

Redux Was Preparing You For This

Consider Redux.

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

    default:
      return state
  }
}

Actions:

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

Process them:

actions.reduce(
  reducer,
  0
)

Output:

Sound familiar?

It should.

Because Redux and Event Sourcing are siblings.

Both are:

State Evolution
Through Events

Why Event Sourcing Exists

The obvious question:

Why not just store the state?

Good question.

The answer is:

History has value.

Benefit #1: Audit Trail

Traditional database:

Balance = 175

Event Sourcing:

Deposit 100
Deposit 100
Withdraw 25

Now you know exactly how the state was produced.

Benefit #2: Time Travel

Want the account balance yesterday?

Simply replay events until yesterday.

eventsUntilYesterday.reduce(
  reducer,
  0
)

Done.

Benefit #3: Debugging

Imagine a production bug.

Traditional system:

State is wrong.

Why?

Nobody knows.

Event Sourcing:

Replay the events.

The bug becomes reproducible.

Benefit #4: Rebuild Everything

Imagine:

New Reporting System

needs historical data.

Traditional database:

Too late.

Event Sourcing:

Replay events.
Generate reports.

History becomes reusable.

Projections Are Just More Reducers

This is another concept that sounds scary.

A projection is simply:

A reducer that creates a view.

Example:

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

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

    return state
  }

Process events.

Build a customer report.

That's a projection.

CQRS Starts Making Sense

Most CQRS explanations make it sound mysterious.

Reality:

Commands
↓
Generate Events
↓
Reducers
↓
State

That's the heart of CQRS.

The terminology is harder than the concept.

Event Sourcing Meets RxJS

In the previous article we discussed:

scan()

Remember:

scan()
=
reduce()
+
time

Now imagine events arriving continuously.

Deposit 100

(wait)

Withdraw 25

(wait)

Deposit 50

Suddenly:

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

becomes Event Sourcing in real time.

Real World Example: Shopping Cart

Events:

Add Item
Add Item
Remove Item

Reducer:

(cart, event) =>
  nextCart

Replay events.

Get cart state.

Event Sourcing.

Real World Example: Inventory

Events:

Stock Added
Stock Removed
Stock Returned

Reducer:

(inventory, event) =>
  nextInventory

Replay.

Current stock.

Event Sourcing.

Real World Example: User Activity

Events:

Login
Purchase
Logout

Store events forever.

Build analytics later.

No extra tracking tables required.

Why Event Sourcing Feels Difficult

Because people usually start here:

Event Store
CQRS
Snapshots
Distributed Systems

Instead of here:

events.reduce(
  reducer,
  initialState
)

The second explanation is far easier.

Because that's the core idea.

Everything else is optimization.

The Problem With Event Sourcing

Let's be fair.

Event Sourcing is not free.

1. More Complexity

A CRUD application is usually simpler.

2. Data Migration Becomes Harder

Events are history.

Changing history is dangerous.

3. Event Design Matters

Poorly designed events become technical debt.

4. Learning Curve

Teams must understand the model.

5. Not Every System Needs It

A simple blog probably doesn't need Event Sourcing.

Pros Of Event Sourcing

1. Complete Audit History

Nothing is lost.

2. Time Travel

State at any point in time.

3. Easier Debugging

Replay events.

Reproduce bugs.

4. Flexible Reporting

Build projections later.

5. Natural Fit For Distributed Systems

Events scale surprisingly well.

The Real Lesson

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

It was about a pattern I already knew.

Current State
+
Event
=
Next State

Which is:

(state, event) =>
  nextState

Which is:

Reduce

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

The architecture becomes much less intimidating once you realize that.

And suddenly concepts like:

CQRS
Projections
Replay
Snapshots

start feeling like natural extensions rather than mysterious enterprise magic.

What's Next?

In the next article we'll discuss:

Why Functional Code Can Be Slower

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

Beautiful code
≠
Fast code

And understanding that tradeoff makes you a much better engineer.

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

scan() Is Reduce For Infinite Data

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

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

Maybe you've seen code like this:

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

And maybe you've thought:

Okay...

It accumulates stuff.

Seems useful.

Then you moved on.

I did too.

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

One more thing to memorize.

Then I realized something.

scan() isn't a special RxJS operator.

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

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

The Limitation Of reduce()

Let's start with something familiar.

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

console.log(total)

Output:

Simple.

The reducer processes:

and eventually produces:

But notice something important.

Reduce only works because:

The collection ends.

At some point:

Array Finished
↓
Emit Final Result

That is fundamental.

Reduce needs an ending.

What Happens When Data Never Ends?

Consider:

interval(1000)

Output:

When does it end?

Potentially never.

So if we tried:

reduce()

What would happen?

The answer:

Nothing.

Because reduce is waiting for completion.

And completion never arrives.

Enter scan()

RxJS introduced:

scan()

for exactly this problem.

Example:

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

Output:

Interesting.

Instead of waiting until the end:

scan()
emits every intermediate state.

Visualizing The Difference

Reduce:

Scan:

Every intermediate state becomes visible.

The Formula Is Identical

Reduce:

(accumulator, value) =>
  nextAccumulator

Scan:

(accumulator, value) =>
  nextAccumulator

Same function signature.

Same concept.

Different timing.

That is why I like describing scan as:

Reduce for infinite data.

The Hidden Relationship To Redux

This is where things get interesting.

Suppose:

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

    default:
      return state
  }
}

Sound familiar?

That's Redux.

Now imagine actions arriving over time.

INCREMENT
INCREMENT
INCREMENT

What happens?

0
↓
1
↓
2
↓
3

That's scan.

Literally.

Redux is conceptually a scan over actions.

State Management Is Just scan()

Let's build a tiny state store.

const actions$ = new Subject()

Reducer:

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

    default:
      return state
  }
}

Store:

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

Dispatch:

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

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

Output:

5
15

We just built reactive state management using scan.

Event Sourcing Is Also scan()

Consider a bank account.

Events:

Deposit 100
Deposit 50
Withdraw 25

Reducer:

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

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

Traditional:

events.reduce(
  accountReducer,
  0
)

Result:

Now imagine events arriving live.

Deposit 100
(wait)

Deposit 50
(wait)

Withdraw 25

Suddenly:

scan()

becomes the natural choice.

Event sourcing becomes a continuous reduction process.

Why scan() Feels Magical

Because it combines two powerful ideas.

First:

State

Second:

Time

The result:

State Evolution Over Time

Which is exactly what most applications are doing.

Real World Example: Shopping Cart

Actions:

Add Product
Add Product
Remove Product

Scan:

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

Output:

Cart Version 1
Cart Version 2
Cart Version 3

Every state change emitted automatically.

Real World Example: Live Analytics

Visitors arrive.

Visitor
Visitor
Visitor
Visitor

Scan:

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

Output:

1
2
3
4
5
...

Live metrics become trivial.

Real World Example: Game Score

Player scores:

10
20
50

Scan:

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

Output:

10
30
80

Perfect for dashboards.

Performance Considerations

A common misconception:

scan()
stores all previous values

It doesn't.

Normally:

Previous State
+
Current Value
=
New State

Only the accumulator survives.

Memory usage remains constant.

Which makes scan suitable for:

Live streams
WebSockets
Telemetry
Monitoring
Analytics

Why Most Developers Misunderstand scan()

Because they learn:

Operator Names

instead of:

Underlying Concepts

When you memorize:

scan()

it feels random.

When you realize:

scan()
=
reduce()
+
time

it becomes obvious.

Pros Of scan()

1. Perfect For Infinite Streams

Works where reduce cannot.

2. Great For State Management

Redux-like patterns emerge naturally.

3. Constant Memory Usage

Only current state is required.

4. Easy To Compose

Works beautifully with RxJS pipelines.

5. Foundation Of Reactive Architecture

Many reactive systems are built around scan.

Cons Of scan()

1. Can Be Misused

Not every stream needs accumulated state.

2. State Logic Can Become Complex

Large reducers become difficult to maintain.

3. Debugging Deep Pipelines Can Be Hard

Especially when multiple scans exist.

4. Requires Thinking In Streams

Which takes time to learn.

5. Easy To Confuse With reduce()

The names are similar.

The behavior is not.

The Real Lesson

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

Just like:

reduce

wasn't really about arrays.

And:

map

wasn't really about arrays either.

The real abstraction is:

Current State
+
New Value
=
Next State

Reduce applies that idea to finite collections.

Scan applies that idea to data that keeps arriving.

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

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

And that is usually the moment reactive programming finally clicks.

What's Next?

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

Event Sourcing Is Just Reduce Over Time

Because once you understand:

reduce()
scan()
state evolution

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

About The Author

Hi, I'm Amrish Khan.

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

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

Here's a detailed blog on Aruvix:

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

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

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

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

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

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.