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(...)

or

Array.flatMap(...)

or

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:

[

  101,

  102,

  103

]

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(...)

or

Array.flatMap(...)

or

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.