What is concurrency?

To see why we need a library like Ember Concurrency in the first place, it's helpful to understand what concurrency is, and how it affects your Ember app.

Ember applications can do lots of things that take time: load data from a server, animate UI elements, or even just pause a few seconds while waiting for user input. We typically say that these activities are non-blocking, since the user can continue to do other things in the app while waiting for these long-running activities to finish.

This tendency for multiple activities to happen at the same time is known as concurrency.

Ember apps themselves are long-running, and they make it easy to add activities that take time and don't interrupt the user. So nearly every Ember app exhibits concurrency in some form.

What makes concurrency hard?

The mere fact that some activities are long-running is not itself problematic. After all, they could just run in a sequence. If our app needed to pause for 250 milliseconds and then make a network request (for example while filling out an autocomplete search box), we could just execute those activities in order, waiting for the first to finish before moving on to the next. If the user did nothing while these two activities were running, they would complete, and everything would work as expected.

However, the story becomes much different when long-running activities interact with each other. It's this interaction that's at the core of what makes dealing with concurrency so difficult.

Imagine a user enters a search term in an autocomplete box. Our Ember app pauses while the user is typing, and then sends a network request to query the server. Before that query returns, the user starts typing again. Our app kicks off another request. What happens now?

When the first request comes back, the autocomplete box is filled with the list of results - but that list is now outdated, since it doesn't have the latest search term. While the user starts reading the list, the second request comes back, and the list re-renders with the new results.

The key thing to observe here is that both search activities affected the same piece of state - the autocomplete results list. Because both activities were long-running, and both shared the same piece of state, it was easy for our app to behave in a way that we didn't expect.

These types of problems are endemic to Ember apps, and they stem from the interactions that happen between long-running activities. Shared state in a concurrent environment creates many problems for programmers. In the next video, we'll talk about Ember Concurrency's solution to this problem.