🙅‍♂️ Stop trying to learn RxJS

If you have any interest in RxJS, this article is for you. If you have no idea what RxJS is, I advise you not to worry about it and check out rubico: a new asynchronous functional programming library authored by yours truly.

At the highest level, the relationship between rubico and RxJS is characterized by convergent evolution, that is

the independent evolution of similar features in species of different periods or epochs in time

Emphasis on different periods in time. One period without async iterables, and one period in the future when they're a thing.

For the longest time, I had at best a hazy idea of RxJS. In fact, My first encounter with the reactive paradigm was through talks of RxSwift with a pal of mine from an old job. It wasn't until after I had heard numerous comparisons of RxJS to rubico that I really hunkered down and dove in.

This set me off to learn RxJS, and I'll be honest, I was disappointed. At no point in either of the release branches or the main site do they talk about why RxJS. It always just starts with what. It's like reading a research paper that starts with "hey guys, here's our research! it's important because we say so!". There needs to be a reason why the research is being done, otherwise no one will care. Just take a look at any TC39 proposal, it always starts with why. For RxJS, on the other hand, the current first time experience on the site is

1. Introduction - "RxJS is..." <- this is what
2. Example 1 - RxJS is powerful because you can use pure functions and pure functions are less error prone
3. Example 2 - RxJS has operators for flow control
4. Example 3 - RxJS has operators to transform values in RxJS observables
5. Observables - "Observables are..."

They never answered my first question: why is this here in the first place? On rubico it's

1. Motivation - Why is this here? Because When I was still writing in the imperative style, I got tired of looking at my own code. I created this library for myself, so I can write in a style I love.
2. Principles - What is the highest level of what I want from this library? Simple code; don't care about async; and simple, composable, and performant transformations (on all collections)
3. rubico follows these principles to grant you freedom
4. Introduction - take the tour, read the docs
5. Examples...

Why should always precede what. Otherwise, your product will run in circles. I experienced this first hand at my previous company.

From the creator of RxJS

RxJS isn't easy to learn. But the alternative lessons you'll learn if you try to roll your own streaming paradigm for your app with a lot of streaming data will be much, much more painful and costly.

I mean I can't predict the future, but I agree. I trust that the creator of RxJS speaks from experience. There will probably be a lot of pain rolling my own streaming paradigm, which is why I'm not going to roll my own streaming paradigm. In fact, I'm not going to invent another paradigm at all; I'm just going to borrow the existing functional paradigm and polish it for JavaScript.

...and at the end of the day, anything you create will just be another flavor of Observable without the safety guarantees.

Does the async iterable count as another flavor of the Observable? It seems the spec is leaving RxJS behind when async iterables are already here to stay, while Observables are a stage 1 proposal. Observables are not async iterables, but they compete for the same streaming data model. Async Iterables were created partly because of the pains of NodeJS streams, which are analogs to RxJS Observables. Part of these pains are backpressure problems, from RxJS creator:

Since observables are all push-based, there are memory and back pressure concerns unless you use a lossy strategy to adapt the incoming values into the asyncIterator. I have a proposal to add this as a feature to RxJS, but it's not without it's drawbacks.

^ that turned into this library.

You can see excitement for async iterable streams in this issue in the streams spec. Read it for the good vibes. Here's a nice summary from domenic

It's starting to feel a bit magic though....

Really, I'm just against spaghetti code. You'll get spaghetti if you model streams as a push datatype like Observable. You'll get worry free code if you model streams as async iterables. Finally, you'll get magical code if you feed an async iterable to rubico's transform. Check out this functional style async iterable webserver with rubico and deno

const s = serve({ port: 8001 });
console.log("http://localhost:8001/");
transform(map(req => {
  req.respond({ body: "Hello World\n" });
}), null)(s);

Here's my abridged list of features and roadblocks comparing RxJS and rubico. I encourage you to voice any additions or subtractions in the comments.

I'm telling you to stop learning and using RxJS because rubico is that much better at doing what RxJS is trying to do. Don't get me wrong, rubico is easy to learn, but it takes time and hard work to master. I urge you to put your time to better use: take the tour.