Are you really talking about angular or is it more about rxjs/observables ?
Because the former is really hard to imagine with what you claim to be proficient in.
The reactive stuff from rxjs is another story though, few people I know really worked with any of the reactive libraries before and mostly everyone I know struggled with the concepts at first, no matter which language they were using them in
I'm absolutely fine with rx* and observables. I was an early (but very minimal) contributor to many of the rx* family of libraries, even. I basically adore the pattern.
But I didn't even get that far with it. I don't think I could even accurately describe what an angular component is.
Angular CLI is definitely the biggest cause of my confusions.
This really isn't a fair statement to make because Angular without RxJS and Observables is nothing. The core http library is based on observables. If you forego observables, you're using very little of what makes Angular useful.
IMO using Observables instead of Promises for most API-type HTTP calls causes more harm than good. i.e. if you pipe the observable into an async pipe in more than one place, it does more than one HTTP call. I find in Angular code having my services that do HTTP calls return Promises via .toPromise() is much cleaner, and enables async/await and try/catch. Also with Observables, you have to remember to unsubscribe if you manually subscribe to the call, implement OnDestroy, etc. No need to worry about that with Promises.
Observables are great for other things though, like debouncing input, timers, @Outputs, etc. where there might be more than one result produced. They're awkward compared to Promises for single-result futures.
Yeah, Angular uses RX Observables so terribly and its HTTP module in particular for using Observables as "heavy weight Promises" does so much injustice for the entire ecosystem. People using Angular treat Observable subscribe() like it is just a bad non-conforming Promise then() in nearly every project including examples baked into Angular's own awful documentation and many "Production" libraries out there. Those bad habits are just so entirely persistent across the ecosystem that you just about have to assume every dependency is a memory leak (including Angular team's own CDK and Material libraries!).
I've made PRs to things to push them to use .toPromise() at least when they want Promises.
I was angry for days when I finally discovered where they buried AsyncPipe in the documentation (letting the template language automatically manage subscribe/unsubscribe rather than all bad habits of every component for themself and all the boiler plate for OnDestroy). Something like that should have been the default in the template binding language, not hidden away in a closet in the basement of the documentation. But they buried it because they never really committed to RxJS in the first place (such a huge dependency to half ass) and would have to teach things like shareReplay and hot versus cold Observables if they were to recommend AsyncPipe more strongly and/or make it the default it deserves to be (if they were actually committed to RxJS/Observables).
(React's been on a multi-year journey to towards Suspense/Concurrency and waiting for some updates together before scheduling them/Scheduling some DOM updates on requestAnimationFrame versus others more immediately that Angular could have done it so easily with a couple RxJS operators at template binding time if it had been intelligently designed with good defaults! It's amazing how hard they have instead worked to sabotage everything about the RxJS ecosystem in Angular.)
There's too many leaky boat escape hatches from RxJS and the few core libraries that make use of RxJS make use of it so poorly as either heavy-weight Promises or heavy-weight Node Classic Event Emitters (and bleeding Subjects/BehaviorSubjects everywhere across API boundaries which are their own violations of RxJS best practices). As an RxJS fan going into Angular it just makes me weep.
Thats true to a degree, but the distinction makes sense to me because angular is not the only project using reactive concepts.
RxJS is just one of the implementations [1] and people that haven't grokked it would struggle with other project utilizing it as well - even if its a React frontend, Go backend etc.
(and as others have pointed out: angular should not be considered a poster-child of reactive programming. they made it work somehow, but its really easy to get memory leaks even if you're just copy-pasting code from the official angular docs)
One of my projects for work is RxJava and I’ll never touch anything Rx again. I don’t see any benefit it brings outside of making your project and control flow convoluted.
That's unfortunate because reactive programming shines when you have continuous data flows and want to run pipelines against them; whether that's clicks, websocket events, queue items, etc.
Java streams don’t infest your project. They also don’t throw away the error system of the language. They are also leagues more maintainable than a reactive project.
Because the former is really hard to imagine with what you claim to be proficient in.
The reactive stuff from rxjs is another story though, few people I know really worked with any of the reactive libraries before and mostly everyone I know struggled with the concepts at first, no matter which language they were using them in