# Concurrent Async and Normal Await Evaluation Blocks

**URL:** <https://es.discourse.group/t/concurrent-async-and-normal-await-evaluation-blocks/827>\
**Category:** 💡 Ideas\
**Tags:** proposal\
**Created:** [June 25, 2021, 1:24am UTC](https://es.discourse.group/t/concurrent-async-and-normal-await-evaluation-blocks/827 "2021-06-25T01:24:11Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Jonas\_Wilms](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/jonas_wilms/32/189_2.png) [@Jonas\_Wilms](https://es.discourse.group/u/Jonas_Wilms)\
**Post date:** [June 28, 2021, 7:07pm UTC](https://es.discourse.group/t/concurrent-async-and-normal-await-evaluation-blocks/827/6 "2021-06-28T19:07:18Z")

</div>

I don't like this kind of magic. Reasoning about async code is already hard, having the language do the magic for you will make folks forget what happens under the hood, until it does not work as expected. I see the [same problem with Automatic Semicolon Insertion](https://brendaneich.com/2012/04/the-infernal-semicolon/).

> Here, we have an "`async` block" that is unlike other blocks in that it is actually maintaining its scope.

With `let` and `const` we finally had consistent block scoping in JS ... Just to break that now again?

> If this change is seen as too much, I would happily settle for just a nice  
> syntax sugar for `Promise.all`

Jup, that sounds like a good idea ...

---

_[View the full topic](https://es.discourse.group/t/concurrent-async-and-normal-await-evaluation-blocks/827)._
