Promises (representing the result of a single asynchronous operation) and Observables (representing an ongoing stream of emitted values) aren't really equivalent. I know you can create an Observable from a Promise, which will emit a single value when that promise is fulfilled and then be marked as completed or closed - but this is more for integration - such as being able to combine inputs from single-shot async calls into broader observable operations. If your Promises are discrete async calls, I'm curious why you would want to convert them?

If you're just rewriting these Promises because the syntax is too verbose, you might be interested in checking out async/await as another alternative; I just rewrote some Promises to that recently, and it's really, really nice. Of course, if you prefer RX Observables, go right ahead :)

Thanks for the note, I am looking into it right now. One area that may grind my head with async await however is that there is a lot of Promise.all work in this codebase. Would you still use async/await constructs when you need to do a lot of fork/join/merge stuff? (sorry for the derail HN)

If you're using Promise.all to run code in parallel, then async await can't really replace that, as far as I know. But you can still use `await Promise.all(...)`, which will free you from having callbacks everywhere; running parallel code will no longer have to look so different from running it sequentially, which is quite nice.

Yes, of course !

https://jsfiddle.net/0wc0vjw2/1/

>I'm converting a codebase of Javascript of about 200+ js files to Typescript today.

Pity you! I fear such tasks.

As mentioned,take advantage of async/await. Also, make sure you wrap everything in modules and access from outside through module exports.