Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future.
I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront:
Generator based flow-control goodness for nodejs (and soon the browser), using thunks or promises
What you yield from your generator is not magical pixie dusts, it's promises.
The generator is the driver, but the driver on its own its useless if it's got nothing to drive.
And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there.
Again, generators in and of themselves don't do anything (for async code). Something needs to be generated/yielded, and that thing is the reification of an asynchronous operation. Such as a promise[0]. Generators and promises fulfil different roles, generators are used as imperative "sugar" for chaining promises.
The generators you yield will ultimately resolve into a series of async operations (promises or "thunks"), yielding a generator is convenience (not very useful convenience either, since `yield*` exists the ability to yield generators just complexifies the driver)
[0] and in the case of co a "thunk"[1], because node
You can also use plain functions, objects, array, and even other generators too. Least, that's what the framework tells me when I fuck up my tests. It's not just all promises under the hood.
Comments
I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront:
What you yield from your generator is not magical pixie dusts, it's promises.
Actually, it's not promises. It's generators.
co thunkifies promises: https://github.com/visionmedia/co/blob/master/index.js#L209-...
The generator is the driver, but the driver on its own its useless if it's got nothing to drive.
And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js
Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there.
Here is a file from my ongoing project, should explain how generators are being used. See getPosts() or addPost() https://github.com/jeswin/fora/blob/master/server/src/models...
[Edit: Just read your earlier (Gr.GP) comment. Might want to avoid the unnecessary snark, especially when there's a chance you might be wrong.]
No.
Again, generators in and of themselves don't do anything (for async code). Something needs to be generated/yielded, and that thing is the reification of an asynchronous operation. Such as a promise[0]. Generators and promises fulfil different roles, generators are used as imperative "sugar" for chaining promises.
The generators you yield will ultimately resolve into a series of async operations (promises or "thunks"), yielding a generator is convenience (not very useful convenience either, since `yield*` exists the ability to yield generators just complexifies the driver)
[0] and in the case of co a "thunk"[1], because node
You can also use plain functions, objects, array, and even other generators too. Least, that's what the framework tells me when I fuck up my tests. It's not just all promises under the hood.