In this chapter, we have covered asynchronous code, when it is used, and for what purposes. It is clear that asynchronous code becomes harder and harder to read and maintain as it grows, giving rise to patterns such as callback hell. There are several techniques to deal with this, as described throughout this chapter. Changing your coding style a little is one way. Looking at constructs such as promises, especially in conjunction with async/await, is another way. Using async/await means we suddenly get something that can be likened to order in your async code. We have tried to keep things as framework free as possible as it is important to understand all the mentioned concepts without mixing them up with concepts from a specific application framework. One thing can be said though: Angular allows you to use whichever asynchronous method you want to organize your code. Doing HTTP calls, for example, uses an Angular service that is strongly tied to the RxJS library, but you are free to use a promise-based style such as the fetch() API. It is also possible to leverage async/await with Angular using Babel and the transformer that supports it.

This chapter has laid a foundation for what asynchronous coding is. The next chapter will build on that foundation by introducing the concept of Functional Reactive Programming (FRP). It deals more with how to reason around the fact that data arrives seemingly when it wants to. As messy as that sounds, even that can be modeled to create a sense of structure and order if we think of our data as a stream. More on that in the next chapter.