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

[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.