Forem: Razumovsky

Event Loop in JavaScript: How Async Really Works

Razumovsky — Mon, 09 Feb 2026 20:14:03 +0000

JavaScript is single-threaded. There's only one call stack, one thread executing your code at any given time. Yet somehow you can make HTTP requests, set timers, handle user clicks, and your code doesn't freeze waiting for these operations.

How? The Event Loop.

Most explanations show you a diagram with boxes and arrows. We'll go deeper - let's understand what's actually happening when your async code runs.

The Mental Model: JavaScript Runtime Architecture

JavaScript doesn't run in isolation. The runtime (browser or Node.js) consists of:

1. The JavaScript Engine (V8, SpiderMonkey, etc.)

Call Stack: Where your synchronous code executes
Heap: Where objects live

2. Web APIs / C++ APIs (browser/Node.js)

Timer APIs (setTimeout, setInterval)
Network APIs (fetch, XMLHttpRequest)
File system, crypto, etc. (Node.js)

3. Task Queues

Macrotask Queue (also called Task Queue or Callback Queue)
Microtask Queue

4. The Event Loop

Coordinates everything

Here's the crucial part: When you call setTimeout, you're not calling a JavaScript function. You're calling a Web API that runs outside the JavaScript engine. The event loop bridges the gap between the engine and these external APIs.

The Event Loop: What It Actually Does

The event loop is a simple infinite loop that does one thing:

while (true) {
  if (callStack.isEmpty()) {
    if (microtaskQueue.hasItems()) {
      microtaskQueue.executeNext();
    } else if (macrotaskQueue.hasItems()) {
      macrotaskQueue.executeNext();
    }
  }
}

That's it. The event loop constantly checks: "Is the call stack empty? If yes, is there work in the queues?"

Let's trace through a real example:

console.log('Start');

setTimeout(() => {
  console.log('Timeout');
}, 0);

Promise.resolve().then(() => {
  console.log('Promise');
});

console.log('End');

Output:

Start
End
Promise
Timeout

Let's see why.

Phase-by-Phase Execution

Phase 1: Synchronous Code Runs

console.log('Start'); // Executes immediately

Call Stack: [console.log] → executes → prints "Start" → pops off

Phase 2: setTimeout

setTimeout(() => { console.log('Timeout'); }, 0);

This doesn't execute the callback. Instead:

setTimeout is called (pushed to call stack)
The browser's timer API is invoked with the callback
setTimeout immediately returns and is popped from the stack
The timer API starts a 0ms timer in the background (separate thread)
When the timer expires, the callback is placed in the Macrotask Queue

Call Stack: [setTimeout] → pops off
Macrotask Queue: [] (callback will arrive here after ~0ms)

Phase 3: Promise

Promise.resolve().then(() => { console.log('Promise'); });

Promise.resolve() creates an already-resolved promise
.then() schedules a callback
The callback goes into the Microtask Queue (not macrotask!)

Call Stack: [Promise.resolve, .then] → pops off
Microtask Queue: [() => console.log('Promise')]

Phase 4: More Synchronous Code

console.log('End');

Call Stack: [console.log] → executes → prints "End" → pops off

Phase 5: Call Stack Empty - Event Loop Wakes Up

Now the call stack is empty. The event loop starts working:

Check Microtask Queue first (always has priority!)
- Found: () => console.log('Promise')
- Push to call stack → execute → prints "Promise"
- Microtask Queue is now empty
Check Macrotask Queue
- By now, the timer has expired and placed its callback here
- Found: () => console.log('Timeout')
- Push to call stack → execute → prints "Timeout"

Final output: Start, End, Promise, Timeout

Microtasks vs Macrotasks: The Priority System

The event loop always processes all microtasks before moving to the next macrotask.

Macrotasks (Task Queue):

setTimeout
setInterval
setImmediate (Node.js only)
I/O operations
UI rendering (browser)

Microtasks:

Promise.then/catch/finally
queueMicrotask()
MutationObserver (browser)
process.nextTick (Node.js - special case, even higher priority!)

Example showing priority:

setTimeout(() => console.log('Timeout 1'), 0);

Promise.resolve().then(() => {
  console.log('Promise 1');

  Promise.resolve().then(() => {
    console.log('Promise 2');
  });
});

setTimeout(() => console.log('Timeout 2'), 0);

Promise.resolve().then(() => {
  console.log('Promise 3');
});

Output:

Promise 1
Promise 3
Promise 2
Timeout 1
Timeout 2

Why?

All synchronous code runs first (nothing to log)
Call stack empty → Event loop checks microtasks
Promise 1 executes, schedules Promise 2 (added to microtask queue)
Promise 3 executes
Promise 2 executes (microtask queue must be empty before macrotasks!)
Now microtask queue is empty → move to macrotasks
Timeout 1 executes
Timeout 2 executes

Node.js Event Loop: More Complex Phases

In Node.js, the event loop has specific phases that execute in order:

   ┌───────────────────────────┐
┌─>│           timers          │ <- setTimeout, setInterval
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │ <- I/O callbacks deferred from previous cycle
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │ <- internal use only
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           poll            │ <- retrieve new I/O events
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           check           │ <- setImmediate callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │      close callbacks      │ <- socket.on('close', ...)
│  └───────────────────────────┘
└──────────────────────────────────

Between each phase: All microtasks are processed.

Timers Phase

Executes callbacks scheduled by setTimeout and setInterval whose timers have expired.

Important: The timer specifies the minimum delay, not a guarantee:

setTimeout(() => console.log('100ms'), 100);

If the event loop is busy (executing a long task), the callback might run after 150ms, 200ms, etc.

Poll Phase

This is where Node.js spends most of its time. The poll phase:

Executes I/O callbacks (file reads, network requests, etc.)
If no callbacks, waits for new events (blocking, but can be interrupted)

When I/O completes (file read finishes, HTTP response arrives), the callback is placed in the poll queue.

Check Phase: setImmediate

setImmediate is like setTimeout(fn, 0) but with a guarantee: it always runs after the poll phase.

const fs = require('fs');

fs.readFile('file.txt', () => {
  setTimeout(() => console.log('setTimeout'), 0);
  setImmediate(() => console.log('setImmediate'));
});

Output:

setImmediate
setTimeout

Why? Inside an I/O callback (poll phase), setImmediate executes in the next check phase, while setTimeout has to wait until the next timers phase (next cycle of the event loop).

process.nextTick: The Priority Microtask

In Node.js, process.nextTick is special. It has even higher priority than regular microtasks:

Promise.resolve().then(() => console.log('Promise'));
process.nextTick(() => console.log('nextTick'));

Output:

nextTick
Promise

The execution order in Node.js:

Synchronous code
process.nextTick queue (completely drain)
Microtask queue (completely drain)
Next event loop phase

Warning: You can starve the event loop:

function recurse() {
  process.nextTick(recurse);
}
recurse();

This will block the event loop forever because the nextTick queue never empties - I/O callbacks will never run!

I/O Operations: How They Actually Work

When you read a file in Node.js:

const fs = require('fs');

console.log('Start');

fs.readFile('data.txt', (err, data) => {
  console.log('File read');
});

console.log('End');

What happens:

