JavaScript's Promised Convenience

JavaScript's Promised Convenience
gregroz.me

This is a great discussion here. At the heart, to me, is what a promise represents. If it's just some future value, and the promise itself is inconsequential, of no value, that means it's ok to keep forgetting the promises & just keep relating values.

But a promise isnt just the eventual value. It's a thing unto itself, another first class object. I think there's a totally missing but extremely valuable view, that Promises represent the compute that is happening. They are values we can pass around in their own right, & which properties & control methods can be attached to. That we built a language that erased chain, that forgets the process is unfortunate.

I further think it would have been worthwhile for promise handlers to receive not just the eventual value, but the promise they are handling too (give them the process!). Conveniently the chief question in the article, of whether we blow up intermediary promises, can be perhaps addressed with this same technique: promise handlers could, rather than having a handler(value) function signature, be handler(value, ...promises), where we could see the lineage of promises present.

I confess: there is some speed boost we get, particularly I believe when using async/await syntax, which lets us forgoe creation of an intermediary promise entirely, but it's still wild how much possibility we sacrificed, and how readily & quickly (albeit not without some fierce debate!).

Also just wild to me we decided to make promises fully async, that their resolved status & resolved values would not be knowable except asynchronously. Seemingly just because we were afraid of users being too creative. It's a different but related fear, but fear of unleashing Zalgo was extremely extremely high, a panic about mixing async and sync, that we put on the level of a fear of summoning out of control super demons who would rain anarchy down on earth, but it just... never became a problem. And with async/await, it's basically inconsequential, practically good practice, to return a sync object if you have it and async if thats all there is. It is confusing as heck to me whether any of these fears are at all justified or real. I still genuinely am confused by the arguments made a decade ago; they seem full of charactures of perceived lowly common developers who must be given only blunt instruments. Fear Uncertainty & Doubt ruled this decison making process, & there was surprisingly little effective counter resistance.

There is no such thing as returning "sync object" vs an "async object" unless you mean you wish to check every single value in your app over and over again to see if its 'sync' or 'async'.

Promises are about control flow, not data. They are also just a stone on the path to full, proper async/await

It's mere oponion that promises are flow control, and I dont see why that opinion ought outweigh bith the obvious tautological truth that they are quite factually objects too in their own right. It seems a huge regression to me to decide, js is a language with dirst class everything, oh, except this thing is an object but actually we just want it to be flow control, so treat it otherwise & dont make use of the object-ness please.

A sync vs async object is a thing without a .then vs a thing with a .then. With async/await, you dont have to check. Zalgos dead man, we should give up this fearmongering about demons.