JavaScript#

Before any syntax, one distinction that clears up half the confusion beginners have: JavaScript the language is tiny, and almost everything you actually use is not part of it. The language gives you values, objects, functions, and a rule for when code runs. It has no way to read a file, draw a pixel, open a socket, or even print. Those come from whatever host is running the language.

• Spec ECMAScript
• Engine V8, SpiderMonkey
• Runtime browser, Node
• Threads 1

The second thing worth knowing early: JavaScript is compiled, not interpreted line by line, even though nothing looks compiled. V8 parses your whole file, generates bytecode, starts running it, watches which functions get hot, and then recompiles those to optimised machine code — while making guesses about the types you have been passing. If you later break a guess (a function that always got numbers suddenly gets a string), it throws the optimised version away and starts again. This is why "keep the shape of your objects consistent" is real performance advice and not folklore.

• Primitives 7
• Falsy values 8
• Number type float64 only
• Safe integers ±2⁵³−1

JavaScript has exactly seven primitive types — number, string, boolean, null, undefined, symbol, bigint — and one non-primitive: object. Arrays, functions, dates, regexes, Map, Set and class instances are all objects. That is the whole type system. There is no integer type, no char, no float versus double.

The consequence that catches everyone: every number is a 64-bit float. Integers up to 2⁵³−1 are exact, so day-to-day arithmetic is fine, but decimals are not — 0.1 + 0.2 really is 0.30000000000000004, in every language with IEEE-754 doubles. Money belongs in integer cents or a decimal library, never in a float.

The other daily decision is which equality to use, and it is not a style question — the two operators run genuinely different algorithms. === asks "same type and same value?". == is allowed to convert the operands until the types match, following a specification algorithm nobody memorises. Step through it below and watch [] == false become true through three separate conversions.

• Strength — === is predictableOne rule, no conversions, no surprises. Use it everywhere. Linters default to enforcing it precisely because the alternative is unpredictable.
• Weakness — == is three algorithms deepThe result depends on the types of both operands and on valueOf/toString. The one accepted use is x == null, deliberate shorthand for "null or undefined".

Related, and just as common: truthiness. if (x) does not ask "does x exist?" — it converts x to a boolean. Exactly eight values are falsy (false, 0, -0, 0n, '', null, undefined, NaN) and everything else is truthy, including [], {} and the string '0'. That is why count || 10 quietly replaces a legitimate 0, and why ?? exists.

• Declarations const, let, var
• const scope block
• var scope function
• Lookup cost O(depth)

The rule is short: use const by default, let when you must reassign, and var never. But the reason matters, because it explains a whole family of bugs in older code.

var is scoped to the enclosing function, ignoring blocks entirely — a var declared inside an if is visible after it. It is also hoisted and initialised to undefined, so reading it before the declaration gives you a value rather than an error. let and const are scoped to the enclosing block, and while they are hoisted too, they are left uninitialised: touching one before its declaration throws. That gap is the temporal dead zone, and it converts a silent undefined into a loud error.

Where a name is looked up is the second half of the story. When the engine meets a name, it searches the current scope, then the scope that lexically encloses it in the source, then the next one out, until it reaches global — and throws ReferenceError if it never finds it. Crucially this chain is fixed by where the function was written, not by who called it. Two functions calling the same helper see the same chain.

• Property access O(1)
• Key type string | symbol
• Copy cost (spread) O(n) shallow
• Equality by reference

An object is a bag of key–value pairs where the keys are strings (or symbols) and the values are anything. An array is an object whose keys happen to be numeric and which carries a length. Both are reference types, and that one fact produces more confusing bugs than any other feature of the language.

A variable never contains an object. It contains a reference — an arrow pointing at one place in memory. Assigning copies the arrow, not the thing. So two variables can name the same object, and a change through one is visible through the other. Watch what each kind of copy actually duplicates:

Everyday syntax you will use constantly, all of it built on this model:

const user = { id: 7, name: 'Ada', tags: ['js'] };

// read
user.name;              // dot notation - fixed key
user['na' + 'me'];      // bracket notation - computed key
user.address?.city;     // optional chaining: undefined instead of a throw
user.nickname ?? 'anon' // nullish default (0 and '' survive)

