The State of Reactive in JS: A Practical Review of FRP Libraries

The article was born from this response to StackOverflow and developed into a blog post ( in English ), but I think it has not lost its relevance.

Now a lot of noise around Reactive Programming. I spent some time studying this discipline applicable to JavaScript and Node.js and put my opinion on the most interesting libraries in my opinion.

Rxjs

This is a kind of benchmark - the emergence of Reactive Extensions for .net, in a sense, created this discipline.

Pros:

• Documentation and a large community ( > 15,000 stars on Github , > 3073 SO tags );
• This is a library from the Rx * family, which means it uses the same interface. Practically, this means that sometimes you can watch examples from RxJava and the original Reactive Extensions;
• There are primitives for almost all occasions;
• There is a backpressure ( here you can read what it is );
• There is one book for this library.

Cons:

• Sometimes it looks like "matan". Documentation resembles an abyss - it is not clear how to pull it all over your head?
• Implemented by guys with Java in their head (love for a large number of abstractions, idiomatics from Java / .Net, sometimes strange signatures). It's not that bad, just some things look strange in JS ( Scheduler example - I still don’t understand why all this is necessary in a single-thread environment). Hence the desire to write on TypeScript

Bacon.js

Once a fashionable library for hipsters - now everyone has forgotten
')

Pros

• Good documentation and good examples from the community (for example, Snake game );
• Almost all primitives from Rx * are implemented;
• Implemented at first very for JS and JS with the background;
• IMHO, it is very easy to start just walking through examples and documentation.

Cons

• No backpressure - let's just forget about backend development

Highland.js

Caolan Library - by async

Pros:

• It was immediately written for JS / Node.js by the guys who wrote something big on them and love the language / platform - which means JS-ia idiomatics and Node.js in their head (see the next paragraph);
• Built on top of Node.js Stream , this provided the library with a small size. In addition, it’s subjective, it’s so much easier to think about it: we have stream A, we do something with it and pipe it in stream B (here’s my article, with an example );
• backpressure - And as far as I understand, you didn’t have to write anything with your hands, everything is already in the Node.js Stream.

Cons:

• Weak documentation is already better and lack of examples. For examples you’ll have to go to Rx or Bacon - get over it;
• Lack of many primitives. Not that they are difficult to implement with their hands, but still. Example .interval and .combineLatest;
• Very subjective: Phlegmatic community - they write themselves, they get high, they don't lead to expansion.

Instead of the total

Because of the lack of reasonable examples, you will have to look at all these libraries, Rx * is so accurate. IMHO, the most correct Highland - the people who wrote it, understand the idioms of the platform and love it. The most “mature” RxJS - it was still “angled” in Angular, hype-guaranteed.

Hint: If you need to ask something on StackOverflow, translate RxJS- “dialect” right away, then you are more likely to answer.