What We All Pretend to Know: The Differences Between the JS Engine & JS Runtime

Hi everyone, welcome to our talk. Today we're going to talk about what we all present to know, the difference between the JavaScript engine and the JavaScript runtime. Before we begin, my name is Sam and this is my co-speaker, Karina. We are both from New York, we both play tennis, we both went to the same high school, and we both currently work at Bloomberg as software engineers. And today we're both really excited to talk to you about JavaScript. Before we dive in, why are we giving this talk and why is it relevant to you? Modern JavaScript development is full of very useful frameworks that let you build and ship code really quickly. But these frameworks abstract away a lot of the low-level intricacies that make your code run. We think understanding what's going on under the hood will allow you to have a mental model of how your code is being executed so you can more easily write and debug your JavaScript code. JavaScript is technically a specification, that's all it is. ECMAScript is the name of the specification for JavaScript and it defines what JavaScript is. So what exactly does ECMAScript define? It defines the syntax, the available types, the operators, and language semantics. You can think of these as the rules for the characters that you actually type, like for, while, if, brackets, and so on. In addition to ECMAScript, there's also the engine which Karina will talk about, and that engine implements the specification. And then there's the runtime that takes the engine and allows you to run your code. And now I'll hand it over to Karina.

Yeah, so let's take a closer look at the engine. The MDN web docs have a definition for JavaScript engines. Simply put, they're just low-level programs that parse and execute JavaScript code. They also convert your high-level JavaScript into fast machine code that can be executed by the CPU for some code paths. And we'll go over how it does this by first taking a look at how the components of the engine process the JavaScript code.

So first, your JavaScript source code is passed into the parser. It parses that source code and turns it into a tree representation of the source code or the abstract syntax tree. Then that tree is passed into the interpreter which reads and executes engine-specific low-level instructions called byte code. JavaScript is a dynamic language, so types aren't known until runtime, and that makes it hard to optimize in advance, unlike languages like C or C++.

JavaScript interpreters do a couple of things. One, they execute the byte code step by step. But as they do that, they also gather type information and profiling data, which includes information like function call frequency, argument shapes, and when a function is called frequently, which we call a hot function or a hot code path, the engine identifies it as worth optimizing. As the optimizing compiler optimizes your code, it relies on assumptions based on how your code has behaved so far.

And the compiler will use that information to create highly optimized machine code to be executed by the CPU directly. And there are a few methods that the compiler employs to generate this fast machine code. It uses type specialization, which is basically generating machine code tailored to the actual data types used at runtime. It uses function inlining, where it replaces small functions with their actual bodies on the call site, and also loop unrolling.

As the optimizing compiler optimizes your code, it relies on assumptions based on how your code has behaved so far. So it might see that a variable is always a number, or it might notice that an object always has the same structure, and these help the engine generate that highly efficient machine code and skip runtime checks. However, if an assumption breaks, that optimized machine code is discarded and the original byte code is sent back to the interpreter. So this can be time-consuming, and frequent deoptimizations due to unstable code patterns can add significant overhead.

There are a couple of things that we as developers can do to prevent the assumptions from breaking. One assumption that your engine makes is that variables and function parameters are consistently used with the same types. So we can ensure type stability by keeping our functions monomorphic, and that helps your engines use inline caches to remember the structure of the function. Another example is using type-stable arrays, or arrays where all of the elements are of the same type, for example, numbers, and that allows the engine to use special internal representations that are broken when you introduce a mixed type.

So we want to make sure that we always use the same types of input. Another example is using type-stable arrays, or arrays where all of the elements are of the same type, for example, numbers, and that allows the engine to use special internal representations that are broken when you introduce a mixed type. The engine also loves consistent object shapes. It assumes that they follow the same internal structure and create hidden classes based on things like property names and property order. So we can avoid adding properties after object construction. Adding an attribute alone doesn't guarantee that it will break the assumptions, it largely depends on the context and whether it changes the hidden class shape, but as a general rule of thumb, you want to keep object shapes consistent. You also want to avoid megamorphic call sites, which is function calls or property access that uses different types or shapes at runtime. We want to keep it consistent because optimizers can't inline a function if it's unclear which version is being called. And the engine also loves it when hot-code functions are predictable. We can help make them predictable by avoiding function declarations in loops to reduce scope complexity. Creating closures repeatedly makes the just-in-time compiler treat them as new every time, and that breaks optimization. We can also use pure, short, and inlinable functions. So avoid side effects and avoid relying on or changing anything outside of the function scope to keep the functions pure. So in short, keep your functions pure, short, and type stable, and use tools such as the node trace opt flag to monitor what is being optimized and deoptimized to improve your performance. And that way you'll keep your engine happy and help it to optimize your code.

