3 ms·

To rephrase a quip, I have found often that RxJS and similar tooling is the worst way to get correct behavior... except for all the others. More than once I h

To rephrase a quip, I have found often that RxJS and similar tooling is the worst way to get correct behavior... except for all the others. More than once I have set down a path to avoid RxJS, because of the complexity of explaining it and bringing a new developer up to speed... and ended up writing more code and having more difficulty producing correct results. My context is in web applications, SPAs. Typically with Angular, but I've used many tools in this space, including React, Redux, Cycle (which has its own Rx-like library), etc. The tricky part in all this is pervasive asynchronicity. Here's an example. Looking back at the AngularJS era, most of the applications I have seen (including review of many of our big customers applications) have incorrect behavior in the case of servers with jittery response time. It is quite easy to make an event handler load some data, and miss the fact that the data arrives in a different order than it was requested. Very easy to avoid with RxJS. If anyone's interested in this bit, here's a video explaining the merit of RxJS even with AngularJS 1.x, before the adoption of RxJS in Angular 2+. https://www.youtube.com/watch?v=XY9VPrKuJaA https://www.youtube.com/watch?v=XY9VPrKuJaA

dfee 9y ago
I "learned" RxPy in a couple hours yesterday (a 3rd party lib I'm using has an interface that requires me to use them), and I figure I'll share a bit about my experience: 1) the documentation is supremely lacking (subjects aren't even mentioned in the RxPy repo https://github.com/ReactiveX/RxPY https://github.com/ReactiveX/RxPY) 2) the generic documentation points to language specific documentation – that's 80% just "TBD" (http://reactivex.io/documentation/subject.html http://reactivex.io/documentation/subject.html) 3) it's actually quite simple once you figure out it's just code level pub/sub with a new naming convention. 4) there seem to be some opinionated perspectives around using it in the community, though largely from a JS perspective (look into "should I use subjects"). Despite those flaws, I've found it pretty accessible, and I'll actually switch out some home-grown code for it. [edit] I noticed some other comments complaining about execution handling (threads, etc.) so I figured I'd update this and say, maybe I got lucky as it's all pretty straightforward in Python (as long as you understand your app's execution environment (threads, asyncio, etc.) -> https://github.com/ReactiveX/RxPY#schedulers https://github.com/ReactiveX/RxPY#schedulers

dfee 9y ago

I "learned" RxPy in a couple hours yesterday (a 3rd party lib I'm using has an interface that requires me to use them), and I figure I'll share a bit about my experience: 1) the documentation is supremely lacking (subjects aren't even mentioned in the RxPy repo https://github.com/ReactiveX/RxPY https://github.com/ReactiveX/RxPY) 2) the generic documentation points to language specific documentation – that's 80% just "TBD" (http://reactivex.io/documentation/subject.html http://reactivex.io/documentation/subject.html) 3) it's actually quite simple once you figure out it's just code level pub/sub with a new naming convention. 4) there seem to be some opinionated perspectives around using it in the community, though largely from a JS perspective (look into "should I use subjects"). Despite those flaws, I've found it pretty accessible, and I'll actually switch out some home-grown code for it. [edit] I noticed some other comments complaining about execution handling (threads, etc.) so I figured I'd update this and say, maybe I got lucky as it's all pretty straightforward in Python (as long as you understand your app's execution environment (threads, asyncio, etc.) -> https://github.com/ReactiveX/RxPY#schedulers https://github.com/ReactiveX/RxPY#schedulers