Open tjvr opened 7 years ago
I'd argue that async/await is less confusing - especially if you don't know that they're actually promises. If everything is async/await it simplifies a lot of code.
await UW.init(...)
let player = (...)
await waitSeconds(5) // etc
Interesting thought. Can await
/async
be used at the top-level scope in an ES module?
No.
You'd have to do:
import 'you-win' as UW
async function main() {
await UW.init()
// ...
}
main().catch(console.error)
Which I'd argue is fairly ugly. You could do:
import 'you-win' as UW
UW.init(...).then(async () => {
// ...await foo()
}).catch(console.error) // not sure if you need this in browsers?
Which is almost the same as the current recommended way of initialising, except it has an async
keyword.
Or, if the game itself could be considered a module (this allows us to easily have an actual restart() method, too!)
import 'you-win' as UW
export async function main() {
await UW.init()
// ...
}
And then we somehow dynamically import that script (babel in the browser??) and execute main().
Perhaps you could run it in a Web Worker - and kill the web worker upon restart()
!
No.
Aw. :(
An export is an interesting idea, though I don't think it's required in order to have a restart() method...
Proposal:
forever
andSound.play
should return aPromise
. That way, you can do stuff after they finish.Example for
forever
:sound.play().then(() => { … })
would act like "play sound and wait" from Scratch.My concern is that introducing Promises really complicates the concept of control flow—because they're a poor fit for the nature of JavaScript! Using
await
/async
might help alleviate this, but then we're introducing more confusing keywords.Help!