JavaScript Engine Internals: how your code actually runs

Every line of JS has to run somewhere, every variable has to live somewhere, every function call has to come back to where it was called from. The engine keeps all of this in two structures - the execution context (where am I now) and the call stack (where did I come from). They're what closure, this, and async are all built on.

The textbook explanation says declarations 'move to the top' of the code. The ECMA-262 spec doesn't define hoisting as a mechanism at all, and let behaves as if the rule didn't apply to it. So what really happens before your code runs, and why does the TDZ look exactly the way it does?

Functions in JS usually disappear together with their local memory. Closure breaks that rule - and it is the foundation for the module pattern, memoization, asynchronous JS, and private state without classes.

this in JS only looks weird because people look in the wrong place. Its value is decided at the moment of the call - and there are only four rules the call can pick from, plus arrow functions, which break out of the whole system.

The new keyword in JS looks short, but behind it the engine runs four steps at once - creates an empty object, hooks up this, links it to the function's prototype, and returns the whole object back. Without new, you'd write the same thing by hand with Object.create.

Every object you create in JS takes up space in computer memory. JavaScript removes unused objects automatically, making room for new ones. But the engine sometimes can't tell that a given object is no longer needed - and then the object stays in memory. That's how memory leaks happen. A post about how this cleanup works (mark-and-sweep), the most common pitfalls, and when you actually reach for WeakMap or WeakRef.