3 ms·

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.
      • slackingoff2017 9y ago
        Async avoids callbacks by restoring your calling context under the hood just like the compiler does for normal function calls and callbacks. It just does it in a way thats clearer IMO