Background: I started using async/await in my code a few weeks ago.

I have one major misgiving about async-await - the regression in needing to do a try-catch if one isn't isn't a test situation. This is a terrible syntax to have to write to handle this.

If you don't like try/catch, you can still do:

    await getPromise().catch(err => {/* handle error */ })

Personally, I don't find the try/catch syntax that awful and it'll get better with do expressions[0], e.g.:

    const username = do {
      try { await getUsername() }
      catch (err) { 'unknown-username' }
    }

One common misconception is that async/await forces you to put everything inside a try/catch block which isn't the case. Errors get bubbled as with regular promises and you only need a try/catch block wherever you previously had a `.catch` (or you can keep the `.catch` as mentioned above if you prefer that syntax).

One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution.

I'm not sure what you mean by that but you still have to explicitly use the "async" keyword for any function that uses "await". And function calls that are not prefixed with "await" will not block just like before. In fact, in an async/await codebase, you can more easily tell which functions are async because they'll have "async" in front of them (unlike errback/promise code which would require you to read the body of the function).

Minus the awful try-catch, I'm not necessarily against async-await being the norm, but its broad effects on how async code will be written should be recognized, especially considering that it doesn't solve a fundamental issue like something like observables do.

Yes, it's basically just syntax sugar for promises but it does remove a lot of boilerplate code and is easier for JavaScript engines to optimise.

[0] http://wiki.ecmascript.org/doku.php?id=strawman:do_expressio...