RxJS’s Pros And Cons: Is It A Holy Grail Or A Nuisance?

BlogUPDATED ON January 14, 2020

RXjs Pros and Cons

RxJS: A Fundamental Library That Stands Out

RxJS is the fundamental library for a large number of packages, including such widespread and advanced frameworks as Angular and NestJS. It features a whole rundown of handy operators that you can leverage to make your code more efficient, faster, and snappier! So, what makes this library a good pick? Let’s dig deeper and take a closer look at RxJS to define what makes it stand out from the crowd!

RxJS is one of the key libraries each modern JavaScript developer should have in his kit. It’s a library that helps developers simplify the process of composing callback-based or asynchronous code. At the same time, it also has the potential to help you make your applications even more performant and efficient thanks to a wide array of effective operators featured in it. Keeping all this in mind, it’s fair to say that RxJS is the de-facto basis of any reactive application.

Such popular frameworks as Angular and NestJS actively use the concept of reactive programming. Thus, their architects’ choice of RxJS is completely justified. However, is it really that good for everyone? Let’s take a closer look at this library’s most significant pros and downsides to figure out what makes RxJS so cool!

RxJS Pros: Strong Sides That Make This Library Awesome

Today, RxJS is among the hottest libraries used in the world of web development. It is a functional and powerful tool integrated into a wide range of frameworks. In a broader sense, RxJS makes reactive programming more appealing and approachable.

Since its introduction, RxJS has been evolving rapidly. Even now, it keeps gaining momentum. Here are some numbers that clearly indicate its huge popularity:

  • At the moment of work on this article, this library has 2.4 million (!) dependent repositories on GitHub;
  • More than 16 thousands of dependent packages on NPM;
  • The number of weekly downloads from NPM has exceeded 14 million!

The number of dependent repositories, dependent packages, and weekly downloads of RxJS is impressive. Now, what is the reason for such success? Let’s look closer at the key strong sides to find the answer.

[text_on_the_background title=”Do You Want to Build More Dynamic, Interactive
and Real-time Applications? “]We’d be Delighted to Help! Ask Us for a FREE Consultation HERE[/text_on_the_background]

Solid story

Without any doubt, the enormous success of RxJS we observe today is a result of many years of hard work, dedication, and thousands of improvements and fixes. According to GitHub, the first release in the current repository appeared in 2015.


Date when RxJS first released on GitHub (in the new repository)


Nevertheless, its development started even earlier – back in 2013. Cool!


Date when RxJS first released on GitHub (in the old repository)


We can assume that throughout the long history of the project it in total got around 6000 commits from 500 developers. That’s a huge contribution!

High-quality API 

Thanks to the graceful API, RxJS makes it easy to describe a complex stream of data more compactly. To make it possible it comes with a comprehensive kit of standard entities (Subjects, Observables, and operators), which undertake all the hard work on themselves. This way, the complexity of the process is being hidden from a developer, allowing him to focus more on the product’s logic. 

What does this mean for react developers? Having enough experience, it becomes possible to significantly simplify the workflow with asynchronous data flows, for example, with UI events, HTTP requests or WebSocket messaging. Respectively, this allows developers to save plenty of time and effort for other tasks.

RxJS usage example:


RxJS’s API stability is worth to be admitted separately – it’s on top! RxJS’s developers tend to save backward compatibility as long as possible, softly taking users to need to move from deprecated APIs to the new one. They provide the community with tools and instructions for semi-automated migration to a new major version.

Good optimization and memory leaks protection

Considering the solid background of RxJS, developers can stay rest assured about the high quality of optimization. Thanks to hard work, plenty of not-such-obvious problems have already been solved. In particular, thanks to the participation of many developers in the process of testing and enhancing of this library, problems associated with memory leaks have already been detected and handled properly.

RxJS’s memory leaks issues stats



Despite the comprehensive kit of standard operators, sometimes it may be necessary to eject repeating algorithms into new RxJS operators. This can be easily achieved by following the official reference. YouTube tutorials also explain it well, for example, this video:

Small footprint 

RxJS is known for its high-quality optimization and modular architecture. Both characteristics also ensure a smaller footprint, meaning the production bundle will only contain those parts that are really used.

No third-party dependencies

RxJS is a self-sufficient library, which doesn’t pull tons of dependencies. Unlike many other libraries, it doesn’t rely that much on third-party dependencies. Therefore, it’s influence on a project’s size is optimal and depends on how much of it is really used.

RxJS dependencies

Currently, according to NPM, RxJS only has one dependency – tslib. What this single dependency really does is providing Typescript support.

Another benefit ensured by the lack of dependencies is that it is fairly easy to adopt the RxJS itself as a dependency for other packages, for example, API SDKs, utility packages, server-side programs, webhook implementations, and front-end event managers as well.

Large and responsive community

One of the largest benefits of this library is its diversified and large community. Thanks to having such a responsive community, RxJS grows even stronger and more popular. Participants of the community help each other to handle the problems and questions on StackOverflow and Gitter.


Although reactive programming and RxJS are generally hard to master, overcoming this hefty learning curve gets easy thanks to the library’s massive documentation base it has. At the official website, you can find plenty of official documentation, as well as community-driven resources that aim to provide a more deep explanation of concepts, best practices, patterns, and examples, helping users to boost their theoretical knowledge and skills with ease.

