Notes on ReactiveX
I have fallen down a reactive programming rabbit hole. This all started because I wanted to learn modern web app development. There are many frameworks to choose from, and I decided to start with Angular. Web development is an inherently asynchronous endeavor, and one of the major tools in Angular's toolbox for managing asynchronous data flow is a library called RxJS. Official RxJS documentation was quite unfriendly to beginners, so I looked around and found a website called "Learn RxJS" which turned out to be an extended pitch for a paid course. I'm not upset at the author for that, I'm just not ready to spend that kind of money. For curiosity's sake, I looked at the author's Twitter stream and felt like I stumbled into a clubhouse where everyone in the clique is into something I don't understand.
Seeing a larger world around reactive programming made me realize RxJS isn't a JavaScript library floating in isolation, it is an implementation of an idea bigger than a web framework (Angular) or even a programming language (JavaScript). I was one click away from this fact ever since I started looking at RxJS, but I didn't notice. Its source code repository is at https://github.com/ReactiveX/rxjs. Meaning it is a project of an organization called ReactiveX. Looking at their list of repositories under https://github.com/ReactiveX shows multiple projects with the Rx prefix, each corresponding to a language (RxJava) or a platform (RxAndroid) From there I found the ReactiveX website at https://reactivex.io/
In hindsight it made sense why information on https://rxjs.dev was so terse and assumed the reader already knew the basics. That site was mainly focused on JavaScript specific issues, not general concepts and overview. General background and introduction information would only overlap with content on ReactiveX. Which, by the way, seems to have a Java-centric voice. I inferred RxJava was the first ReactiveX project and RxJS came sometime afterwards.
Reading ReactiveX Introduction page, I felt it is much better written for beginner friendliness. Or maybe it's just the fact I've been reading similar words written by different people enough times for ideas to finally sink in. And while I feel I better understand goals of this project, I wouldn't call myself a convert of the faith. I've seen enough shiny new toys to immediately spot some potential problems. For example, one part of the introduction tells us reactive programming meant we can focus on abstract concepts and its implementation details would not matter.

That may be true in perfect theory land, but I've seen this claim before. I know it falls over as soon as I have to debug a problem. At which point implementation details matter quite a lot! When something crashes in the middle of the library, and I have no idea how my code relates to the crash stack I see in the debugger, it's gonna be a long day.
I will admit reactive programming is an intriguing concept and, as I saw earlier, some people behind the Angular framework are pushing for Angular to become more reactive. To their credit, reactive programming is a concept that has outlasted some lesser flash-in-the-pan ideas. Looking at Wikipedia, ReactiveX has been kicking around for over a decade. However, reactive programming is still early on its road to maturity. That particular Wikipedia page was marked with "This article has multiple issues" as did the page on reactive programming in general.
For my immediate future, I believe I understand it well enough to stumble through its usage in Angular web application framework. It'll be a long time before I can become a skilled craftsman at RxJS, but at least I would no longer become bewildered when I see code using it. This is good enough for me to get back to learning Angular.