RxJS Is Just Arrays Over Time

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:

10

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:

1
2
3
4

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:

10

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:

0
1
3
6
10
15
21
...

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.