// write - all of these MUTATE
user.role = 'admin';
delete user.id;
user.tags.push('ts');

// copy - these produce new objects
const patched = { ...user, role: 'editor' };      // later keys win
const deep    = structuredClone(user);            // whole graph

// inspect
Object.keys(user);      // ['name', 'tags', 'role']
Object.values(user);
Object.entries(user);   // [['name','Ada'], ...] - the for..of pair form
'name' in user;         // true - includes inherited keys
Object.hasOwn(user, 'name'); // true - own keys only

// arrays: know which methods mutate
[3, 1, 2].sort();       // MUTATES and returns the same array
[3, 1, 2].toSorted();   // returns a new array (ES2023)
arr.splice(1, 2);       // MUTATES - removes in place
arr.slice(1, 3);        // copies a window

user = {"id": 7, "name": "Ada", "tags": ["js"]}

# read
user["name"]                 # KeyError if missing - stricter than JS
user.get("nickname", "anon") # the ?? equivalent

# copy - the same shallow/deep distinction exists
patched = {**user, "role": "editor"}   # like JS spread
import copy
deep = copy.deepcopy(user)             # like structuredClone

# inspect
list(user.keys()), list(user.items())
"name" in user

# and the same mutating-vs-returning split
nums = [3, 1, 2]
nums.sort()        # mutates, returns None  <- JS returns the array
sorted(nums)       # returns a new list

• Strength — cheap sharingPassing a large object to a function costs nothing; only the reference moves. This is why JavaScript can pass big structures around freely.
• Weakness — accidental sharingA function that mutates its argument changes the caller's data. Treat arguments as read-only unless mutation is the documented point of the function.

• Functions are values
• Arrow this lexical
• Function this call-site
• Binding rules 4

Functions in JavaScript are ordinary values: you can store one in a variable, put it in an array, pass it to another function and return it from one. That is what makes callbacks, array methods, and the entire asynchronous style possible — and it is the foundation of the next two sections.

function add(a, b) { return a + b; }        // declaration - hoisted whole
const add = function (a, b) { return a + b; }; // expression - not hoisted
const add = (a, b) => a + b;                 // arrow, implicit return
const obj = { add(a, b) { return a + b; } }; // method shorthand

// parameters
const greet = (name = 'world', ...rest) => `hi ${name}`; // default + rest
const draw = ({ x = 0, y = 0 } = {}) => …;   // named arguments

// returning an object literal from an arrow needs parens
const make = (id) => ({ id });               // the () are not optional

def add(a, b):
    return a + b

add = lambda a, b: a + b        # limited to a single expression

def greet(name="world", *rest):
    return f"hi {name}"

def draw(*, x=0, y=0):          # keyword-only args - JS uses destructuring
    ...

# Python has no arrow/function `this` distinction: methods take `self`
# explicitly, which is the problem `this` solves badly.

Now the part that costs people afternoons. this is not decided by where a function is written — it is decided by how it is called. The same function body can see four different values depending on the call site. Step through each rule:

Read the rules in priority order and you can answer any this question mechanically: new wins (a fresh object), then explicit call/apply/bind, then a receiver before the dot, then the default (undefined in strict mode). Arrow functions sit outside this list entirely — they have no this of their own, so the name resolves up the scope chain like any ordinary variable.

• Use an arrow forcallbacks, array-method predicates, anything nested inside a method that needs the surrounding this. Arrows also have no arguments and cannot be used with new — which is a feature, not a limitation.
• Do not use an arrow forobject methods (there is no enclosing this to inherit), prototype methods, or anything you intend to call with new. Use the method() {} shorthand instead.

• map / filter O(n)
• find / some O(n), early exit
• sort O(n log n)
• includes on array O(n)

Most loops you would write in another language are one method call here. The value is not brevity — it is that the method names the intent. filter announces "a subset, same values"; map announces "same count, different values". A reader knows the shape of the result before reading the callback.

Because each one returns an array, they chain — and reading a chain top to bottom describes the pipeline in order:

