3 ms·

RX is a hilarious pattern IMO. 90% of the usage I've seen would be simpler and less code just doing things the old fashioned way. The vast majority of observer

• romanovcode 9y ago
  Yeah but the pattern emerged before `async/await` was javascript standard so people kind of sticked to it. I know some not bad js developers who use RX a lot and have no idea about `async/await` existence, I even had to explain to couple of them how `async/await` works and what is "imperative code". No joke.
  • WorldMaker 9y ago
    Why not both? It doesn't have to be either/or: async/await is a great monad for cases where you need a simple imperative flow. Rx and the Observable pattern are great for cases where you have more complex data flows with complex needs like backpressure support (throttling and buffering), and complex time management. Each has very different strengths, and it's very easy to work with both together. const someStream = Rx.fromPromise(myAsyncAwaitFunction()) const arrayINeed = await myRxObservable.toArray().toPromise()
    • slackingoff2017 9y ago
      let val = await Thing(); Vs Observable.of(thing).subsribe((res)=>{call back} For all(most) cases where you only need to hear back once
      • WorldMaker 9y ago
        If you only need to "hear back once", then yes, Observables are probably overkill. But again, it's a false dichotomy, and your second example isn't much different from what await essentially rewrites to: Thing().then(val => /* call back */) The benefit to async/await is that the runtime does the rewriting to Promise callbacks for you. But you can use both and get that advantage for both. Rx has supported converting to/from Promises since the beginning. Working with both is easy. let val = await observableOfJustOneThingINeed .take(1) // I just need one, I don't care if there are more .toPromise() You don't have to manually subscribe, you can use a Promise and await it.
        • WorldMaker 9y ago
          There are cases as well where maybe you want a linear async/await flow in the middle of an Observable flow, too. For instance: let jsonStream = searchFieldChanges // observable of search field change .debounce(300 /* ms */) // don't do it too often .flatMapPromise(async (search) => { const request = await fetch(`${searchUrl}?query=${search}`) return await request.json() }) ETA: To reiterate the point: both tools are better together and it's not one or the other, it's like most tools finding the right one for the right job.
        • slackingoff2017 9y ago
          What RX gives you is a smooth flow to the last callback. Async is admittedly less flexible but the only way I know of to trigger asynchronous flow without a callback. I worked in the C# world for a while and I'm still in envy of how clear and powerful good async support is.
          • WorldMaker 9y ago
            Under the hood, async/await is using callbacks into a finite state machine. JS Promise and C# Task<T> (which are very similar in design, for obvious reasons) are both still driving the operations in an async/await function, the JS runtime, C# compiler (or TS compiler), is doing the heavy lifting of converting imperative looking code into a finite state machine for Promise/Task callbacks. You can't avoid callbacks in an asynchronous flow. async/await is just a conversion between imperative looking code and a callback structure. It's a great win for developers that we've built such conversion tools (thanks to work on monads in languages like Haskell and OCaml). Rx is for higher-order asynchronous streams where you have multiple events over time. It doesn't have the beauty of async/await because it's a much more complicated abstraction than the basic monad of Promise/Task. If you have a stream of events over time you can use Rx and if you have just one Promise at a time you can use Promise/Task and thus async/await. (The difference between I want to know every click of this button and I want to know just the next click of this button.) Most applications are a little bit of column A and a little bit of column B, and you don't have to pick one or the other, you can use both side-by-side.