“It was the best of times, it was the worst of times”. While the opening for one of Dickens’ famous novels might not have been about programming, it does describe the process of understanding synchronous and asynchronous programming quite well. A lot of interns and new GeoDevs get thrown off by these concepts, so we thought we’d put together a high-level primer to serve as a foundation for anyone trying to break it down.
What do ‘Synchronous’ and ‘Asynchronous’ mean?
In terms of development, synchronous means everything happens step-by-step, in order. Each step is fully complete before moving onto the next one. Most developers learn to write synchronous code first. You’re reading this article synchronously right now (unless you can magically read multiple parts of it at the same time. In that case, please get in touch.)
Asynchronous, on the other hand, allows for code to happen out-of-order. Something may be half-done while something else kicks off, and both are happening at the same time. This is often a little harder for new developers to wrap their heads around. Once they do, however, a whole new world of opportunities await them. As with any new tool, learning how to leverage asynchronous programming properly allows a developer to craft a wider array of new, and potentially more powerful, solutions.
What is Synchronous JavaScript?
Most of the programs our interns start out with will be synchronous, especially when they are just learning programming itself and haven’t gotten into the wonderful world of geo-development. Like we said before, synchronous is when things happen in order. That means, in a synchronous JavaScript program, the code will start at the first line and execute each step in order.
Think of synchronous JavaScript like sitting down to have a conversation with a friend. One of you says something, then the other processes it and responds. This continues, back-and-forth, in real-time. You each wait while the other talks, and everything happens in order.
Perhaps, in your code, you will get to a point where a method is called. If the code jumps to that method, completes it step-by-step, then returns to the point where that function was called, it’s still synchronous. It’s synchronous because the code that called the method pauses and waits until the method finishes before continuing.
To keep with our conversation analogy, it’s as if you were chatting with your friend when they remembered they wanted to show you something. They got up to grab the item, and the conversation paused while they fetched it, then resumed when they returned.
What is Asynchronous JavaScript?
Asynchronous JavaScript is typically a little harder for people to wrap their head around at first, but it is so essential to being a geodev. In asynchronous programming, different things are happening at the same time. It’s important because it keeps things moving. It’s a bit challenging because sometimes that means things are happening out-of-order. To start with, let’s explain using the conversation example from before.
Imagine you are planning on a trip across a continent. At each stop, you will send your friend a letter. When your friend gets them, they will e-mail you back. When you start your journey, you go to each of your planned stops in order, but you soon notice the e-mails your friend is sending appear to be replying to the letters out of order. You realize, because different places have different processes and policies for handling post, your friend isn’t getting the letters in order. This is fine, as you and your friend both have enough information (the location the letter was sent from, events described, etc.) to know what you’re both talking about.
This is asynchronous for a number of reasons. For one, you are not waiting for your friend to respond before continuing. In synchronous JavaScript, you would send your friend a letter, then wait at that location until they e-mail you a response. This would not be a fun or efficient way to travel. Instead, you sent them your letter, then continue your travels while they receive the information and process it. This is more efficient, as you are each able to do what you need to at the same time. You’re both doing different things at the same time, so you’re operating asynchronously.
It’s also asynchronous because the letters are being responded to in a different order than they are sent. This happens a lot in asynchronous programming and is one of the most common things to confuse people when they are first learning about it. It happens because some things are faster to process than others. In asynchronous JavaScript, you will often call a method or invoke a service to perform the same operation on a set of variables. When each one is finished processing, you can continue performing operations as needed while waiting for the others. The order you get the information back doesn’t matter, so long as you can keep track of which dataset it was originally associated with.
How do I know which one to use?
It takes a bit of time to learn when to work with synchronous or asynchronous code. As a geodev, you’ll find yourself using both quite often. One of the best ways to get more familiar is to look at code (Esri has a lot of examples for their JavaScript APIs). Sometimes, it’s easy to figure out. If you need to make a call to a Rest API for some geoprocessing, you’ll probably want to use some asynchronous code. Similarly, anything with a Dojo/Deferred will be using asynchronous JavaScript.
Sometimes, a bit of critical thinking can help you figure it out. For example, if you have 1,000 polygons, and you need to buffer all of them, generate a graphic for each one, then add them to a map, do you really need to wait for each step to finish for all of them before continuing? Not really. You can invoke a geoprocessing service to buffer the polygons. Some will be easier to buffer than others (small polygons with a few vertices in a single ring, as opposed to a large polygon with several rings and lots of vertices). When a polygon is buffered, you can generate its graphic for the map. When all the graphics are finished, just add them to the map. This allows you to be more efficient and will reduce the wait-time of any user interacting with your application.
Like anything else, it’s ultimately practice and experience that will help you get a better understanding of synchronous and asynchronous JavaScript. So, get out there and write some code, fellow GeoDevs! Make mistakes, ask people for help, and learn. We can’t wait to see what you create.
Want to hear more from GEO Jobe?
Check us out! We put out articles on our blog every Wednesday. We’re also on Twitter @GeoJobeGIS, or you can shoot us an e-mail. Interested in learning more about asynchronous JavaScript and being a GeoDev? Let us know, and we’ll continue this series by looking at things like dojo/promise or lang.hitch!
