What exactly did you have in mind other than "new Promise()" to create a promise?

its not creating a promise that is the problem, its consuming.

Async/await really is a nice sugar, check it out when you have a chance.

new Promise(function(resolve, reject){ /* code */ })

it's a little much

That's because 99% of times when people use it it's an anti pattern: stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it

Ideally, if you're writing business logic, you shouldn't be creating promises but consuming/combining/chaining them from libraries.

What would make you say that? Why wouldn't you use promises in your business logic?

The idea isn't "don't use promises", it's more "use/chain the promises you already got from libraries (e.g. AJAX calls), don't construct new promises yourself". See the StackOverflow question inglor linked to: https://stackoverflow.com/questions/23803743/what-is-the-exp...

Yeah what dcoder said. You only need to create a promise at the source of an async event like IO. Internal logic will be downstream of IO and therefore will be just be sequencing promises generated elsewhere. You do not (and should not) need to create intermediate promises to do that.

Most of the time the object you'll be awaiting will be a promise.