The three calls form a strict ladder of restrictions. preventExtensions blocks new properties only, so existing fields can still be reassigned or deleted. seal adds a no-delete rule on top, but writable values can still change. freeze adds a no-write rule, which is the version most engineers actually want when they say immutable. The matching predicates Object.isExtensible, Object.isSealed, and Object.isFrozen are how you verify the level after the fact, which is handy when an object passes through several layers.

Outside strict mode the writes in accordion 1 fail silently, which is the worst possible default for a debugging session. Modules and class bodies are strict by default, but loose-mode scripts and snippet sandboxes are not, so bugs hide in production and surface in testing. Adding 'use strict' (or just authoring inside a module) flips those silent ignores into real TypeError throws, which is what you almost always want during development. The three messages above pin down exactly which rule was violated, so a stack trace tells you whether to relax the integrity level or to fix the call site.

Object.freeze is shallow: nested objects and arrays are still mutable references, which is a common surprise the first time someone tries to lock down a config tree. The recursive walker freezes leaves before parents and short-circuits on already-frozen objects, which keeps the cost linear and prevents stack overflows on shared subtrees. The Object.isFrozen early exit also handles cycles safely (the second visit hits an already-frozen node and returns). Use this for module-level config and dependency-injection containers that should never be mutated at runtime; for hot per-request data, prefer copy-on-write helpers because freezing makes every write a throw.