I agree that a purely blocking style would be best, and maybe we can hope for that in ES8. :) But async functions are still much nicer than promises. And in pr

I agree that a purely blocking style would be best, and maybe we can hope for that in ES8. :) But async functions are still much nicer than promises. And in practice, I don't think it will be that hard to explain to newbie programmers. Most of them will not be writing code that actually produces promises, just the code that consumes it (because they're not writing ajax/database libraries). So the "await" basically becomes part of the library API from their perspective. E.g. they type "await library.doSomething()", their editor tells them that the surrounding function needs to be async, so they add the word "async," and they're done. They don't have to learn a completely new system in order to work with this library. As for the uncaught Promise rejection project, it is certainly nasty (and has burned me many times as I worked on Pouch), but I'm hoping this can be solved by better tools. E.g. in Chrome, they recently started logging uncaught promise rejections to the console.