const total = orders
  .filter((o) => o.status === 'paid')     // fewer items
  .map((o) => o.amount)                   // now numbers
  .reduce((sum, amount) => sum + amount, 0); // one value

// grouping - the reduce that earns its keep
const byUser = orders.reduce((acc, o) => {
  (acc[o.userId] ??= []).push(o);
  return acc;                              // ALWAYS return the accumulator
}, {});

// or, in modern runtimes
const byUser = Object.groupBy(orders, (o) => o.userId);

// sort needs a comparator for numbers - the default is ALPHABETICAL
[10, 9, 1].sort();                   // [1, 10, 9]   ⚠
[10, 9, 1].sort((a, b) => a - b);    // [1, 9, 10]   ✓
orders.toSorted((a, b) => b.amount - a.amount); // non-mutating (ES2023)

// flatten one level of nested arrays
[[1, 2], [3]].flat();                        // [1, 2, 3]
users.flatMap((u) => u.roles);               // map + flat in one pass

total = sum(o["amount"] for o in orders if o["status"] == "paid")
# Python prefers comprehensions where JS chains methods; same pipeline,
# read right-to-left instead of top-to-bottom.

from collections import defaultdict
by_user = defaultdict(list)
for o in orders:
    by_user[o["user_id"]].append(o)

from itertools import groupby   # note: requires sorted input, unlike JS

sorted([10, 9, 1])                       # numeric by default - no JS trap
sorted(orders, key=lambda o: -o["amount"])

• Threads 1
• Stack depth ~10k frames
• Push / pop O(1)
• Blocking cost whole UI

JavaScript runs your code on exactly one thread. There is one call stack, and while something is on it, nothing else in that program can happen — no click handler, no timer, no rendering. A 200 ms synchronous loop is a 200 ms frozen page. Understanding this is the prerequisite for understanding why the async model looks the way it does.

Two practical consequences. First, recursion depth is bounded — around ten thousand frames before RangeError: Maximum call stack size exceeded. JavaScript engines do not implement tail-call elimination (Safari aside), so deep recursion must be rewritten as a loop or split across event-loop turns. Second, anything slow must not be synchronous: parse a huge JSON file, or hash a password, and the whole tab stops. Move it to a Worker, or chunk it so the stack can drain between pieces.

• Captures the variable
• Not a copy of the value
• Per call a new environment
• Lifetime as long as referenced

A closure is what you get when a function outlives the scope it was created in and keeps access to it anyway. It is not an advanced feature you opt into — every function you write inside another function is one. It sounds abstract until you see the two things it enables: private state, and functions configured at runtime.

The mechanism is simple once you know that scopes live on the heap, not the stack. A function's frame pops when it returns, but its environment survives as long as something still points at it — and a returned inner function points at it. Watch the frame disappear while the variable stays alive:

// 1. private state - `count` is unreachable from outside
function makeCounter() {
  let count = 0;
  return {
    increment: () => ++count,
    get value() { return count; },
  };
}
const c = makeCounter();
c.increment();       // 1
c.count;             // undefined - genuinely private

// 2. configuration captured once, reused forever
const withPrefix = (prefix) => (msg) => console.log(`[${prefix}] ${msg}`);
const logAuth = withPrefix('auth');
logAuth('login ok'); // [auth] login ok

// 3. memoisation - the cache lives in the closure
const memoize = (fn) => {
  const cache = new Map();
  return (arg) => {
    if (!cache.has(arg)) cache.set(arg, fn(arg));
    return cache.get(arg);
  };
};

// 4. once - a flag nobody else can flip
const once = (fn) => {
  let done = false;
  return (...args) => {
    if (done) return;
    done = true;
    return fn(...args);
  };
};

# Python closures work the same way, with one wrinkle: assigning to a
# captured name requires `nonlocal`, otherwise you create a new local.
def make_counter():
    count = 0
    def increment():
        nonlocal count      # JavaScript needs no such keyword
        count += 1
        return count
    return increment

c = make_counter()
c()   # 1

def with_prefix(prefix):
    return lambda msg: print(f"[{prefix}] {msg}")

