YouTube video for this article
Signals and fine-grained reactivity are very popular right now. In the last month, both Preact and Qwik announced s...
For further actions, you may consider blocking this person and/or reporting abuse
React hooks, Vue reactivity, Svelte stores, SolidJS signals, all of these pale in comparison to RxJS. But I think for most people RxJS just goes over their head.
mapis about the only thing they can understand. Then its back to writing imperative code, subscribing to observables imperatively, nesting subscriptions etc. I think signals are deceptively simple at first glance but after a while you end up with a hundred "use" functions just to do what rxjs does out of the box.It really is disappointing to hear that Angular team sees RxJS as something of an appendage and not a core feature of Angular.
Exactly my point. The R.O.I of learning RxJs is very high for long term. Maintaining asyncronous code is considered hard but after having fundamental knowledge of RxJs it is like a cake. RxJs is very underrated and it can be not only used on FE but also on BE such as RxJava which is quite popular too. If people are lazy to invest 2-3 weeks for RxJs fundamentals then what type of developers they are.
I spent 60 hours in a week in 2017 diving deep into RxJS, and reactivity basically clicked for me after that. Since then I've been frustrated with other people's resistance with it. However, I think it's more productive to frame it as a change in habits that's required. Easily changing habits is a good skill, but there are some good developers who have never dived into RxJS to appreciate the declarative mindset. So I don't automatically think devs who hate RxJS are bad developers. I just think they haven't seen a use case that convinced them to give it enough effort, and when they do (and they will eventually), they will be able to change their mindset.
I had done the same, spent 10s/100s of hours learning RxJS, playing with it, testing it, fighting with it etc. It made sense afterwards and I loved it but there aren't many people who code/learn in their spare time.
Most people do a "hello-world" angular tutorial, search for a job and work 9-6. As soon as it hits 6 they stop working, stop coding and stop learning and the only time they progress is what they read on their job.
I know it's frustrating that people aren't as passionate but most people won't spend 60 hours learning RxJS and then you just have a codebase that alienates everyone (at least the complex chains). The subscribes in subscribes never stop appearing in PRs and I'll continuously suggest how to do it properly.
My biggest difficulty when learning RxJS was that you basically have to transform everything into async (which makes sense) but I can only imagine how hard that is for everyone else. I spent way too much time trying to avoid BehaviorSubjects because it's bad practise and now everything is one, because it's 100x easier for me and everyone else when I can just push values in and get them out syncronously.
Maybe it's a paradigm worth teaching the next generation of programmers, so they at least enter the job market with it.
RxJS makes it easy to describe complexity in code. That's a trap, don't fall for it. You'll be easily misguided into adding complexity that is not even necessary. There might be cases complex enough to warrant the use of RxJS, but many of the cases that seem like they do are merely not understood well enough to resolve the complexity outside of the code.
You could say that about JavaScript. It's not the point of RxJS though. I hope you read the article before writing this comment.
Edit: I am in favor of avoiding unnecessary complexity though.
It's a bit like with RegExp: if you learn to master RegExp, you tend to overuse it, because they are so powerful. The same is true for RxJS. Once you finally understood it, you might be prone to overuse it, even if the problem does not warrant its use. I really hope that I can do without RxJS most of the time, because its usage implies a higher level of complexity than might be necessary, or worse, that is warranted (and then, I might be solving the wrong problem).
I don't care what the complexity is. That doesn't matter. Reactive code is cleaner than imperative code. I'll use RxJS if something needs to be dynamic and synchronous reactivity isn't enough for it and there are no framework-native declarative solutions (like a debounce hook).
If you still think RxJS is about complexity, give me an example of what you're talking about where RxJS makes something inherently more complex than an alternative.
I should have been more clear. RxJS is obviously about creating, managing and consuming async data - but, and that's my point - allows to easily encode complexity into your solutions using it.
If a problem is too complex to be solved with framwrok-native or tried and tested primitives, it is maybe too complex and needs to be simplified instead of throwing RxJS at it without prior consideration. That's all I meant.
Okay. I haven't had that problem.
Thanks Mike, I've read this article right after "I changed my mind. Angular needs a reactive primitive" one, and I like this one a lot more.
I understand everything you write in that one, but I'm still not convinced those problems can't be solved by extending over RxJS, even adding more "primitives" to it along with Observables, Subjects, BehaviorSubjects etc.
I wonder what RxJS team thinks about this "trend".
Very interesting; thanks for sharing. What's the references that the chart of compatibilites is based on? Your own tests against the 114 operators?
It isn't based on any objective data, just what my subjective experience of using observables with these frameworks has been. I'm interested if people will disagree, but I don't think they will, except maybe putting SolidJS above Svelte for some frustrating corner case in Svelte that I wasn't aware about because I have the least experience in Svelte.