I don't think thatasync/await is a bad thing, but I like that Promises force you to think what parts of your code depend on which asynchronous data and to organise it accordingly. Async/await allows you to write asynchronous code like it is synchronous and I have mixed feelings about this.

It's worth mentioning that I don't use either, I usually useFluture because it doesn't automagically catch all and every error in the rejection branch, which you can't achieve with async/await or Promises. But the Fluture API is quite similar to a Promise and I kind of like it.

Also, notice that if the goal is to remove indentation, there is no reason why the lastthen of the example on the left can't be rewritten as

.then(response=>{this.updateEventValues()returnthis.Alert.success('Se ha actualizado el evento')).then(()=>this.clearEventAndClose())

Which has the additional benefit that if you need tocatch any rejection, you only need to do it once.

Neither is very good, as you're doing nothing to handle errors.

One requires.catch() in several places, the other atry { ... } catch (...) { ... } block or several.

Overall theawait syntax is much easier to read and follow the logic, but if you have to put atry..catch around every one it quickly becomes a mess too.

I love async/await and and the same time I despise try/catch, so I tend to use .catch() method for error handling. Just looks neater. I wish I could do all exception handling that way.

This is totally out of topic, but what font is this?

I think the async/await is a clear winner here, since these were 4 sequential operations, 2 of which just needed to yield yet still block the progress of this function, and cancel the function if they throw.
It's the textbook happy case for async/await.

I do agree with@avalander's refactor though, which gets you closer to this without the async syntax.

i like async and await. Especially await :))