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

concisely - rxjs's fatal flaw in this regard is the Observable's influence over the rxjs/operators api. For example, rubico has only one function map while rxjs has concatMap, exhaustMap, flatMap, mergeMap, and switchMap to name a few. The difference between these map functions is in the behavior on the underlying Observable. rubico does not have the issue of having to deal with an underlying Observable; it just projects each element of whatever collection is passed to it onto another collection of the same type. 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).

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

Observable.of(1, 2, 3)
  .pipe(
    filter(x => x % 2 === 1),
    map(x => x + x),
  )
  .subscribe(x => console.log(x))

is more object oriented via .pipe and .subscribe than the pure functional approach with rubico

pipe([
  filter(x => x % 2 === 1),
  map(x => x + x),
  map(x => console.log(x)),
])([1, 2, 3])

Notice how with rubico, there are only functions except for the last input array. The power behind rubico is that the input is last instead of first. This is powerful because it doesn't lock you in to one type of collection; you have the freedom to transform any collection with rubico (including the v7 observable).

readably - I know I sorta dug myself into the subjective hole with this one, but please hear me out. If we consider readable from the perspective of how many more people can read your code, rubico code will lead to less questions because there's less magic happening. rubico's functional purity and no special data types means you know exactly what is going to happen to your array if you map over it. In fact, please take a look at the implementation for map; there's really not a lot to it. It's just map that works on a lot of the built-in types. rubico also did not invent it's own paradigm, it just follows the functional one. In that regard, much of rubico's API naming is borrowed from the JavaScript language, popular JavaScript libraries, and even other languages. For example, RxJS, ramda, rubico, bash, this proposal, and scala all have the concept of a pipe whereby you chain functions together. Every single one of rubico's method names are derived in this way. Why? Because I wanted to make the code you write with rubico look as familiar and intuitive as possible. I cannot say the same for RxJS when they export functions in their 'rxjs/operators' API with names like bufferWhen, mapTo, switchMap, switchMapTo, etc. This API is questionable, to say the least, especially when there are whole articles dedicated to distinguishing the differences between some of these names.

It's been an uphill battle to push out rubico for exactly the reasons you mention: RxJS has an entire ecosystem written around it and is way older and more mature. I think the difference here is rubico avoids many of the issues of RxJS by design. For example, you can consume async iterables with rubico's transform, but async iterables right now are causing problems for RxJS because they undermine so much of the functionality of Observables. From an API consumer's perspective (aka you and me), async iterables and observables are effectively the same; just attach a function to a stream of events

Observable.of(1, 2, 3)
  .pipe(
    filter(x => x % 2 === 1),
    map(x => x + x),
  )
  .subscribe(x => console.log(x)) // RxJS

const myAsyncIterable = async function*() { yield 1; yield 2; yield 3; }

transform(pipe([
  filter(x => x % 2 === 1),
  map(x => x + x),
  map(x => console.log(x)),
]), [])(myAsyncIterable()) // rubico

This problem with async iterables has motivated ben to publish the library in his tweet that provides strategies for converting Observables into async iterables. More details in this pr and this issue. If you ask me, RxJS is a sinking ship. Please come over to rubico.