Regular updates

Last, but most certainly not least important benefit of this package is that it is being properly maintained. Its updates on GitHub pop up quite regularly, making it a pretty reliable codebase. The current version 7.0 was released not so long ago on 18 September 2019.

One thing that is even more important than consistency of updates is that every new release brings in more improvement to the overall work of RxJS, making it even more powerful, performant, reliable, and convenient.

RxJS Cons: Week Sides To Keep In Mind

There are quite a few advantages to this library that make it simply great for various purposes, there are also a few downsides that have to be kept in mind:

Data immutability required

First of all, everyone should clearly understand that the need for data immutability in RxJS is not exactly a requirement, but rather a concept that came from functional programming.

Reactive programming has many pitfalls by itself. And when this paradigm is going to be applied to JavaScript, there might appear certain problems caused by language features. In particular, the lack of native support of data immutability in JavaScript may force a developer to invent third-party libraries and tricky approaches.

The reactive paradigm works most optimal in couple with functional programming. Such symbiosis is neither new or rare in the world of programming and it is called “functional reactive programming” (or short FRP). It has a bunch of significant advantages such as ease of creation multithreading applications and effective consumption of computing resources. But like many paradigms it’s not a “silver bullet”.

Therefore, one way or another, modern applications based on the symbiosis of object-oriented, functional, and reactive programming are taking the best parts of all paradigms.

Complexity of testing

It’s worth noting that due to the specific features of reactive programming, a developer needs to master an array of additional tools and techniques to test his RxJS code.

Since you are dealing here with asynchronous code, there is no way to get around without some extra tools. In particular, we are talking about Marble diagrams – a special testing tool developed by the RxJS team. The key goal of this tool is to assert data streams work properly. Sadly, the need to use additional tools does make the process of texting more complicated. As a matter of fact, syntax of Marble diagrams is pretty tricky, which means that developers will have an additional learning curve here.


Anatomy of Marble diagram (source)


Strict typing issues

As was already mentioned, the only dependency of RxJS is tslib, which provides you with Typescript support. Typescript definitely provides a set of advantages such as strong typing, autocomplete, etc. However, at the moment, users can notice some wrong usage of access modifiers (private/public), which makes internal methods accessible from the outside. 

Here is a clear example of this issue based on actual implementation (method normally must be hidden with a private or protected modifier):


export class Observable<T> { ... /** @internal This is an internal implementation detail, do not use. */ _subscribe(subscriber: Subscriber<any>): TeardownLogic { const { source } = this; return source && source.subscribe(subscriber); } ... }


In a perfect world, access to sensitive details of internal implementation in RxJS observable has to be restricted, especially in classes that are part of public API. However, they are not always restricted, which is a big downside.

(Possible) operators’ names conflict with other imported functions

We have to admit that the compactness of the RxJS code is a significant design achievement. However, there is another notable issue obscuring the benefit of compactness. In the code, short names of operators (like map, filter, reduce) may conflict with other function names from other packages, for example lodash. Here’s a small example:


import { filter, map } from 'rxjs/operators';
import { filter } from 'lodash'; // Error. Duplicate imports.


Of course, such conflicts, though not too appealing, can be solved with aliases for imported methods. It does give certain inconvenience, which makes it a weak side of this library.


import { filter, map } from 'rxjs/operators';
import { filter as _filter } from 'lodash'; // Ok, imports have different names


Long stack traces

During the process of debugging, a developer may face the need to explore the stack trace of RxJS which may look huge. That’s when you may stumble in a single question: why is it so complex?!

RxJS is built on FP principles including functional composition, partial execution, and delegation. Add to this the fact that data is passed through the stream and processed by operators, which delegates some job to given functions. It turns out that the stream RxJS stream is a complex composite system. That’s why stack traces are so unnaturally long.

Although long stack traces can be pretty overwhelming and inconvenient, the good news is that we are expecting this to change sometime soon. RxJS dev team listens to the community and takes possible measures to improve the situation.


Wrapping up everything discussed above, we have to say that the appearance of the reactive RxJS concept in the JavaScript ecosystem was pretty predictable. We expected something like this to happen simply because FRP is a mature paradigm that plays well with JavaScript features. Since its release in 2015, this project has been gaining momentum and eventually shaped other popular libraries and frameworks such as Angular and NestJS.

The model of operating the data streams offered by RxJS turned out to be successful and highly demanded. This encouraged the community to demand that this functionality would be implemented in the ECMAScript standard. Such a decision will definitely become a big step forward in the platform’s evolution, as happened with adding Promise to the standard.

So, is RxJS a holy grail or a nuisance for a developer? One thing we can say for sure is that this library is a solid solution for more convenient reactive programming. Thus, it is definitely worth attention and learning. Besides, the future promises an increasing involvement of this project in the developed products, which makes it even more vital to adopt it!

However, what if you want to get around this hefty learning curve? Then you might need a bit of pro help and that’s what K&C is here for! We are a react development agency with over 20 years of experience in the field of digital transformation, which delivers the hottest tech talents to your service. We are committed to excellence and trusted all over Europe, so don’t hesitate and Entrust Your Digital Success to Us!

Let’s Get in Touch ▶ HERE and discuss the specifics of your project right now!

Related Service

Angular Development and Migration Services

Read more >

Software Development For Startups

Read more >