JavaScript Event Loop – how does it work?

If you – like me – have ever wondered how JavaScript is able to handle callbacks and do stuff asynchronously, wonder no more, but take a look at this brilliant video by Philip Roberts:

I really recommend watching the whole video. But if you don’t have the time for that, I try to give you a summary of the most important points:

JavaScript is:

  • single-threaded
  • non-blocking
  • asynchronous
  • concurrent

JavaScript has:

  • call stack
  • event loop
  • callback queue
  • access to Web APIs offered by the browser

JavaScript is run by a JavaScript Engine. Each browser has its own implementation of it. Chrome i.e. uses its V8 JS Engine, Firefox is using SpiderMonkey and Microsoft Edge uses an Engine called Chakra.

Each of these engines is implemented on its own and has its own pros and cons.

Async with JavaScript

Although JavaScript always gets executed in just one single thread, it is possible to call methods asynchronously (non-blocking). This is actually crucial for time demanding functions, as they would otherwise block the execution of all the other code.

So how does that work if JavaScript is always running single-threaded you may ask? Actually this is possible by using Web APIs that are implemented in the browser, which handle the whole concurrency stuff. So you do have concurrency in the way JavaScript is executed, but you cannot directly control it, only by using the Web APIs of the browser.

This is explained very nicely at around 12:02 in the video.

Philip Roberts even wrote a web tool to simulate how JavaScript code is being run. It is called Loupe and it does a pretty good job at visualizing everything that happens behind the scenes. No worries, he even explains how to use the tool in the video.

You can also check out the presentation by Thomas Hunter if you want to get more information on this topic.

I have to say, this video opened my eyes. And I have a much better understanding now of what goes on under the surface of my browser.

ES5, ES6, ES2016? – JavaScript versioning

JavaScript vs ECMA script

To get to understand the confusing version names, it may help to look where JavaScript got its name from and who the people are who are maintaining it.

JavaScript initially got released in 1995 as part of Netscape Navigator. First it was named LiveScript, but then renamed to JavaScript in the hopes that it could benefit from the popularity of Java, although it never had any connections to that language.

In 1996 Netscape submitted JavaScript to ECMA International¹ for standardisation. This eventually resulted in a new language standard, labeled ECMAScript. All JavaScript implementations since, have actually been implementations of the ECMAScript standards. However, out of marketing reasons and commodity, the language still gets referred to as JavaScript.

Mostly when talking about ECMAScript, people are talking about the standard, while when talking about JavaScript they are referring the practical use of the language.


  • ECMAScript 5 (ES5): The 5th edition of ECMAScript, standardized in 2009. This standard has been implemented fairly completely in all modern browsers
  • ECMAScript 6 (ES6)/ ECMAScript 2015 (ES2015): The 6th edition of ECMAScript, standardized in 2015. This standard has been partially implemented in most modern browsers. To see the state of implementation by different browsers and tools, check out these compatibility tables.
  • ECMAScript 2016: The expected 7th edition of ECMAScript. This is scheduled to be released next summer. The details of what the spec will contain have not been finalized yet
  • ECMAScript Proposals: Proposed features or syntax that are being considered for future versions of the ECMAScript standard. These move through a process of five stages: Strawman, Proposal, Draft, Candidate and Finished.

This list has been copied 1:1 from Ben McCormicks Blog post because It was just perfect as it was already 😉

¹ ECMA International was founded 1961 and stood for European Computer Manufacturers Association. In 1994 however, they got rid of the meaning and just stuck with ECMA International to underline the international importance of the organisation. They also maintain the standards for C# and other .NET components. Their headquarters are located in Geneva, Switzerland.

Sources & further information