You do the promise-as-a-pyramid example, then say you still have to nest and leave it at that, misrepresentation if not malice. Basically, you have a solution through promises you're not showing either because you were unaware or because you chose to, I _hope_ it's the former.
> not an example of how to use promises in production code.
I have some 3 year old production code that begs to differ :)
> Additionally, this is an article about framework design, not how to use them, making your corrections (which involve using a framework with chainable proxy queues) somewhat tangental to the discussion.
Promises are not a framework, and your proxy queues don't make sense for someone who understand promises. If you go look at Mark Miller's original work on promises you'll see that promises are proxies for asynchronous actions - that's why they were created in the first place. It's also a great read regardless.
> You seem to have the generic concept of a promise confused with a particular promises implementation with some extensions that you particularly like.
I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
> The Promises/A[0] specification
Promises/A is an old specification about _interoperability_ that no one (its authors included) care about anymore.
> Even the Promises/A+[1] spec
Promises/A+ is a spec about interoperability between promise libraries. It only specifies `then` and even there only what it must.
> This isn't a criticism of the model, it's an explanation of the model and some suggested extensions.
Then I'm sorry but it's not a particular good one, really, I don't know who you are and I mean no offence but I think your article does a disservice to promises.
> I'm really curious as to how you managed to miss that point.
Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling.
> I think we can both agree that, to a developer not possessing your level of skill, the revised example is slightly easier to follow.
I think it conflates promises with values, we've offered this technique in Bluebird for years now as an example in https://github.com/petkaantonov/bluebird/blob/master/API.md (see under "Using defaultPromisifier parameter to add enhancements on top of normal node promisification:) without anything more than `.all`ing the arguments.
> Thank you very much for the encouraging words, but in the future, could you do everyone a favor and either read an author's biography or click on the author link before making wild assumptions about his or her programming background?
I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
> The context might make it easier for you to understand the article itself, making your comments far more valuable.
I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that. I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article.