fs.readFile is called (synchronous part)
Node.js delegates to libuv (C++ layer)
libuv uses the OS's async I/O or a thread pool
fs.readFile returns immediately (non-blocking)
JavaScript continues executing (console.log('End'))
When the file read completes (in background), libuv notifies the event loop
The callback is placed in the poll queue
Event loop picks it up and executes it

Output:

Start
End
File read

The I/O happens in parallel (separate thread/OS), but the callback runs on the main JavaScript thread.

Practical Example: Ordering Chaos

setTimeout(() => console.log('1'), 0);

setImmediate(() => console.log('2'));

Promise.resolve().then(() => console.log('3'));

process.nextTick(() => console.log('4'));

console.log('5');

Output:

Execution order:

Synchronous: 5
nextTick queue: 4
Microtask queue: 3
Macrotask (timer phase): 1
Check phase: 2

(Note: Outside I/O callbacks, the order of setTimeout vs setImmediate can vary)

Visualizing Async Flow

console.log('A');

setTimeout(() => {
  console.log('B');
  Promise.resolve().then(() => console.log('C'));
}, 0);

Promise.resolve()
  .then(() => console.log('D'))
  .then(() => console.log('E'));

console.log('F');

Execution trace:

Sync Phase:

A prints
setTimeout registers callback in macrotask queue
Promise chain starts, D callback → microtask queue
F prints

Microtask Phase:

D prints, schedules E → microtask queue
E prints
Microtask queue empty

Macrotask Phase:

setTimeout callback executes
B prints
Promise callback → microtask queue

Microtask Phase (again!):

C prints

Output: A, F, D, E, B, C

Common Pitfalls

1. Assuming setTimeout(fn, 0) runs immediately:

let x = 0;
setTimeout(() => { x = 1; }, 0);
console.log(x); // 0, not 1!

The callback runs after synchronous code completes.

2. Infinite microtask loops:

function loop() {
  Promise.resolve().then(loop);
}
loop(); // Blocks event loop!

Each promise schedules another microtask. Macrotasks never get a chance to run.

3. Heavy computation blocking the loop:

setTimeout(() => console.log('Never runs?'), 100);

// Block for 5 seconds
const start = Date.now();
while (Date.now() - start < 5000) {}

The setTimeout callback won't run until the while loop finishes, even though 100ms passed long ago.

Summary

The event loop is JavaScript's solution to single-threaded async:

Key Points:

JavaScript executes synchronous code first
Async APIs (timers, I/O) run outside JavaScript, notify when done
Callbacks go into queues: microtasks (promises) or macrotasks (setTimeout, I/O)
Event loop processes all microtasks before any macrotask
In Node.js: specific phases (timers → poll → check), microtasks run between phases
process.nextTick has highest priority (use carefully!)

Mental model:

Sync code runs to completion
Drain all microtasks
Take one macrotask
Drain all microtasks again
Repeat

Understanding this helps you:

Predict execution order
Avoid blocking the event loop
Debug async race conditions
Write performant async code

Next time you see a setTimeout or a Promise, you'll know exactly when that code will run - and why.

Understanding 'this' in JavaScript: Execution Context Explained

Razumovsky — Sun, 01 Feb 2026 09:59:02 +0000

this is one of the most confusing concepts in JavaScript. You've probably seen code like this break unexpectedly:

const user = {
  name: 'Alice',
  greet() {
    console.log('Hello, ' + this.name);
  }
};

user.greet(); // "Hello, Alice" ✓

const greet = user.greet;
greet(); // "Hello, undefined" ✗

Same function, different results. Why?

The answer: this is not determined by where a function is defined, but by how it's called. Let's understand what that really means and how JavaScript determines this at the engine level.

What is 'this'? A Binding, Not a Variable

First, let's clear up a misconception: this is not a variable. You can't reassign it like this = something. It's a special binding that gets set when a function is invoked.

When JavaScript creates an Execution Context (which happens every time you call a function), it sets up:

Variable Environment (local variables)
Lexical Environment (scope chain)
ThisBinding - what this points to

The value of this is determined by looking at how the function was called - specifically, the call-site.

The Four Rules of 'this' Binding

There are four main ways this gets bound, in order of precedence:

new binding (constructor calls)
Explicit binding (call, apply, bind)
Implicit binding (method calls)
Default binding (standalone function calls)

Let's dive into each one.

Rule 1: Default Binding (Standalone Function Calls)

When you call a function as a standalone function (not as a method, not with new, not with call/apply/bind), this defaults to the global object (or undefined in strict mode).

function showThis() {
  console.log(this);
}

showThis(); // Window (in browser) or global (in Node.js)

What happens internally:

JavaScript creates an Execution Context for showThis
Looks at the call-site: showThis() - no object, no new, no explicit binding
Applies default binding: ThisBinding = globalObject

In strict mode:

'use strict';

function showThis() {
  console.log(this);
}

showThis(); // undefined

Strict mode changes the default binding from global to undefined. This prevents accidental global pollution.

Why your original example broke:

const user = {
  name: 'Alice',
  greet() {
    console.log('Hello, ' + this.name);
  }
};

const greet = user.greet;
greet(); // "Hello, undefined"

When you extract the method and call it standalone, it's just a regular function call. Default binding applies → this = globalObject (or undefined in strict mode) → this.name is undefined.

Rule 2: Implicit Binding (Method Calls)

When you call a function as a method of an object (using dot notation or bracket notation), this binds to that object.

const user = {
  name: 'Alice',
  greet() {
    console.log(this.name);
  }
};

user.greet(); // "Alice"

What happens internally:

JavaScript evaluates user.greet - finds the function
Creates an Execution Context for that function
Looks at the call-site: user.greet() - called on user object
Sets ThisBinding = user

The rule: The object immediately to the left of the dot (or bracket) becomes this.

Nested Objects: Only the Last Level Matters

const obj = {
  level1: {
    level2: {
      method() {
        console.log(this);
      }
    }
  }
};

obj.level1.level2.method(); // this = level2 (not obj, not level1)

Only level2 (the immediate parent) becomes this, because that's what's directly to the left of the final dot before the call.

Implicit Binding Loss: The Common Trap

const user = {
  name: 'Alice',
  greet() {
    console.log(this.name);
  }
};

setTimeout(user.greet, 1000); // "undefined" (or error in strict mode)

Why does this fail?

When you pass user.greet to setTimeout, you're passing a reference to the function, not calling it. Inside setTimeout, roughly this happens:

function setTimeout(callback, delay) {
  // ... wait for delay ...
  callback(); // Called as standalone function!
}

The function is called without an object, so default binding applies.

Solutions:

1. Arrow function wrapper:

setTimeout(() => user.greet(), 1000); // "Alice"

The arrow function calls user.greet() with the object, preserving implicit binding.