from functools import lru_cache    # memoisation, batteries included

@lru_cache(maxsize=None)
def slow(n):
    ...

• Strength — encapsulation without classesState that literally cannot be reached from outside, no naming conventions or #private fields required. Every module pattern, hook and middleware factory is this.
• Weakness — silent retentionA closure keeps its whole environment alive, not just the variable it uses. A callback that captures a scope containing a large array keeps that array in memory for as long as the callback is registered.

• Inheritance delegation
• Lookup O(chain depth)
• Methods stored once, shared
• Chain ends at null

JavaScript has no classes in the way C++ or Java do. It has objects, and every object holds a hidden link to another object called its prototype. When you read a property the engine looks at the object, then its prototype, then its prototype, until it finds the key or runs out of chain. class syntax is a readable way to build these links — real, useful sugar over a mechanism that stays visible underneath.

The important asymmetry: reads walk the chain, writes never do. Assigning rex.speak = fn creates an own property on rex that shadows the inherited one for that object only. This is why mutating a shared prototype at runtime is so dangerous, and why accidentally adding to Object.prototype breaks every object in the program.

class Animal {
  static kingdom = 'Animalia';   // on the class itself
  #secret = 42;                  // truly private - not just a convention
  constructor(name) { this.name = name; }
  speak() { return `${this.name} makes a sound`; }
  get label() { return this.name.toUpperCase(); }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name);                 // MUST run before touching `this`
    this.breed = breed;
  }
  speak() { return `${super.speak()} - a bark`; }
}

const rex = new Dog('Rex', 'lab');
rex instanceof Dog;     // true
rex instanceof Animal;  // true - the chain is walked

// the same thing, written by hand, pre-2015
function Animal(name) { this.name = name; }
Animal.prototype.speak = function () { return `${this.name} makes a sound`; };
function Dog(name) { Animal.call(this, name); }
Dog.prototype = Object.create(Animal.prototype);  // link the chains
Dog.prototype.constructor = Dog;

// no classes needed at all
const proto = { speak() { return `${this.name} speaks`; } };
const cat = Object.create(proto);
cat.name = 'Tom';
Object.getPrototypeOf(cat) === proto;   // true

class Animal:
    kingdom = "Animalia"          # class attribute - shared, like a prototype

    def __init__(self, name):
        self.name = name

    def speak(self):
        return f"{self.name} makes a sound"

    @property
    def label(self):
        return self.name.upper()

class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name)
        self.breed = breed

    def speak(self):
        return f"{super().speak()} - a bark"

# Python resolves attributes through the MRO (a linearised class list),
# JavaScript through a chain of ordinary objects. Same delegation idea;
# Python's is fixed at class-definition time, JavaScript's is mutable at
# runtime - you can reassign an object's prototype after creating it.

• Strength — one copy of every methodA thousand instances share a single speak function on the prototype. Defining methods inside the constructor instead creates a thousand copies.
• Weakness — this comes along for the rideClass methods are ordinary functions, so passing obj.method as a callback loses the receiver. Bind it, or declare the method as a class field arrow: speak = () => ….

• Microtasks drained all of them
• Macrotasks per turn 1
• setTimeout(fn, 0) ≥ 4 ms, later
• Render budget 16.7 ms

One thread, yet a browser handles clicks, timers and network responses without freezing. The trick is that the slow work is not done by JavaScript. When you call setTimeout or fetch, you hand a callback to the host — the browser or Node — and return immediately. The host does the waiting on its own threads, and when it is finished it puts your callback in a queue. The event loop's only job is: when the stack is empty, take the next callback and run it.

The subtlety, and the source of every "why did that print in that order" question, is that there are two queues with different priorities. Microtasks (promise callbacks, await resumptions) are drained completely after each task; macrotasks (timers, I/O, DOM events) get one per turn.

Before stepping through the animation, here is the whole machine on one picture — the four parts and the single circular path a callback travels through them.

• States 3
• Transitions 1, ever
• Callbacks run as microtasks
• await returns a promise

