DevelUp.js : Async and Await
A colleague recently turned me on to an ES2017 feature called “await”, which extends upon ES2015’s introduction of native promises by providing a synchronous-like syntax to JavaScript’s underlying, asynchronous, processing model.
Along with introducing me to the concept, that same colleague pointed me to a fantastic presentation, from Ross Boucher, that does a great job of explaining the “await” and “async” keywords in a way that I could easily digest. I highly recommend that you check it out.
My Take
Although await does a lot to advance the asynchronous model by reducing the complexity of code structures, as an extension of the progress that promises have made, there is a cost that we should, at least, acknowledge.
A parallel can be drawn, here, with the ES2015 introduction of native classes, which simplify fundamental prototype manipulation.
In both cases, the cost is an obfuscation of the underlying mechanisms of the platform (and the libraries that extend it) which, inevitably, remove an amount of control from the developer. In losing that control, developers also tend to lose opportunities to form deep understandings.
A developer who is learning asynchronous methodologies for the first time may not be motivated to gain a core understanding if “async” and “await” are available, since they make asynchronous code look a heck of a lot like synchronous code.
I’ve taught a lot of people to code, or to get better at coding, and one of the more common hurtles that I face when explaining any concept is their lack of “background information” about some mechanism. Those I’ve taught about promises, for example, usually grasp it more quickly if I teach them about “callback hell”, first.
With that said, this is not necessarily a bad trade, especially if developers learn when, and when not, to use these new language features. After all, one could argue that we lost an amount of control when we began compiling source code into assembly, but it would be hard to make a case for compilers as being a bad thing, overall.
Often, access to the underlying mechanisms of a platform just isn’t needed, especially if the adoption of a new feature is done in a comprehensive way, whereby the implementer learns to augment his or her broader approach to solving problems. As long as you try to develop a mastery of a new feature, by understanding how it works and why it exists, rather than simply gaining a surface understanding, then you can [usually] overcome the pitfalls and side-step the “gotchas” that come with it.
Overall, I think the new await and async keywords are awesome and I am excited to see where they take us as they gain wider adoption.