2. bind() (we'll cover this soon):

setTimeout(user.greet.bind(user), 1000); // "Alice"

Rule 3: Explicit Binding (call, apply, bind)

JavaScript gives you three methods to explicitly set this: call, apply, and bind.

call() and apply()

function greet(greeting, punctuation) {
  console.log(greeting + ', ' + this.name + punctuation);
}

const user = { name: 'Alice' };

greet.call(user, 'Hello', '!'); // "Hello, Alice!"
greet.apply(user, ['Hello', '!']); // "Hello, Alice!"

What happens with call():

call invokes the function immediately
First argument (user) becomes this
Remaining arguments are passed to the function

call vs apply: Only difference is argument passing:

call: arguments listed individually
apply: arguments as an array

Under the hood:

// Conceptually, call does this:
Function.prototype.call = function(thisArg, ...args) {
  // Set this function's ThisBinding to thisArg
  // Invoke the function with args
  // Return the result
};

bind(): Creating a Hard-Bound Function

function greet() {
  console.log(this.name);
}

const user = { name: 'Alice' };
const boundGreet = greet.bind(user);

boundGreet(); // "Alice"

// Even if you try to change this, it won't work:
const other = { name: 'Bob' };
boundGreet.call(other); // Still "Alice"!

What bind does:

bind returns a new function with this permanently bound. No matter how you call it later, this will always be what you bound it to.

Polyfill (simplified) to understand what bind does:

Function.prototype.bind = function(thisArg, ...fixedArgs) {
  const originalFunction = this;

  return function boundFunction(...callArgs) {
    return originalFunction.apply(
      thisArg,
      [...fixedArgs, ...callArgs]
    );
  };
};

It returns a new function that, when called, invokes the original function with a fixed this value.

This is why bind solves the setTimeout problem:

setTimeout(user.greet.bind(user), 1000);

bind returns a new function that always calls user.greet with this = user, no matter how setTimeout calls it.

Rule 4: new Binding (Constructor Calls)

When you call a function with new, JavaScript does something special:

function User(name) {
  this.name = name;
  this.greet = function() {
    console.log('Hello, ' + this.name);
  };
}

const alice = new User('Alice');
alice.greet(); // "Hello, Alice"

What happens when you use new:

Create a new empty object: {}
Set the object's [[Prototype]] to User.prototype
Execute User with this bound to the new object
If User doesn't return an object, return the new object

// Conceptually:
function User(name) {
  // const this = {}; (done by 'new')
  // this.[[Prototype]] = User.prototype; (done by 'new')

  this.name = name;
  this.greet = function() {
    console.log('Hello, ' + this.name);
  };

  // return this; (done by 'new' if you don't return an object)
}

new has the highest precedence (except for explicit arrow function binding, which we'll cover next).

function test() {
  console.log(this.value);
}

const obj = { value: 42 };
const boundTest = test.bind(obj);

boundTest(); // 42

new boundTest(); // undefined (creates new object, ignores bind)

Even though test was bound to obj, new creates a fresh object and binds this to that instead.

Arrow Functions: Lexical 'this'

Arrow functions completely break all these rules. They don't have their own this binding at all.

const user = {
  name: 'Alice',
  greet: () => {
    console.log(this.name);
  }
};

user.greet(); // undefined (or error)

Why?

Arrow functions use lexical this - they inherit this from the enclosing scope at the time they're defined, not when they're called.

const user = {
  name: 'Alice',
  greet: () => {
    // 'this' here is the 'this' from the scope where this arrow function was created
    // That's the global scope (where the object literal was evaluated)
    console.log(this.name);
  }
};

The arrow function was created in the global scope, so this inherits from there (global object or undefined).

When arrow functions are useful:

const user = {
  name: 'Alice',
  delays: [1000, 2000, 3000],

  start() {
    this.delays.forEach(delay => {
      setTimeout(() => {
        console.log(this.name + ' after ' + delay + 'ms');
      }, delay);
    });
  }
};

user.start();
// "Alice after 1000ms"
// "Alice after 2000ms"
// "Alice after 3000ms"

The arrow functions in forEach and setTimeout don't create their own this - they use the this from start(), which is user (implicit binding).

Without arrow functions, you'd need:

start() {
  const self = this; // Capture this
  this.delays.forEach(function(delay) {
    setTimeout(function() {
      console.log(self.name + ' after ' + delay + 'ms');
    }, delay);
  });
}

Important: You can't change an arrow function's this with call, apply, or bind:

const arrow = () => console.log(this.name);
const obj = { name: 'Alice' };

arrow.call(obj); // this is still global/undefined, not obj

Precedence: When Rules Conflict

When multiple rules apply, here's the priority (highest to lowest):

Arrow function - always uses lexical this, can't be overridden
new - creates new object and binds to it
Explicit binding (call/apply/bind) - you explicitly set this
Implicit binding - method call on an object
Default binding - global or undefined

Example:

function test() {
  console.log(this.value);
}

const obj1 = { value: 1 };
const obj2 = { value: 2 };

const bound = test.bind(obj1);
bound.call(obj2); // 1 (bind wins over call)

bind creates a hard-bound function that can't be overridden by call.

Real-World Scenarios

Event Handlers in DOM

const button = document.getElementById('myButton');

button.addEventListener('click', function() {
  console.log(this); // The button element
});

Browser event handlers set this to the element that triggered the event (implicit binding).

With arrow function:

button.addEventListener('click', () => {
  console.log(this); // Window or undefined (lexical this)
});

Class Methods

class User {
  constructor(name) {
    this.name = name;
  }

  greet() {
    console.log('Hello, ' + this.name);
  }
}

const alice = new User('Alice');
alice.greet(); // "Hello, Alice"

const greet = alice.greet;
greet(); // Error: Cannot read 'name' of undefined

Class methods are not automatically bound. To fix:

Solution 1: Arrow function (in constructor):

class User {
  constructor(name) {
    this.name = name;
    this.greet = () => {
      console.log('Hello, ' + this.name);
    };
  }
}

Solution 2: Bind in constructor:

class User {
  constructor(name) {
    this.name = name;
    this.greet = this.greet.bind(this);
  }

  greet() {
    console.log('Hello, ' + this.name);
  }
}

Solution 3: Class field (modern JavaScript):

class User {
  name;

  greet = () => {
    console.log('Hello, ' + this.name);
  }

  constructor(name) {
    this.name = name;
  }
}

React Components (Classic Pattern)

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };

    // Must bind or increment won't have correct 'this'
    this.increment = this.increment.bind(this);
  }

  increment() {
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return (
      <button onClick={this.increment}>
        Count: {this.state.count}
      </button>
    );
  }
}

Without binding, this.increment passed to onClick loses its context (implicit binding loss).

Common Mistakes and Debugging

Mistake 1: Extracting methods

const obj = {
  value: 42,
  getValue() { return this.value; }
};

const getValue = obj.getValue;
console.log(getValue()); // undefined

Fix: Keep the object reference or use bind:

console.log(obj.getValue()); // 42
// or
const getValue = obj.getValue.bind(obj);
console.log(getValue()); // 42

Mistake 2: Callback context loss

const obj = {
  values: [1, 2, 3],
  double() {
    return this.values.map(function(v) {
      return v * this.multiplier; // this.multiplier is undefined!
    });
  },
  multiplier: 2
};

Fix: Arrow function or bind:

double() {
  return this.values.map(v => v * this.multiplier);
}

Mistake 3: Arrow functions as methods

const obj = {
  value: 42,
  getValue: () => this.value // this is NOT obj!
};

Fix: Use regular function for methods:

const obj = {
  value: 42,
  getValue() { return this.value; }
};