Now I'll pass it back to Sam. Thanks, Karina. So let's go into the runtime a little bit. What is the runtime? The runtime The runtime is just code. Just like the engine is low-level code that Karina just talked about, the runtime is also low-level code. It's code that does three main things. It invents the engine, it adds extra API calls for the specific environment that you're running in, and then it manages the event loop. So on the right, we have a made-up example of a runtime that we're going to go over in each of the steps right now. But before we begin, what are some widely used runtimes? The two most popular ones are Node, which is what you use to program JavaScript on the back end, and then there's Browser, which we're all familiar with. Every browser that you've probably used, Chrome, Firefox, Safari, has its own unique JavaScript runtime. So what does it mean for a runtime to embed the engine? If we take Node as an example, Node is a runtime that's implemented in C++, and you can see on the right that it is importing something called V8. V8 is the engine that the Node runtime uses, and V8 exposes an API for embedding. So if you were to make your own runtime with V8 as the engine, you could import that and then instantiate it, and now you have that as the engine for your runtime. And the runtime also adds APIs. Why do we need APIs in a runtime? We need them because JavaScript behaves very differently in the different environments that it runs on.

When JavaScript is running in Node on a back-end server, it needs to do very different things than what JavaScript would need to do if it's running on the browser on your computer, free to access a website. In order to do this, that's when the runtime implements these APIs, and to do that, in your low-level code, you could define a function, and then after that, you would do two things. You would define a binding, which allows you to expose that function that you write in C++, or C, or another low-level language, and then two, after you define the binding, you can then call it in JavaScript. So we talked about Node in the browser. What are some common runtime APIs for Node? In Node, you want to be able to access the file system with FS, you want to get system-level info like CPU or memory info, you can do that with the OS API, and then you also want to create services using HTTP and HTTPS. If you are using JavaScript on a browser, and you're on a browser runtime, you want to do very different things. You want to be able to interact with HTML via the DOM, you want to make network requests using Fetch, and then you want to store things in your browser using local storage and session storage. There are a lot of other runtimes and engines. This is not a complete list, but a few runtimes and engines you should know about. There's Deno, Bun, and Electron, those are runtimes, and then for engines, there's V8, there's JavaScript Core, and then there's V8 Plus Chromium.

So far, we've covered the two things that the runtime does. The third most important thing, not the most important thing, but a very important thing, is the event loop. What is the event loop? Well, the runtime used the event loop to determine when to run your code. The event loop is just additional code that's part of the runtime that you write, and some event loops are even libraries. Like Node uses the liduv library of the event loop, which is a C++ library that you can embed in your own code. In order to understand what the event loop is doing, there are four components that we want to keep in mind. There's the actual event loop itself, which is the code that's written in the runtime. There's a call stack, which is where your code is actually executed, and then there are two queues, the microtask queue and the task queue, that is also referred to as the macro task queue. And these all combine with the runtime, the engine, and all the other components to execute your code. So on the right we have pseudocode that's showing what happens at a high level. What's happening is that the event loop checks to see if the call stack is empty. If it is, it takes everything from the microtask queue and places that onto the call stack for that code to be executed. And then once all of the items from the microtask queue are done, it takes one item from the task queue or the macro task queue, puts that into the call stack to be executed. So the event loop is a continuously running process you can think of that monitors the call stack and the queue to decide when code is executed. And this is the primary way JavaScript behaves asynchronously, even though it is single-threaded.

To recap, the engine is a low-level code that executes JavaScript. Similarly to the engine, the runtime is also low-level code and it allows your code to be run. Thank you for listening to our talk.