5 ms·

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 i

by y4mi 5y ago

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

vips7L 5y ago
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.
- halfmatthalfcat 5y ago
  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.
- Offpics 5y ago
  I work with rxjs and its a breeze to work with. My data flow got only complicated after introducing redux-observable.
- Jenk 5y ago
  document.addEventListener("something", event => { /* blah */ }); is no different. Nor are Java streams or .NET linq.
  - vips7L 5y ago
    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. Ignoring the maintenance issues, reactive applications do not yield better performance on realistic I/O-bound workloads: https://julien.ponge.org/blog/publication-performance-and-costs-of-reactive-programming-libraries-in-java/ https://julien.ponge.org/blog/publication-performance-and-co... So all you end up with is less maintainable code and more developer headache.
88913527 5y ago
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.
- paulirwin 5y ago
  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.
  - WorldMaker 5y ago
    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.
Jenk 5y ago
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.

by y4mi 5y ago

vips7L 5y ago

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.

halfmatthalfcat 5y ago
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.
Offpics 5y ago
I work with rxjs and its a breeze to work with. My data flow got only complicated after introducing redux-observable.
Jenk 5y ago
document.addEventListener("something", event => { /* blah */ }); is no different. Nor are Java streams or .NET linq.
- vips7L 5y ago
  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. Ignoring the maintenance issues, reactive applications do not yield better performance on realistic I/O-bound workloads: https://julien.ponge.org/blog/publication-performance-and-costs-of-reactive-programming-libraries-in-java/ https://julien.ponge.org/blog/publication-performance-and-co... So all you end up with is less maintainable code and more developer headache.

88913527 5y ago

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.

paulirwin 5y ago
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.
- WorldMaker 5y ago
  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.

Jenk 5y ago

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.