Discussion on: 🙅‍♂️ Stop trying to learn RxJS

[Andrei Gatej]

rxjs's fatal flaw in this regard is the Observable's influence over the rxjs/operators api

An operator is a function which returns a function whose single argument is an Observable and whose return type is also an Observable. So, the Observable is just a fundamental unit of the library. If you'd spend some time reading the sources, you should see that this akin to that Node class which you use to build a linked list.

For example, rubico has only one function map while rxjs has concatMap, exhaustMap, flatMap, mergeMap, and switchMap to name a few.

These operators surely exist with a purpose. I find it very nice that rxjs has these options, because they are frequently met when solving problems.

it just projects each element of whatever collection is passed to it onto another collection of the same type.

rjxs' map might be the same as rubico's map, but mergeMap is very useful when you're dealing with another observable(inner observable) and you need that value to be passed along in the stream.

In this regard, rubico is more concise because it defines predictable behavior for a multitude of types (Array, Set, Map, ...) including the observable (v7 with @@asyncIterator).

This makes me think that you didn't not carefully read on what observables are and what problems do they solve.

functionally - I meant functionally as in the functional style, for example

I find this more intuitiveL

of(1,2,3).pipe(a(), b()).subscribe()

than this:

pipe([
 a(),
 b(),
 c(),
])([1, 2, 3])

because in the first snippet you can clearly understand which is the source and which is the consumer.

rubico code will lead to less questions because there's less magic happening.

IMHO, less magic is not an advantage. As long as the magic is abstracted away from the dev, and it magically works, I see no problem in this.

I cannot say the same for RxJS when they export functions in their 'rxjs/operators' API with names like ...

I'd that these operators exist with a purpose. Yes, at first bufferWhen, buffer and bufferToggle might seem not intuitive, but after understanding their purpose, everything should make sense. Not to mention how many benefits you'd get out of reading their source code.

but async iterables right now are causing problems ...

Here's an article which describes a possible use case for them(testing). I don't see a breaking change, it's just another feature.

If you ask me, RxJS is a sinking ship

I would disagree since it's used by important technologies, such as angular, ngrx etc...
I think you would benefit a lot if you started contributing to rxjs(by writing articles, SO, helping other people). I just see no point in going against this with another library, because rxjs is really great. It also has a lot more features: testing your own observables using marble tests, multicasting, adding teardown logic.

[Richard Tong]

Andrei, I oppose rxjs because the ideology is weak. 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.

RxJS is giving me PTSD because all I see is what. RxJS is a sinking ship because the spec is moving on without them: async iterables are 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 /comfy/ 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);

Andrei, I don't think you actually like things that magically work because you are someone who reads source code. Isn't it core to you to understand the way something works by studying its source line by line? You've done that quite a bit for RxJS. I'm not really sure what they did to deserve that. I see your passion, that's why I want you to use and contribute to rubico. Stop wasting your talent on a sinking ship. The project is just me right now, but there's a lot of interesting stuff I've spec'd out. Really, I would love to have your help on this.

[Deanfei]

Because you don't actually know rxjs in depth.