A promise is an object representing a value that is not there yet. It has three states — pending, fulfilled, rejected — and it may transition exactly once. Because the result is stored rather than broadcast, you can attach a handler long after it settled and still get the value; an event you missed is gone forever, but a promise replays.

async/await is not a different mechanism — it is syntax over exactly those promises. An async function always returns a promise, and await means "suspend this function, hand control back to the caller, and resume in a microtask when that promise settles". Watch a function pause and leave the stack entirely:

async function loadDashboard(userId) {
  try {
    // independent work - start both, then await. NOT two sequential awaits.
    const [user, orders] = await Promise.all([
      fetchUser(userId),
      fetchOrders(userId),
    ]);

    // dependent work - this one genuinely must wait
    const prefs = await fetchPrefs(user.prefsId);

    return { user, orders, prefs };
  } catch (err) {
    // catches ANY rejection above, exactly like a synchronous throw
    report(err);
    throw err;              // rethrow unless you can truly recover
  } finally {
    hideSpinner();          // runs on success and on failure
  }
}

// mapping over async work: map first, then await together
const users = await Promise.all(ids.map((id) => fetchUser(id)));

// a deadline for anything
const withTimeout = (promise, ms) =>
  Promise.race([
    promise,
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error('timeout')), ms)),
  ]);

import asyncio

async def load_dashboard(user_id):
    try:
        # gather is Promise.all
        user, orders = await asyncio.gather(
            fetch_user(user_id),
            fetch_orders(user_id),
        )
        prefs = await fetch_prefs(user["prefs_id"])
        return {"user": user, "orders": orders, "prefs": prefs}
    except Exception as err:
        report(err)
        raise
    finally:
        hide_spinner()

# The big difference: Python coroutines are LAZY - calling one does
# nothing until it is awaited or scheduled. A JavaScript promise starts
# its work the moment it is created, which is why `Promise.all` on
# already-started promises still runs them in parallel.

Once you have several promises in flight, the four combinators cover essentially every situation. They differ only in when they settle and what a failure does:

• Standard ESM
• Legacy (Node) CommonJS
• Evaluated once
• Bindings live

A module is a file with its own scope. Nothing inside it is visible elsewhere unless you export it, and nothing from elsewhere is visible inside unless you import it. That is the entire idea, and it replaced a decade of workarounds — IIFEs, namespaces, and global variables carefully prefixed to avoid collisions.

Two systems exist. ES modules (import/export) are the standard, understood by browsers and Node alike; their imports are static, so the whole dependency graph is known before a single line executes. CommonJS (require/module.exports) is Node's original system, where importing is a function call that runs the file right there. Compare how each one loads the same graph:

// cart.js - named exports are the default choice
export const TAX = 0.2;
export function total(items) { … }
export default class Cart { … }        // at most one per module

// main.js
import Cart, { total, TAX as VAT } from './cart.js';  // extension required
import * as cart from './cart.js';                     // namespace object

// lazy: a function call, allowed anywhere, returns a promise
const { heavy } = await import('./heavy.js');

// side-effect only - runs the module, imports nothing
import './polyfills.js';

# cart.py
TAX = 0.2
def total(items): ...

# main.py
from cart import total, TAX as VAT
import cart                       # namespace, like import * as
import importlib
heavy = importlib.import_module("heavy")   # the dynamic form

# Python modules are also evaluated once and cached (sys.modules),
# exactly like JavaScript. The difference: Python exports everything
# public by default, JavaScript exports nothing unless you say so.

Around modules sits the package ecosystem, and three facts save a lot of confusion. package.json declares your dependencies and their allowed version ranges; the lockfile records the exact versions that were installed and is what makes a build reproducible, so it belongs in git. npm ci installs strictly from the lockfile and is what CI should run; npm install may update it. And node_modules is a build artifact — never committed, always regenerable.

• DOM read/write can force layout
• Frame budget 16.7 ms
• Event phases 3
• fetch rejects on network only

The DOM is a tree of objects representing the page, handed to you by the browser. You query it, change it, and listen to it — and the only performance rule that matters is that touching it is expensive. Reading a layout property such as offsetHeight forces the browser to recompute geometry; doing that inside a loop that also writes creates "layout thrashing", where every iteration invalidates the work of the last. Batch your reads, then batch your writes.

