RxJS in action: RxJs vs RXJava concurrency

I am almost flluent in RXJava and reading the snippets in the  sample of the book, it looks exactly the same thing, there is an Observable, an Observer, the two are linked with a subscribe method, and a bunch of operators. In Android there are the so called Schedulers, that are really useful to manage async  calls, do you have a similar concept to manager concurrency? Thanks

Thanks for the question!

Indeed, in RxJS you will also find a concept of Schedulers as well, however their use tends to be much rarer as its utility is somewhat different from what you would find in RxJava or Rx.NET (where I started my journey with reactive programming). Because JavaScript is a single threaded language that manages async through an event loop, there is little need to be able to manage multiple contexts (re: thread) as you might with RxAndroid where you have both a UI thread as well as long running background tasks or asynchronous API calls.

Thus you will primarily see Schedulers being used in testing, where we can use the TestScheduler to mock out and directly control time. One other use case where you might also find schedulers is in games or simulators that use the "requestAnimationFrame" animation loop and we can use the AnimationFrameScheduler to synchronize Observables with the animation loop.

Pau Daniels wrote:Thanks for the question!

Indeed, in RxJS you will also find a concept of Schedulers as well, however their use tends to be much rarer as its utility is somewhat different from what you would find in RxJava or Rx.NET (where I started my journey with reactive programming). Because JavaScript is a single threaded language that manages async through an event loop, there is little need to be able to manage multiple contexts (re: thread) as you might with RxAndroid where you have both a UI thread as well as long running background tasks or asynchronous API calls.

Thus you will primarily see Schedulers being used in testing, where we can use the TestScheduler to mock out and directly control time. One other use case where you might also find schedulers is in games or simulators that use the "requestAnimationFrame" animation loop and we can use the AnimationFrameScheduler to synchronize Observables with the animation loop.

crystally clear! great reply, makes perfectly sense in RXAndroid you have observeOn and subscribeOn just because you want to maintain the UI responsive,  as you say. Did not know about javascript( actually I grasped the basis only to dedicate a bit more to reactJS).  I guess so the power in Javascript to use RX comes when you have to manage multiple calls with the server, or when you want simplify some operations that with a no functional approach will be much more verbose and code unreadable

Pau Daniels wrote:Because JavaScript is a single threaded language that manages async through an event loop, there is little need to be able to manage multiple contexts (re: thread) as you might with RxAndroid where you have both a UI thread as well as long running background tasks or asynchronous API calls

In a browser you could have a webworker which (supposedly?) runs in its own event loop. Do schedulers make any sense in that case?

I don't think the Scheduler interface would work very well with that of the Web Worker because there is a lot of indirection which would make it difficult to send actions that the Scheduler needs executed to the Worker. I think you can still use Web Workers with RxJS but it would be through leveraging them as as we would something like a WebSocket.


See my more complete answer the same topic here