How to Debug 'this'

When this isn't what you expect:

Find the call-site - where is the function actually called?
Check how it's called:
- Is it object.method()? → implicit binding
- Is it func()? → default binding
- Is it new func()? → new binding
- Is it func.call/apply/bind? → explicit binding
- Is it an arrow function? → lexical this
Apply the precedence rules

Add logging:

function test() {
  console.log('this is:', this);
  console.log('this.constructor.name:', this.constructor.name);
  // Your actual code
}

Summary: 'this' is All About the Call-Site

Key takeaways:

Four binding rules (in precedence order):

new binding: this = newly created object
Explicit binding: this = what you passed to call/apply/bind
Implicit binding: this = object before the dot
Default binding: this = global object (or undefined in strict mode)

Arrow functions:

Don't have their own this
Inherit this from enclosing scope (lexically)
Can't be changed with call/apply/bind
Perfect for callbacks where you want to preserve this

Common patterns:

Use arrow functions for callbacks
Use regular functions for methods
Bind methods in constructors if passing them around
Remember: extraction loses context

The golden rule: To know what this is, find where the function is called (not where it's defined), and apply the binding rules.

Next time you see unexpected this behavior, trace the call-site and ask: "How is this function being invoked?" The answer will tell you exactly what this should be.

If you have a different mental model of this, or noticed an edge case worth discussing — share it in the comments!

Closures in JavaScript: Understanding Lexical Scope and Memory

Razumovsky — Sun, 25 Jan 2026 18:32:37 +0000

If you've been writing JavaScript for a while, you've definitely used closures - even if you didn't know it. Every callback, every event handler, every setTimeout involves closures. But what exactly is a closure, and why does JavaScript work this way?

The textbook definition is usually something like: "A closure is a function bundled together with references to its surrounding state (lexical environment)." But that doesn't explain the why or the how.

Let's dive deep into what closures actually are at the engine level, why they exist, and what problems they solve.

The Problem Closures Solve: Functions Need Context

Here's a simple example:

function createCounter() {
  let count = 0;

  return function increment() {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

This works, but... how? When createCounter() finishes executing, shouldn't count be destroyed? The function has returned, its execution context is gone. So how does increment still have access to count?

This is the fundamental question closures answer.

How JavaScript Executes Functions: The Call Stack and Execution Contexts

Before we can understand closures, we need to understand how JavaScript runs code.

When you call a function, JavaScript creates an Execution Context - a structure containing everything needed to run that function:

Variable Environment: Where local variables live
Lexical Environment: Where the function "looks up" variables (more on this soon)
this binding: What this points to
Outer Environment Reference: A link to the parent scope

These execution contexts are pushed onto the Call Stack. When a function returns, its execution context is popped off the stack.

function outer() {
  let x = 10;
  inner();
}

function inner() {
  console.log('Hello');
}

outer();

Call Stack during execution:

3. inner() execution context  ← Currently executing
2. outer() execution context
1. Global execution context

When inner() returns, its context is popped:

2. outer() execution context  ← Back to executing outer
1. Global execution context

When outer() returns, its context is popped:

1. Global execution context  ← Back to global

So if execution contexts are destroyed when functions return, how do closures work?

The Secret: Lexical Environments Live on the Heap

Here's the key insight: Execution Contexts live on the call stack (temporary), but Lexical Environments live on the heap (permanent, until garbage collected).

When you create a function, that function gets a hidden internal property called [[Environment]]. This property stores a reference to the Lexical Environment where the function was created.

Let's trace through our counter example:

function createCounter() {
  let count = 0;

  return function increment() {
    count++;
    return count;
  };
}

const counter = createCounter();

Step 1: Call createCounter()

JavaScript creates an Execution Context for createCounter:

Call Stack:
  createCounter() execution context
  Global execution context

Heap:
  Lexical Environment A {
    Environment Record: { count: 0 }
    Outer Reference: → Global Lexical Environment
  }

Step 2: Create the increment function

When JavaScript encounters function increment(), it creates a function object and sets its [[Environment]] property:

Heap:
  Lexical Environment A {
    Environment Record: { count: 0 }
    Outer Reference: → Global
  }

  Function Object: increment
    [[Environment]]: → Lexical Environment A  // This is the closure!

The function object now has a permanent reference to Lexical Environment A.

Step 3: Return from createCounter()

const counter = createCounter();

The execution context for createCounter() is popped off the call stack. But Lexical Environment A stays in memory because the increment function still references it!

Call Stack:
  Global execution context

Heap:
  Lexical Environment A {
    Environment Record: { count: 0 }
    Outer Reference: → Global
  }

  Function Object: increment
    [[Environment]]: → Lexical Environment A

Global Lexical Environment {
  Environment Record: { 
    counter: → Function Object: increment
  }
}

Step 4: Call counter()

When you call counter() (which is increment), JavaScript:

Creates a new Execution Context for increment
Sets its Lexical Environment's outer reference to increment.[[Environment]] (Lexical Environment A)
Executes count++

To resolve count, JavaScript:

Looks in the current Environment Record (increment's local scope) - not found
Follows the outer reference to Lexical Environment A - found! count: 0
Increments it to 1
Returns 1

Heap:
  Lexical Environment A {
    Environment Record: { count: 1 }  // Updated!
    Outer Reference: → Global
  }

  Lexical Environment B (for this call to increment) {
    Environment Record: { }  // No local variables
    Outer Reference: → Lexical Environment A
  }

The next time you call counter(), it creates a new Execution Context, but that context's outer reference still points to the same Lexical Environment A, where count is now 1. So it increments to 2.

This is a closure: The increment function "closes over" the variables in Lexical Environment A, keeping them alive even after createCounter has returned.

Multiple Closures, Shared Environment

Here's where it gets interesting:

function createCounter() {
  let count = 0;

  return {
    increment() {
      count++;
      return count;
    },
    decrement() {
      count--;
      return count;
    },
    getCount() {
      return count;
    }
  };
}

const counter = createCounter();
console.log(counter.increment()); // 1
console.log(counter.increment()); // 2
console.log(counter.decrement()); // 1
console.log(counter.getCount());  // 1

All three methods share the same Lexical Environment:

Heap:
  Lexical Environment A {
    Environment Record: { count: 1 }
  }

  Function: increment
    [[Environment]]: → Lexical Environment A

  Function: decrement
    [[Environment]]: → Lexical Environment A

  Function: getCount
    [[Environment]]: → Lexical Environment A

They all close over the same count variable because they were all created in the same scope.

Multiple Closures, Separate Environments

But if you call createCounter again, you get a completely independent closure:

const counter1 = createCounter();
const counter2 = createCounter();

console.log(counter1.increment()); // 1
console.log(counter2.increment()); // 1
console.log(counter1.increment()); // 2
console.log(counter2.getCount());  // 1

Each call to createCounter() creates a new Lexical Environment:

Heap:
  Lexical Environment A {
    Environment Record: { count: 2 }
  }

  Lexical Environment B {
    Environment Record: { count: 1 }
  }

  counter1.increment [[Environment]]: → Lexical Environment A
  counter2.increment [[Environment]]: → Lexical Environment B

Each counter is completely isolated. This is why closures are powerful for creating private state.

The Loop Problem Revisited

Remember this classic problem?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Output: 3, 3, 3

Now you can see exactly why this happens. Let's trace the Lexical Environments:

During the loop:

Heap:
  Global Lexical Environment {
    Environment Record: { i: 0 }  // Then 1, then 2, then 3
  }

  Arrow Function 1
    [[Environment]]: → Global Lexical Environment

  Arrow Function 2
    [[Environment]]: → Global Lexical Environment

  Arrow Function 3
    [[Environment]]: → Global Lexical Environment

All three arrow functions close over the same Global Lexical Environment. When they execute 100ms later, they all read i from that environment, where it's now 3.

With let:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Output: 0, 1, 2

As we discussed in the var/let/const article, let in a loop creates a new Lexical Environment for each iteration:

Heap:
  Lexical Environment (iteration 0) {
    Environment Record: { i: 0 }
  }
  Arrow Function 1
    [[Environment]]: → Lexical Environment (iteration 0)

  Lexical Environment (iteration 1) {
    Environment Record: { i: 1 }
  }
  Arrow Function 2
    [[Environment]]: → Lexical Environment (iteration 1)

  Lexical Environment (iteration 2) {
    Environment Record: { i: 2 }
  }
  Arrow Function 3
    [[Environment]]: → Lexical Environment (iteration 2)

Each arrow function closes over a different environment with a different i.

Before let existed, the solution was to create a new scope manually:

for (var i = 0; i < 3; i++) {
  (function(j) {
    setTimeout(() => console.log(j), 100);
  })(i);
}
// Output: 0, 1, 2

The IIFE (Immediately Invoked Function Expression) creates a new Lexical Environment for each iteration, with its own j parameter. Each arrow function closes over its own j.

Practical Use Cases: Why Closures Matter

1. Data Privacy

JavaScript doesn't have private class fields (well, it does now with #, but closures were the original solution):

function createBankAccount(initialBalance) {
  let balance = initialBalance; // Private variable

  return {
    deposit(amount) {
      if (amount > 0) {
        balance += amount;
        return balance;
      }
    },
    withdraw(amount) {
      if (amount > 0 && amount <= balance) {
        balance -= amount;
        return balance;
      }
    },
    getBalance() {
      return balance;
    }
  };
}

const account = createBankAccount(100);
account.deposit(50);
console.log(account.getBalance()); // 150
console.log(account.balance); // undefined - can't access directly!

There's no way to access balance except through the methods. It's truly private because it only exists in the Lexical Environment that the methods close over.

2. Function Factories

function createMultiplier(multiplier) {
  return function(number) {
    return number * multiplier;
  };
}

const double = createMultiplier(2);
const triple = createMultiplier(3);

console.log(double(5)); // 10
console.log(triple(5)); // 15

Each returned function closes over its own multiplier value:

Heap:
  Lexical Environment A { multiplier: 2 }
  Lexical Environment B { multiplier: 3 }

  double [[Environment]]: → Lexical Environment A
  triple [[Environment]]: → Lexical Environment B

3. Callbacks and Event Handlers

function setupButton(buttonId, message) {
  const button = document.getElementById(buttonId);

  button.addEventListener('click', function() {
    console.log(message);
  });
}

setupButton('btn1', 'Button 1 clicked');
setupButton('btn2', 'Button 2 clicked');

Each click handler closes over its own message variable, even though setupButton has long since returned.

4. Memoization

function memoize(fn) {
  const cache = {};

  return function(...args) {
    const key = JSON.stringify(args);
    if (key in cache) {
      return cache[key];
    }

    const result = fn(...args);
    cache[key] = result;
    return result;
  };
}

const expensiveOperation = memoize((n) => {
  console.log('Computing...');
  return n * n;
});

console.log(expensiveOperation(5)); // Computing... 25
console.log(expensiveOperation(5)); // 25 (cached, no log)

The returned function closes over cache, which persists between calls.

Memory Leaks: When Closures Go Wrong

Closures keep Lexical Environments alive. This is usually good, but can cause memory leaks:

function attachHandler() {
  const data = new Array(1000000).fill('leak');

  document.getElementById('button').addEventListener('click', function() {
    console.log('Clicked');
  });
}

attachHandler();

Even though the click handler doesn't use data, the entire Lexical Environment (including data) is kept alive because the handler closes over it.

Modern engines optimize this: V8 and other engines detect when variables aren't actually used in closures and don't keep them in memory. But it's still something to be aware of.

Fix: Don't capture what you don't need:

function attachHandler() {
  const data = new Array(1000000).fill('leak');

  // Process data here if needed
  const result = processData(data);

  document.getElementById('button').addEventListener('click', function() {
    console.log('Clicked', result); // Only closes over result, not data
  });
}

Closures and `this`: A Common Pitfall

const obj = {
  name: 'Alice',
  greet() {
    setTimeout(function() {
      console.log('Hello, ' + this.name);
    }, 100);
  }
};

obj.greet(); // Hello, undefined

The problem: The function passed to setTimeout doesn't close over this. this is not a variable - it's determined by how a function is called, not where it's defined.

Solution 1: Arrow functions (which don't have their own this):

const obj = {
  name: 'Alice',
  greet() {
    setTimeout(() => {
      console.log('Hello, ' + this.name);
    }, 100);
  }
};

obj.greet(); // Hello, Alice

Solution 2: Capture this in a variable (the pre-ES6 way):

const obj = {
  name: 'Alice',
  greet() {
    const self = this;
    setTimeout(function() {
      console.log('Hello, ' + self.name);
    }, 100);
  }
};

obj.greet(); // Hello, Alice

Now self is a regular variable that the closure can capture.

How Engines Optimize Closures

You might think: "Doesn't keeping all these Lexical Environments around use a lot of memory?"

Modern JavaScript engines are very smart about closures:

1. Dead Variable Elimination: If a variable in a closure's environment is never used, the engine doesn't keep it in memory.

function outer() {
  let used = 1;
  let notUsed = new Array(1000000);

  return function() {
    return used;
  };
}

The engine sees that notUsed is never accessed in the closure and doesn't keep it alive.

2. Sharing Environments: If multiple functions are created in the same scope and use the same variables, they can share an Environment Record.

3. Scope Analysis: During compilation, the engine figures out exactly which variables each function needs and creates optimized structures.

Understanding Closures Through the Spec

The ECMAScript specification defines closures through these mechanisms:

§9.1 Environment Records: The spec defines exactly how variables are stored and accessed.

§9.4 Execution Contexts: Defines how contexts reference their outer environments.

§10.2 Function Objects: Specifies that functions have a [[Environment]] internal slot.

When you call a function:

Create a new Function Environment Record
Set its outer environment reference to the function's [[Environment]]
This creates the closure - the function can now access variables from where it was defined

Summary: Closures are Lexical Scope + Memory

A closure isn't magic - it's a natural consequence of how JavaScript implements lexical scope:

Functions store a reference to the Lexical Environment where they were created ([[Environment]])
Lexical Environments live on the heap, not the call stack
When a function executes, it can access variables from its [[Environment]], even if the original execution context is gone
Multiple functions created in the same scope share the same Lexical Environment
Each call to an outer function creates a new, independent Lexical Environment

Closures enable:

Private variables (data hiding)
Function factories (partial application)
Callbacks that remember context
Memoization and caching

Understanding closures at this level helps you:

Debug scope-related bugs
Avoid memory leaks
Write more efficient code
Understand React hooks, module patterns, and other advanced patterns

Next time you write a callback or return a function from a function, you'll know exactly what's happening in memory - and why your variables are still accessible.

var, let, const: Why JavaScript Needed Three Ways to Declare Variables

Razumovsky — Sun, 11 Jan 2026 09:53:01 +0000

If you're coming to JavaScript from another language, you might be confused. Why does JavaScript have three different keywords for declaring variables? Isn't one enough?

The answer isn't just "var is old, use let/const instead." There's a fundamental difference in how these keywords interact with JavaScript's execution model - specifically, how the engine creates and manages execution contexts and lexical environments.

Let's dig deep and understand what's actually happening when you declare a variable.

What Really Happens When JavaScript Runs Your Code

Before we talk about var, let, or const, we need to understand how JavaScript prepares to run your code.

When JavaScript enters any executable context (a function, a block, or global code), it goes through two phases:

Creation phase: Sets up the environment
Execution phase: Actually runs your code line by line

During the creation phase, JavaScript creates something called a Lexical Environment. Think of it as a data structure that consists of:

Environment Record: A place where variables and functions are stored
Outer reference: A link to the parent lexical environment (for scope chain)

Here's the critical part: var, let, and const interact with these structures completely differently.

var: Function-Level Environment Records

Let's trace through what happens with var:

function checkAge() {
  console.log(age); // undefined
  var age = 25;
  console.log(age); // 25
}

Creation Phase (before any code runs):

JavaScript creates a Function Environment Record for checkAge
It scans the entire function body looking for var declarations
For each var, it creates a property in the Environment Record and initializes it to undefined
The assignment (= 25) is not executed yet

So internally, the Environment Record looks like:

FunctionEnvironmentRecord {
  age: undefined  // created during setup
}

Execution Phase:

console.log(age) - reads from Environment Record → undefined
age = 25 - updates the existing property in Environment Record
console.log(age) - reads from Environment Record → 25

This is why var is "hoisted" - it's not that the declaration moves up, it's that the variable exists in the Environment Record from the very beginning of function execution.

The Block Scope Problem: Why var Ignores Blocks

function test() {
  if (true) {
    var x = 10;
  }
  console.log(x); // 10
}

Here's what's happening under the hood:

Creation Phase:

JavaScript creates one Function Environment Record for the entire test function
It finds var x inside the if block
It adds x: undefined to the Function Environment Record
The if block does not create its own Environment Record (for var)

Execution Phase:

Enters if block
x = 10 updates the x in the Function Environment Record
Exits if block (but the Environment Record stays - it's the function's record)
console.log(x) reads from the same Function Environment Record → 10

The specification doesn't give blocks their own Environment Records when you use var. Blocks are just control flow - they don't create new scopes.

The Loop Mystery: Why All Callbacks Share the Same Variable

This is where it gets really interesting:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Output: 3, 3, 3

Let's trace the execution step by step:

What happens:

Loop initialization creates i in the Function Environment Record (or Global if no function)
First iteration: i = 0, setTimeout schedules a callback
Second iteration: i = 1, setTimeout schedules another callback
Third iteration: i = 2, setTimeout schedules another callback
Loop condition check: i = 3, condition fails, loop exits
~100ms later, callbacks execute

Why they all print 3:

Each arrow function creates a closure. A closure is a function plus a reference to the Lexical Environment where it was created. All three arrow functions close over the same Lexical Environment - the one containing the loop.

When callbacks execute, they read i from that shared Environment Record. By that time, the loop has finished and i is 3.

Visually:

Outer Lexical Environment:
  EnvironmentRecord: { i: 3 }  // Final value after loop completes

Callback 1: () => console.log(i)  ──┐
Callback 2: () => console.log(i)  ──┼─→ All reference the same environment
Callback 3: () => console.log(i)  ──┘

There's only one i variable in memory, shared by all callbacks.

let and const: Block-Level Environment Records

Now here's where JavaScript's behavior fundamentally changes:

{
  let x = 10;
}
console.log(x); // ReferenceError

What happens:

When JavaScript encounters a block with let or const, it creates a new Lexical Environment with its own Environment Record (called a Declarative Environment Record for blocks).

Creation Phase (entering the block):

Create a new Lexical Environment for the block
Find all let/const declarations in that block
Create uninitialized bindings in the Environment Record
Set the outer reference to the parent environment

Execution Phase:

When code reaches let x = 10;, the binding is initialized
Upon exiting the block, the Lexical Environment is discarded (if no closures reference it)

The crucial difference: the variable exists in the Environment Record from the start (it's registered), but accessing it before initialization throws an error.

The Temporal Dead Zone: Not Just a Rule, It's a State

console.log(x); // ReferenceError: Cannot access 'x' before initialization
let x = 5;

Here's what's really happening:

When JavaScript enters the scope, it creates a binding for x in the Environment Record, but that binding is in a special state: uninitialized. This is different from undefined.

Internally, the Environment Record might look like:

DeclarativeEnvironmentRecord {
  x: <uninitialized>  // Special internal state, not undefined
}

If you try to read x, JavaScript checks: "Is this binding initialized?" If not, it throws a ReferenceError. This is the TDZ - the time between when the binding is created and when it's initialized.

When execution reaches let x = 5;, the binding transitions from <uninitialized> to 5.

Why does this exist?

Consider this scenario:

let x = x + 1; // ReferenceError

Without TDZ, what would x be on the right side? undefined? That would silently create bugs (undefined + 1 = NaN). The TDZ forces an error, making bugs obvious.

The Loop Fix: Creating New Environments Per Iteration

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Output: 0, 1, 2

This is where the specification does something really clever. For let in a for loop, JavaScript creates a new Lexical Environment for each iteration.

Here's the actual process:

Iteration 0:

Create a new Lexical Environment: { i: 0 }
Execute loop body in this environment
setTimeout callback closes over this environment

Iteration 1:

Create a new Lexical Environment: { i: 1 }
Execute loop body in this environment
setTimeout callback closes over this new environment

Iteration 2:

Create a new Lexical Environment: { i: 2 }
Execute loop body in this environment
setTimeout callback closes over this new environment

Visually:

Environment 0: { i: 0 } ← Callback 1 references this
Environment 1: { i: 1 } ← Callback 2 references this
Environment 2: { i: 2 } ← Callback 3 references this

Each callback has its own i because each iteration creates a separate Lexical Environment. This is specified in ECMAScript §13.7.4.8 - the spec literally says to create a new environment and copy the loop variables into it.

This is not the same as:

let i = 0;
// Create environment 0
i = 1;
// Create environment 1
i = 2;
// Create environment 2

That would be just reassigning the same variable. The spec explicitly creates new bindings.

const: Immutable Bindings in the Environment Record

const x = 10;
x = 20; // TypeError: Assignment to constant variable

What's happening here at the engine level?

When you declare const x = 10, JavaScript creates a binding in the Environment Record, but marks it as immutable. Internally, this might be represented as:

DeclarativeEnvironmentRecord {
  x: { 
    value: 10, 
    mutable: false  // Internal flag
  }
}

When you try x = 20, JavaScript checks the mutable flag. If it's false, it throws a TypeError.

Important: This is about the binding, not the value:

const obj = { count: 1 };
obj.count = 2; // OK
obj = {}; // TypeError

The binding obj is immutable (you can't make it point to something else), but the object it points to is still mutable. The Environment Record only controls the binding, not the heap-allocated object.

The Weird Interactions: Shadowing and Redeclaration

let x = 1;
{
  var x = 2; // SyntaxError: Identifier 'x' has already been declared
}

Why does this fail at parse time (before execution)?

When JavaScript parses this code, it sees:

let x - will create a binding in the outer environment
var x - tries to create a binding in... wait, where?

var is function-scoped, so it would try to create x in the same Environment Record as the outer let x. But the spec says you can't have duplicate lexical declarations in the same scope. Parse error.

But this works:

var x = 1;
{
  let x = 2; // OK
  console.log(x); // 2
}
console.log(x); // 1

Because let x creates a binding in the block's Environment Record, which is different from the function/global Environment Record where var x lives.

The environment chain looks like:

Block Environment:
  Record: { x: 2 }
  Outer → Function/Global Environment:
            Record: { x: 1 }

When you access x inside the block, JavaScript looks in the innermost environment first (finds 2). Outside the block, it looks in the function/global environment (finds 1).

What About Performance?

You might wonder: if let creates new environments for each loop iteration, isn't that slower?

Modern JavaScript engines (V8, SpiderMonkey, JavaScriptCore) optimize this heavily. If a loop variable isn't captured by a closure, the engine doesn't actually create separate environments - it's smart enough to know the variable isn't shared.

The extra environments only exist when they're semantically necessary (when closures capture them).

Summary: It's About Lexical Environments

The real difference between var, let, and const isn't syntax - it's how they interact with JavaScript's Lexical Environment system:

var: Creates bindings in Function Environment Records, initialized to undefined immediately, function-scoped
let: Creates bindings in Block Environment Records, starts in TDZ, block-scoped, one environment per loop iteration
const: Same as let, but bindings are marked immutable

Understanding this helps you predict behavior and debug issues. When you see strange scoping bugs, you can trace through the environment creation and see exactly where a variable lives.

Next time you write let in a loop, you'll know that JavaScript is creating separate environments behind the scenes - and why that matters for closures.

In the next article we'll see why closures aren't feature - they're a consequence of JavaScript's execution model.

Stay tuned for every Sunday!

Building Ephemeral Notes: Cryptography That Respects Reality

Razumovsky — Mon, 22 Dec 2025 20:26:03 +0000

The Problem with Passwords

Cryptography has three jobs:

Hide the content so nobody else can read it
Prove it wasn't tampered with during storage or transmission
Stay secure even if an attacker sees everything except your secret

That secret is usually a password. And here's the uncomfortable truth: human-made passwords are terrible cryptographic secrets.
They're short. They're predictable. They get reused. They can be guessed or brute-forced. People pick "Summer2024!" instead of "X7$mK9#pQw2@nF5&".

The entire architecture of Ephemeral Notes is built around compensating for this fundamental weakness.

Why Passwords Aren't Keys

Let's get this straight:

Password: A string chosen by a human. Weak, memorable, often reused. "ilovecats123"

Cryptographic Key: Fixed-size, random, unpredictable data. "7a3f9c2e8b1d4f6a9c3e7b2d8f1a5c9e4b7d2a6f8c3e1b9d7f4a2c8e5b1d6f9a"

Cryptographic algorithms can't work with passwords directly. They need keys. So we need a secure way to transform one into the other.

Enter Password Hashing

Why Regular Hashes Don't Work

You've probably heard of SHA-256 or MD5. They're fast—really fast. Bitcoin miners calculate billions of hashes per second. That's great for blockchain verification.

But it's terrible for password security.

If an attacker steals your encrypted file, they can test billions of passwords per second against it. "password123"? Checked in 0.0001 seconds. "ilovecats123"? Done before you blink.

What We Need: crypto_pwhash

Instead of speed, we need slowness. We need memory hunger. We need something that's a pain to parallelize.

This is where crypto_pwhash comes in. It's specifically designed to make brute-forcing passwords economically unprofitable. An attacker would need to spend more money on computing power than your data is worth.

Argon2: The Gold Standard

Argon2 is the algorithm behind crypto_pwhash. It won the Password Hashing Competition in 2015—basically the Olympics of password security.

Why it's good:

Resistant to GPUs and specialized hardware (ASICs)
Modern and actively maintained
Three variants for different security models

The variants:

Argon2i: Protects against timing attacks (side-channel attacks)
Argon2d: Maximum resistance to GPU cracking
Argon2id: Hybrid approach — this is what we use Argon2id gives us the best of both worlds: resistance to both timing attacks and GPU brute-forcing.

Making It Even Slower (On Purpose)

We configure Argon2id with two parameters:

OPSLIMIT
How many operations to perform. More operations = slower derivation.

MEMLIMIT
How much RAM to use. More memory = harder to parallelize on GPUs.

The philosophy: You'll enter your password maybe once a day. That's fine if it takes half a second. But an attacker needs to try millions of passwords, and half a second times a million is... expensive.
We set the limits to "MODERATE"—not paranoid, not lazy. Just enough to make your laptop wait a moment, and an attacker's server farm cry.

The Nonce Problem

Okay, we have a key now. Problem solved?
Not quite.
If you encrypt two different messages with the same key and the same "starting state," patterns emerge. Cryptographers can analyze those patterns and break your encryption.
This is where the nonce comes in.

What's a Nonce?

Nonce = Number used ONCE
It's a random (or at least unique) value that you use exactly one time with each key. Think of it as ensuring every encryption operation is unique, even if you're using the same password.

Important: The nonce is NOT a secret. You can store it right next to your encrypted data. It's not there to hide anything—it's there to prevent patterns.

Analogy: It's like adding a random starting position to a lock. The key still works, but the mechanism starts from a different place each time.

XChaCha20: Fast and Paranoid

Now we get to the actual encryption algorithm: XChaCha20-Poly1305.
Let's break that down.

ChaCha20

ChaCha20 is a stream cipher designed by Daniel J. Bernstein (a legend in crypto). Why it's good:

Fast: Even on weak processors
Simple: No complex lookup tables (S-boxes) that can leak timing information
Secure: Resistant to timing attacks and side-channel attacks

The X in XChaCha

XChaCha is an extended version of ChaCha20. The main improvement?

> Huge nonces: 192 bits (24 bytes)

Why does this matter? With a 192-bit nonce, you can generate them completely randomly and the chance of ever getting a duplicate is... basically zero. You'd need to encrypt 2^96 messages before you'd have even a tiny chance of collision.
That's more messages than atoms in a small country.

Philosophy: "Better to have way too much space than rely on perfect randomness."

Poly1305: The Authentication Tag

Here's the thing about encryption: it only hides data. It doesn't prove the data wasn't tampered with.
An attacker could flip bits in your encrypted file. When you decrypt it, you'd get garbage—but how would you know it was garbage vs. a wrong password?

Enter Poly1305: a message authentication code (MAC).

How It Works

When you encrypt, Poly1305 generates an authentication tag — a cryptographic fingerprint of your encrypted data. This tag is stored alongside the ciphertext.

When you decrypt:

You compute what the tag should be
You compare it to the stored tag
If they don't match exactly, something was tampered with—reject immediately

This is called AEAD: Authenticated Encryption with Associated Data.

Result: If someone modifies even a single bit of your encrypted note, decryption fails instantly. No garbage output, no confusion—just a clear "this has been tampered with" error.

Putting It All Together

Here's what happens when you create an ephemeral note:

Why This Design?

Every choice compensates for human weakness:

Weak passwords?
→ Argon2id makes them expensive to brute-force
Same password reused?
→ Unique salt per note prevents rainbow table attacks
Patterns in encryption?
→ Random nonces ensure every encryption is unique
Tampered data?
→ Poly1305 catches any modifications instantly
Side-channel attacks?
→ ChaCha20 is timing-attack resistant

What We DON'T Protect Against

Let's be honest about what this system can and can't do:

We Protect Against:

✅ Brute-forcing the password
✅ Forensic recovery after deletion
✅ Accidental backups to the cloud
✅ Someone finding your encrypted file

We DON'T Protect Against:

❌ Malware running on your computer
❌ Screen recording while the note is open
❌ Memory dumps during decryption
❌ Someone with physical access + root privileges

This is intentional. We're not selling snake oil. If your computer is compromised while the note is open, no software can save you. That's physics, not a bug.

What we guarantee is this: Once a note self-destructs, it's cryptographically gone. Not "deleted," not "overwritten," but mathematically unrecoverable.

The Self-Destruction Mechanism

When a note hits its limit (max opens or TTL expiry):

The encryption key is zeroed out in memory  (Not just deleted—every byte overwritten with zeros)
The file is overwritten with random data Multiple passes, different random bytes each time
The file header is corrupted Even if someone recovers the bits, the structure is broken
The file is deleted

On modern SSDs, physical overwriting isn't guaranteed due to wear-leveling. But here's the thing: without the key, the encrypted data is just random noise anyway.

The multi-pass overwrite is defense-in-depth. Even if somehow the bits persist, you'd need to:

Recover the exact file structure
Crack 256-bit XChaCha20 (computationally infeasible)
Do it without the salt or nonce working properly It's paranoia layered on top of math.

Why This Matters

Most "secure note" apps lie to you. They promise:

"Military-grade encryption!" (meaningless marketing)
"Unhackable!" (nothing is unhackable)
"Your data is 100% safe!" (under undefined conditions) We don't do that.

Ephemeral Notes is built on a simple principle: Respect the limits of what's possible, and be honest about what's not.

Your password is weak—we assume that and design around it. Your computer might be compromised—we can't fix that, so we don't claim to. You might want to read a note twice—we let you set that limit yourself.

What we can promise:

Your note is encrypted with algorithms that actual cryptographers trust
Your password is strengthened with techniques that make brute-forcing impractical
Once the note self-destructs, it's gone in a way that no "undelete" tool can reverse

For the Curious

If you want to verify any of this, the entire project is open source. Every line of crypto code can be audited. We use:

libsodium: Industry-standard crypto library (used by Signal, GitHub, and more)
Argon2id: Winner of Password Hashing Competition 2015
XChaCha20-Poly1305: Modern AEAD cipher recommended by cryptographers No custom crypto. No "we made it better." Just proven, peer-reviewed algorithms used correctly.

The Bottom Line

Ephemeral Notes is not about perfect security. Perfect security doesn't exist.

It's about honest security:

We know passwords are weak, so we strengthen them mathematically
We know files can be recovered, so we encrypt and then destroy properly
We know attackers will try to brute-force, so we make it unprofitable If you need to share a secret once and have it vanish forever — this is how you do it right.

Not with magic. Not with marketing. Just math, engineering, and honesty about what's actually possible.

The code is open source. The algorithms are public. The design choices are documented. If you don't trust it, audit it. That's the point.

GH: https://github.com/0xRazumovsky/ephemeral_notes

Forem: Razumovsky

Event Loop in JavaScript: How Async Really Works

The Mental Model: JavaScript Runtime Architecture

The Event Loop: What It Actually Does

Phase-by-Phase Execution

Microtasks vs Macrotasks: The Priority System

Node.js Event Loop: More Complex Phases

Timers Phase

Poll Phase

Check Phase: setImmediate

process.nextTick: The Priority Microtask

I/O Operations: How They Actually Work

Practical Example: Ordering Chaos

Visualizing Async Flow

Common Pitfalls

Summary

Understanding 'this' in JavaScript: Execution Context Explained

What is 'this'? A Binding, Not a Variable

The Four Rules of 'this' Binding

Rule 1: Default Binding (Standalone Function Calls)

Rule 2: Implicit Binding (Method Calls)

Nested Objects: Only the Last Level Matters

Implicit Binding Loss: The Common Trap

Rule 3: Explicit Binding (call, apply, bind)

call() and apply()

bind(): Creating a Hard-Bound Function

Rule 4: new Binding (Constructor Calls)

Arrow Functions: Lexical 'this'

Precedence: When Rules Conflict

Real-World Scenarios

Event Handlers in DOM

Class Methods

React Components (Classic Pattern)

Common Mistakes and Debugging

How to Debug 'this'

Summary: 'this' is All About the Call-Site

Closures in JavaScript: Understanding Lexical Scope and Memory

The Problem Closures Solve: Functions Need Context

How JavaScript Executes Functions: The Call Stack and Execution Contexts

The Secret: Lexical Environments Live on the Heap

Multiple Closures, Shared Environment

Multiple Closures, Separate Environments

The Loop Problem Revisited

Practical Use Cases: Why Closures Matter

1. Data Privacy

2. Function Factories

3. Callbacks and Event Handlers

4. Memoization

Memory Leaks: When Closures Go Wrong

Closures and this: A Common Pitfall

How Engines Optimize Closures

Understanding Closures Through the Spec

Summary: Closures are Lexical Scope + Memory

var, let, const: Why JavaScript Needed Three Ways to Declare Variables

What Really Happens When JavaScript Runs Your Code

var: Function-Level Environment Records

The Block Scope Problem: Why var Ignores Blocks

The Loop Mystery: Why All Callbacks Share the Same Variable

let and const: Block-Level Environment Records

The Temporal Dead Zone: Not Just a Rule, It's a State

The Loop Fix: Creating New Environments Per Iteration

const: Immutable Bindings in the Environment Record

The Weird Interactions: Shadowing and Redeclaration

What About Performance?

Summary: It's About Lexical Environments

Building Ephemeral Notes: Cryptography That Respects Reality

The Problem with Passwords

Why Passwords Aren't Keys

Enter Password Hashing

Why Regular Hashes Don't Work

What We Need: crypto_pwhash

Argon2: The Gold Standard

Making It Even Slower (On Purpose)

The Nonce Problem

What's a Nonce?

XChaCha20: Fast and Paranoid

ChaCha20

The X in XChaCha

Poly1305: The Authentication Tag

How It Works

Closures and `this`: A Common Pitfall