Events do not simply fire on the element you clicked. They travel down from the window to the target, then back up — and that upward journey is what makes one listener able to serve a thousand rows:

// query
const el   = document.querySelector('#list');       // first match
const all  = document.querySelectorAll('li.active'); // static NodeList

// change - textContent is safe, innerHTML is an injection risk
el.textContent = userInput;          // ✓ always
el.innerHTML = userInput;            // ✗ executes markup
el.classList.toggle('open', isOpen);
el.dataset.userId = 7;               // <div data-user-id="7">

// build without parsing strings
const li = document.createElement('li');
li.textContent = name;
list.append(li);

// one delegated listener beats a thousand direct ones
list.addEventListener('click', (e) => {
  const row = e.target.closest('li');
  if (row) select(row.dataset.id);
});

// cancellable listeners - one signal removes them all
const ac = new AbortController();
window.addEventListener('scroll', onScroll, { signal: ac.signal });
ac.abort();

// fetch: only rejects on NETWORK failure, never on 404 or 500
const res = await fetch('/api/users', { signal: ac.signal });
if (!res.ok) throw new Error(`HTTP ${res.status}`);   // you must check
const data = await res.json();

# The closest analogue on the server side
import httpx

async with httpx.AsyncClient() as client:
    res = await client.get("/api/users", timeout=5)
    res.raise_for_status()      # httpx DOES raise on 4xx/5xx - fetch does not
    data = res.json()

# Parsing HTML server-side rather than manipulating a live DOM
from bs4 import BeautifulSoup
soup = BeautifulSoup(html, "html.parser")
soup.select_one("#list")
[li.get_text() for li in soup.select("li.active")]

Finally, the browser fires events far faster than you can usefully respond to them — scroll and input can fire dozens of times a second. Two closures fix this, and knowing which to reach for is the difference between a smooth page and a janky one:

Everything above, compressed into the form you would want on a card next to your keyboard.

The decisions you make daily#

The machine, in five sentences#

The traps, ranked by how often they bite#

• 1. Shared referencesconst b = a does not copy. Mutating b.x changes a.x, and {...a} only protects the top level.
• 2. Lost thisPassing obj.method as a callback drops the receiver. Wrap it in an arrow or bind it.
• 3. Sequential awaitsTwo independent awaits cost the sum of both latencies. Start both promises, then Promise.all.
• 4. Truthiness on 0 and ''if (count) and x || fallback silently treat valid values as missing.
• 5. Mutating array methodssort, reverse, splice change the original. toSorted, toReversed and slice do not.
• 6. Unhandled rejectionsA chain with no catch and no await in a try crashes Node and vanishes in the browser.
• 7. fetch not rejecting on 404An HTTP error is a successful request. Check res.ok yourself.
• 8. Leaked listeners and timersEvery registered handler keeps its whole closure alive. Remove them, or pass an AbortSignal.

That last one is worth one more look, because "why is memory climbing?" is a question you will be asked eventually and the answer is always the same shape — something reachable from a root that nobody remembered to release:

Two more worth knowing before you go#

Destructuring is everywhere in modern code — in imports, in function signatures, in for…of over Object.entries. Reading it as "a picture of the shape I expect" makes it immediately legible:

And generators, while rarer, are the mechanism behind for await…of, streaming responses and lazy pipelines — a function that can pause in the middle and be resumed later with its locals intact:

Where to go next#

1. The JavaScript Detailed Course — the same ground from first principles plus everything this page skipped: property descriptors, symbols, iterators, Proxy, regular expressions, the memory model, Node internals and tooling.
2. All Programming Language Courses — the Python track covers the same ideas from the other side, which is the fastest way to see which parts of JavaScript are genuinely unusual.
3. MDN JavaScript reference — the documentation to keep open. Accurate, versioned, and the source most other sites are paraphrasing.
4. The ECMAScript specification — dense, but the final word when two blog posts disagree about coercion or the event loop.
5. javascript.info — a well-sequenced tutorial with exercises, good for filling gaps in a specific area.