JOjohnsonjo·Apr 1, 2017
Async iterables seem to be more like a unifying feature to me.
For example the TC39 docs on async iterable say this:
> Furthermore, we introduce a new symbol
> used for obtaining an async iterator
> from a given object, Symbol.asyncIterator.
> This allows arbitrary objects to advertise
> that they are async iterables, similar to
> how Symbol.iterator allows you to advertise
> being a normal, synchronous iterable.
> An example of a class that might use this
> is a readable stream.
[1]
So, the readable stream may end up implementing this api. I went to see if the same thing might go for the observable api. I found that they may have the ability of coercing async iterables with Observable.from()[2] or they could have the ability for asyncIterators to be used as observables through other methods [3].
Observables do implement their own
Read the rest
Symbol.observable which does make them different. Really Observables do play a different role than async iterables though[3]. Something that makes observables different is they don't have to be asynchronous. As you may have noticed in the article Promises are added to a queue as micro-tasks where as observables can and will execute immediately if they have a value ready.
Honestly we don't even know whether both or either of these will make it into the final spec. I personally hope they will make it. As long as there is strong interoperability it is fine with me, which as it is this seems to be the case.
[1] https://github.com/tc39/proposal-async-iteration#async-itera...
[2] https://github.com/tc39/proposal-observable/issues/130
[3] https://github.com/tc39/proposal-async-iteration/issues/47
[4] https://github.com/tc39/proposal-observable/issues/116