I love async/await but I really wish it wasn't built on promises. All you would have had to do is make it so when you use the await keyword, you don't pass the

I love async/await but I really wish it wasn't built on promises. All you would have had to do is make it so when you use the await keyword, you don't pass the callback, the runtime passes it for you, pauses the function and resumes it when the callback is called (returning values and throwing errors as you would expect). I implemented this here: https://github.com/bessiambre/casync https://github.com/bessiambre/casync but it would be even better with language level support. Whenever I encounter JS beginners and they ask me about simple looping over asynchronous operations sequentially, I mention async/await, the discussion veers towards promises and then I have to mention the state machine and the caching layer for errors and return values, pending, fulfilled, rejected, settled states, reject/resolve callbacks and how it all fits together with 'then' chaining and 'dynamic replacement' by which point they just want to go back to Python or whatever. With a callback based async/await, I could just say: Here, with this keyword, the function will pause until the callback is called. Just put your function taking a callback in a normal loop and await it. It would be cleaner, more functional, more stateless and faster. The features of promises aren't even used with async/await. The point of promises, the caching layer and the state machine, is to be able to add the continuation later but with async/await, it is always just the next line in the function so it doesn't need to be added later. It's unnecessary performance penalty, complexity and statefulness on every asynchronous function call. I did try to propose this as a language feature here: https://es.discourse.group/t/callback-based-simplified-async-await/343/7 https://es.discourse.group/t/callback-based-simplified-async... It didn't get much traction an I was too busy to push it further.