await on synchronous functions

Gil Tayar gilt at
Fri Jul 17 18:50:13 UTC 2015

I would tend to agree with Tom (i.e. Promisify non-promises), even though
we should notice that awaiting a synchronous function adds a non-trivial
overhead, because although the promise is immediately resolved, the await
will "return" only after being processed in the event loop (if I remember
the Promise spec correctly).

So if option #1 has the advantage of "alerting" us to this performance
effect, why do I still prefer option #2? Because of consistency - this is
similar to the callback the ".then" of a promise accepts: if the callback
returns a promise, it is chained, and if it is a regular value, then it is
promisified and chained.

The same two options exist there, and the spec decided on #2. And
rightfully so. I like the fact that the code "just works" and in languages
like JS, I would prefer it "just working" than being "statically correct".
Dynamic languages lots of time tend to prefer the "just works, albeit
slowly" approach to the "theoretically and statically correct" approach.

- Gil

On Fri, Jul 17, 2015 at 9:27 PM, Tom Van Cutsem < at> wrote:

> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <andrea.giammarchi at>
> :
>> If I might, if there's one thing that has never particularly shone in JS,
>> that is consistency.
>> I see only two possibilities here: 1) it throws with non Promises 2) it
>> "Promisify" anything that's not a Promise as if it was a
>> `Promise.resolve(1)` ... but since there's too much magic in the second
>> point, I'd rather stick with the first one.
> I would be highly in favor of (2). Think about a large program where you
> refactor a single async function to no longer be async. Then I see no
> reason why I should be forced to refactor all of its callers to remove the
> await keyword. Going from sync to async requires refactoring because you're
> introducing new potential interleaving hazards, but any code that is
> already prepared to work with async functions (or promises in general)
> should work equally fine on immediately resolved promises.
> regards,
> Tom
>> Just my quick thoughts
>> Best Regards
>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <zenparsing at>
>> wrote:
>>> I know the spec for this isn't finalized, but what is the current
>>>> direction for the behaviour when await is used on a function that is not
>>>> marked async and doesn't return a Promise? Should it run immediately or
>>>> wait for the next turn of the event loop?
>>> More generally, the question is: what should await do for non-promises?
>>>     await 1;
>>> Should it force a job to be queued?
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Gil Tayar
Software Architect @ Wix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list