Skip to content

Instantly share code, notes, and snippets.

@mattpodwysocki
Created May 15, 2015 13:23
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save mattpodwysocki/00bc7acebd6912998dc0 to your computer and use it in GitHub Desktop.

Answer the Question: Q: What's your opinion in the claims of RxJS having too cumbersome API? AFAIK eg. Bacon.js was borned from that frustration.

Bacon.js was created for a number of reasons, the first of which was due to the nature of the source of RxJS. At the time that RxJS was created, it was not open source back in 2010, and in fact wasn't open sourced until 2012. That was the first frustration because Juha, the author of Bacon.js, could not fully understand the code, nor was it well documented. We have since remedied that in a number of ways with our ReactiveX.io site which contains all implementations of Rx and their operators. In addition, we have added extensive documentation for RxJS as well on the RxJS Documentation Page

The second reason is that RxJS was not idiomatic JavaScript at the time of its inception, in fact it more looked like C# just translated roughly into JavaScript. That was helpful to .NET programmers using RxJS, but not to the rest of the JavaScript community. This has also since been remedied with operator aliases such as adding filter for where, map for select, flatMap for selectMany and so forth.

The rest of the reasons for why Bacon.js were created are philosophical differences. Juha, the author of Bacon.js, did not understand why we had the idea of Hot versus Cold Observables. To give an analogy to make it clearer, think of a Cold Observable as a movie where you will be able to watch the same movie, time and time again and you will always get the same result. Things that fall into this category would be Arrays, Iterables, Ranges, etc. Hot Observables on the other hand are more like a play in which you can see it night after night, but there might be varying differences between the performances. Operators that fall into that category are things like events where it will happen whether you are watching or not and the values aren't quite the same depending on when you start listening. Bacon.js made it so that all operators were Hot Observables due to some frustration of not understanding why we made those choices. We were very specific in why we created it that way so that you would always get the same result for static data such as arrays, etc and everyone would get their own copy as it were for consistency sake. Hot Observables were also very important because we didn't want to start capturing data from events until we are actually listening via the subscribe or forEach else we would be queueing up data that we might not ever need. There are ways around this of turning cold observables into hot and vice versa, but ultimately we left it up to the developer to determine what temperature they need. Another part of that laziness and coldness came in the frustration of operators such as scan which do not immediately yield a value until there has been some calculation, so many times you will find developers will use startWith, but this is very deliberate decision on laziness that we made.

The other aspect that Bacon.js is missing is the idea of Schedulers, which is unfortunate as that is really the secret sauce as it were for Rx. This determines where and when a particular item is scheduled. Why this is important is that we can say that the next item should be yielded via the requestAnimationFrame, MessageChannel, postMessage, setTimeout, setImmediate, process.nextTick or any other mechanism directly as part of the DOM, or just executed immediately. Thus we could schedule items in the future, or now, and have deep cancellation down to the very core. This is also useful when it comes to libraries such as AngularJS which has a digest cycle that you want all updates to happen in. Using schedulers, you can control to that degree. The usage of schedulers also allows for virtual time, which is a big help with deterministic time-based testing where there are no async tests required (unless we are testing things such as Promise integration or the schedulers themselves).

I hope this answers your question as to why Bacon.js was born and why we think we are different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment