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:

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.

推荐订阅源

DEV Community

Start With Something Familiar

Now Imagine The Values Arrive Over Time

Enter Observables

map() Works Exactly The Same

filter() Works Exactly The Same

scan() Is Reduce For Infinite Data

flatMap Exists Here Too

switchMap, mergeMap and concatMap

mergeMap

concatMap

switchMap

Why RxJS Feels Hard

Real World Example: Search Autocomplete

Real World Example: WebSocket Streams

Performance Considerations

Pros Of Thinking This Way

1. RxJS Becomes Easier

2. Reuse Existing Knowledge

3. Better Mental Models

4. Easier Debugging

5. Strong Foundation For Reactive Programming

Cons Of The Analogy

1. Arrays Are Finite

2. Time Changes Everything

3. Concurrency Doesn't Exist In Arrays

4. Error Handling Differs

5. The Analogy Eventually Breaks

The Real Lesson

What's Next?

About The Author