JS Questions: What’s the Event Loop?

This is the eleventh in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

What’s the Event Loop?

Like any programming language, JavaScript has a specific process for handling function calls in a program, and more specifically, deciding when each function will run. Unlike other languages, JavaScript can be run in a browser, meaning that users may be interacting with the program by clicking a mouse or scrolling, for instance, simultaneous to other processes that are already running. The event loop helps create a fluid experience for users, by dictating a flow that allows for relatively long running processes to occur alongside client-side interactions.

Without features built into Node and browsers, JavaScript would only be able to handle one event at a time. Each function call would be added to a stack and one-by-one, popped off the top and run. It’s easy to imagine how this could become problematic in a web app. If a notice telling a user she had successfully updated her account were rendered to a webpage for three seconds using setTimeout, the user would not be able to interact with the page until the setTimeout had completed.

Some events do happen synchronously in JS. Loops will run in the call stack and prevent a webpage from re-rendering until they have completed.

However, due to the event loop built into browsers, processes such as AJAX requests and timeouts can run in the background, with their callback functions placed in a queue that are added to the call stack only when the entire stack has cleared. The below code snippet illustrates this.

If you paste this in your console, you’ll see 1 logged, then 2 returned, then 3 logged. Here’s what happens:

  1. The eventLoop function gets added to the call stack.
  2. The setTimeout timer begins and the callback function is added to the queue after 0 milliseconds.
  3. The number 1 is immediately logged.
  4. The eventLoop function returns 2 and the call stack is cleared.
  5. The setTimeout callback runs, logging 3.

Note that the call stack runs functions in ‘first in last out’ order (meaning that the first function added to a stack is the last to run). That’s why, in the code below, the strings are already concatenated when logged:

First, the greet function is added to the call stack. Then, the concat function is added to the call stack. Concat runs, the greeting is logged, and the greet function is cleared from the stack.

Meanwhile, the queue runs callback functions in ‘first in first out’ order. The first item added to the queue is the first to be added to the call stack. That means, if multiple AJAX requests are made, for instance, the first request to finish will be the first to have its callback function run.

In sum, the event loop in JavaScript refers to the synchronous and asynchronous flow dictated by the call stack and queue in browsers.




Going to Meetups

When I first started learning to code, I felt way under-qualified to attend programming-related events. I felt like an outsider to the field, and I figured I wouldn’t have much to say or even understand what other people were talking about.

Plus, networking-type functions are intimidating in general. Honestly, any event that requires mingling with strangers on a work night, when I could be running in the park, or getting drinks, or at least going home to change into yoga pants and make mac n cheese, is tough to get motivated to attend.

In September, I pushed myself to go to two Meetup events hosted by the Flatiron School, one called “Women in Tech” that featured a panel of recent graduates working as developers, and another where teams of students presented their projects.

Both times I had some hesitations. (What if I have to make awkward conversation? What if everyone else knows each other? What if it’s not worth my time? Shouldn’t I be at home learning to code instead of standing around talking about it?)

My fretting mostly went to waste because: 1) Awkwardness wasn’t really a problem. All I had to say was “Hi, I’m Rachel. Are you a student?” and that seemed to get the conversation flowing. 2) I underestimated how helpful it would be hearing from people tackling similar challenges to me. 3) Being a part of the developer community (or some very small corner of the community) makes learning to code, in so many ways, just–well– better.

With my brief experience, I’d say going to these types of events is like anything else: the more you do it, the less intimidating it becomes.