Unlike C and other compiled languages, Javascript runs in a container - a program that reads your js codes and runs them. This program must do two things

• parse your code and convert it to runnable commands
• provide some objects to javascript so that it can interact with the outside world.

The first part is called Engine and the second is Runtime.

For example, the Chrome Browser and node.js use the same Engine - V8, but their Runtimes are different: in Chrome you have the window, DOM objects etc, while node gives you require, Buffers and processes.

Imagine a robot is playing a music:

• The JavaScript code would be the music notes to the robot.
• TheJavaScript engine would be the robot which can understand the notes and act on it.
• The JavaScript runtime would be the instruments the robot can use in order to play the music.

Imagine a robot is putting out a fire:

• The JavaScript code would be the instructions to the robot to put out a fire.
• The JavaScript engine would be the robot which can understand the instructions and act on it.
• The JavaScript runtime would be the fire truck, and the water gun.

Let's first imagine an Ahead-Of-Time compiled implementation of JavaScript.

The compiler will translate JavaScript code to, for example, native x86 machine code that you can run. However, there are some things in JavaScript which happen at runtime, and thus cannot be statically compiled. Garbage Collection, for example, or reflection. So, in order for the program to run, there need to be some kind of support services at runtime, such as the garbage collector and the reflection system. Also, JavaScript has eval, which means that (in our hypothetical compiled implementation) the compiler itself or some other interpreter needs to be available at runtime.

Let's call these things Runtime Support Services.

A second thing that needs to be available for the program, are objects such as Array, Function, Object, etc. and functions such as forEach. This collection of objects and functions that needs to be available to the program from the get-go, is typically called the Core Library or Base Library. For a language like JavaScript, which is designed to be embedded, there are also additional libraries which are assumed to be present, depending on the context. For example, for JavaScript embedded in a browser, we expect the DOM objects and functions and the global window and document objects and so on to exist. These may be considered part of the core library too.

And lastly, let's now forget about our hypothetical compiler and look at an interpreter (or JIT compiler or mixed-mode engine or bytecode VM). Here, the Interpreter (or JIT, or whatever) is the third piece of the puzzle. It's the thing that actually executes the JavaScript program. (Well, technically, a JIT doesn't execute, it compiles, and then something else executes.)

The terminology is not 100% clear: sometimes, only the Runtime Support Services are referred to as Runtime Environment, sometimes, the Core Library is included as well.

Execution Engine refers to either just the interpreter (JIT, VM, …) or the combination of interpreter and Runtime Environment. A compiler is never called an Execution Engine (it doesn't execute anything, just translate to another language), and the term Execution Engine is rarely used to refer to a statically compiled implementation.

The event loop is part of the host environment, not the JavaScript implementation.