You’re at a job interview, sitting in the HR office of WECode.js.
The hiring manager clears her throat after glancing at your exquisitely detailed resume and asks, “What is JavaScript, Mr. JavaScript Developer?”’
“A single-threaded non-blocking asynchronous concurrent language,” you answer.
“Yes, but what does that mean and how would you explain that to, say, someone on the UX team?”
“…”
Cut!
To avoid the awkward blank stare followed by more computer science buzzwords, we’re going to break down exactly what JavaScript is. If you’re Mr. JavaScript Developer or a newbie who’s intimidated by the notion of JavaScript callbacks, everything will be demystified by our web comic. But before that, let us unpack Mr. JavaScript Developer’s first answer.
What is a single-threaded language?
Simply put, a single threaded language uses a single call stack, meaning that it can only fire one event at a time. If you’re not exactly sure how to conceptualize a call stack, just picture a Jenga stack.
Say you’ve written a list of functions. JavaScript's runtime would then compile the script you’ve written and sequentially stack the functions like blocks within its call stack. Afterwards, each function that executes is taken from the top of the stack until it reaches the bottom of the stack. There is only one stack. This, ladies and gentlemen, is single-threading.
What is non-blocking, asynchronicity, and concurrency?
Well, let us try to understand what blocking is first. In a nutshell, blocking is the traffic caused by too many synchronous calls. Imagine a narrow exit that funnels drivers into a single lane road. That road is guarded by a traffic police who only allows one car at a time to go beyond his stop sign.
Now imagine the headache you’d have if you’re the fifteenth car in line and you have to get to the emergency room. Similarly, websites coded with blocking code make for a clunky user interface.
So we understand what blocking is. Non-blocking is the complete opposite of blocking. Instead of making synchronous calls, a non-blocking language like JavaScript uses asynchronous calls, or, in other words, an emergency lane that allows for a breakup of sequential order so that you can get to the hospital on time.
Here’s where things get really interesting.
By wrapping a JavaScript function within a Web API function like setTimeout(), we can let the “secret underworld” of the browser handle this function without forcing it onto the stack. This works because Web APIs are independent of JavaScript's runtime. This concept of having a third party handle code is what concurrency is all about. We use callbacks to make our programs dynamic and prevent the event loop from clogging up.
We’ve mentioned Web APIs and an event loop. There’s also a callback queue. If you’re getting slightly confused, don’t panic. The comic will explain everything.
Roles
- JavaScript runtime: a single customer service call operator. He reads from a script, makes the call, and files it onto the stack.
- Web APIs: a third party data store that holds a message for however long it is instructed to hold it.
- The callback queue: a loading dock for calls
- The event loop: a little green droid with one simple job — check if the stack is empty. If it’s empty, take an event from the queue and place it onto the stack. Continue to do so while the condition is true.
The Comic
On a very synchronous day, the data flow is restricted. The “call operator” or the JavaScript runtime has to manually log all of the calls. The call operator has no time to get to the more important functions, like calling his wife or rendering a web page.
On a very asynchronous day, all the call operator has to do is load all of the Web API functions, then he can leave the task to both the Web APIs and the mini droid aka the event loop. The Web APIs store the callbacks until they are ready to be staged onto the call back queue. All the event loop (mini droid) has to do is check if the stack is empty and place the callback onto the stack. Meanwhile, the call operator can focus on more important functions, like dinner with the wife.
Conclusion
You can see why JavaScript devs make a big fuss about callbacks. No one wants their runtime environment to be preoccupied with too many tasks. You can think of callbacks as Gwen Stefani’s “Hollaback Girl.” JavaScript's runtime sends a shout out to the Web APIs and performs other tasks while waiting for the hollaback, or, in our case, a callback.
Resources
Philip Robert’s awesome talk at JSConf EU 2014: https://www.youtube.com/watch?v=8aGhZQkoFbQ
Vector images were Designed by Freepik
Code in peace
Raji Ayinla,
Intern Content Writer at Codesmith Staffing
