returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)

David Teller dteller at mozilla.com
Mon Feb 4 12:11:14 UTC 2019


Unfortunately, turning async code (which often has components that
execute in a different thread or process) back into in sync code is
really, really hard.

What semantics would you give to this `Promise.sync()`? Can other code
be executed by the main thread while you're waiting for your promise to
be fulfilled?

* If the answer is "no", you need to also block the entire DOM and CSS
engines (both of which can call back into JavaScript) for this to work.
Or, if you're in Node, all your I/O and all your ongoing callbacks.
Needless to say, your users aren't going to be happy.

* If the answer is "yes", you are breaking the run-to-completion
guarantee of JavaScript. You may have events that are processed in the
middle of apparently synchronous execution because there's a
`Promise.sync()` hidden somewhere. That's going to break a lot of things.

For what it's worth, Firefox used to have an equivalent of
`Promise.sync()` for use in privileged code (i.e. the UI and
extensions). Experience shows that it caused insane amounts of bugs.

Cheers,
 David

P.S.: Yes, there are ways around this, if you're willing to write/use a
CPS transpiler. I've written one years ago. The results were really
powerful, but also really messy. I don't suggest heading in this direction.

On 04/02/2019 00:39, #!/JoePea wrote:
> I often find myself enjoying async functions until the time comes when I
> don't want to await anything, and I want the call stack to be sync (i.e.
> I don't want to defer if I don't have to).
> 


More information about the es-discuss mailing list