> 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 all promises libraries support `call`. This isn't an article about the differences between particular promises libraries and the cooler features of some of the fancier ones. It's about returning proxy interfaces to seamlessly chain asynchronous operations.
If I were writing a critique of bluebird and left out `call`, then you would be right to accuse me of ignorance and/or malice.
> and your proxy queues don't make sense for someone who understand promises.
Proxy queues aren't for someone who understands promises.
The point of the proposed framework technique is to negate the need for the end user to understand promises, by simplifying the interface as much as possible. It's about making things more accessible for beginners and hobbyists.
> I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
No doubt, but it's not an article about bluebird. It's an article about creating frameworks which hide their complexity from the end user by using some interesting techniques.
> 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'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
My goal is is to prompt people to think creatively about their libraries and how their users interact with them. A lot of people use technology these days to enhance their main profession, and making the code more accessible to them is not a disservice.
> I think it conflates promises with values,
The point is to allow the user to use asynchronous responses as if they're normal values. Promises can be used as a powerful building block to this end, but not the end itself.
> I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
http://mootools.net/developers
Why not just be respectful of other developers, though? It's a creative profession, and not everyone will write their code in the exact same way that you would write your code.
> I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that.
I'm pretty sure you understand those things as well. Good for you.
Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
> 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.
I also agree there's a lot to be improved in the article, but it's a rather complex topic and I wanted to target the widest audience possible. However, an in-depth discussion of how developers who are intimately familiar with promises write their code when utilizing their own frameworks would not be one of my improvements, as it has nothing to do the topic I set out to tackle.
What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself, or because you wouldn't need to use it yourself. This went through several rounds of technical review, and took quite a lot of work from many different people.
There's no community benefit to discouraging alternative viewpoints, and considering the article's title isn't How Ingor Writes JavaScript, I don't feel particularly bad for not explaining that particular nuance of the topic.