In JavaScript, what can wrapping an object in a Proxy do that plain getters and setters cannot, and which real use cases does that unlock?

## What a Proxy actually wraps `new Proxy(target, handler)` returns a new object that stands in front of `target`. Every fundamental operation on the proxy — reading a property, writing one, deleting one, asking `in`, listing keys, calling it — is routed to the matching method on `handler` if one exists, and otherwise performed on the target unchanged. An empty handler therefore produces something that behaves almost exactly like the target. The key word is *operation*. An accessor property (a getter/setter pair) is bound to one name that must exist before anything can be intercepted, and it only covers get and set. A Proxy is bound to the object, not to a name, so it can answer for names that were never declared and for operations that are not property reads at all. ```js const counted = new Proxy({}, { get(target, key, receiver) { if (!Reflect.has(target, key)) return 0; // default for unknown keys return Reflect.get(target, key, receiver); } }); counted.anythingAtAll; // 0 — no property was ever defined ``` ## The use cases that genuinely need it **Reactive state.** A store must know when *any* key is read (to record a dependency) and when *any* key is written or deleted (to invalidate). Installing accessors at construction time can only cover the keys present then; adding a key later, or deleting one, is invisible. A Proxy covers the whole object for its whole life, which is why Vue 3's `reactive()` and Immer's copy-on-write drafts are Proxy-based. **Validation and invariants in one place.** A `set` trap runs for every assignment, so range checks, type checks and required-field rules live in one handler instead of being duplicated per property. In strict-mode code — which includes all ES modules — a `set` trap that returns `false` makes the assignment throw a `TypeError`, though throwing your own error with a useful message is friendlier. **Defaults and safe lookup.** A `get` trap that returns a fallback turns missing-key `undefined` into a sensible value; the inverse — throwing on an unknown key — turns a typo in a config object from a silent `undefined` into an immediate error. **Negative array indices and other index tricks.** `arr[-1]` is a plain property read of the key `"-1"`; a `get` trap can translate it into `length - 1`. **Dynamic API clients.** `api.getUser` need not exist. A `get` trap can manufacture a function from the property name, so a client library covers an entire endpoint surface without generating code for it. **Access logging and tracing.** Wrapping a service object in a logging proxy records every call site during debugging without editing the object. ## What it costs Every intercepted operation becomes a call into your handler, so an engine cannot use the inline caches it would use for a plain property read. That is fine for configuration objects and UI state touched at human speed, and a real problem in a loop touching millions of elements. There is also a transparency cost: the proxy is not the target. `proxy !== target`, a lookup in a `Map` or `WeakMap` keyed by the target will not find the proxy, methods that need internal slots (`Map.prototype.get`, `Date.prototype.getTime`, DOM node methods) throw when invoked with the proxy as `this`, and methods reading `#private` fields throw for the same reason. And anyone still holding the raw target writes straight past your traps — a reactivity or validation layer only works if the proxy is the *only* reference that circulates. ## When not to reach for one If you know the property names up front and only need get/set behaviour, accessors are simpler, faster and easier to debug. If you need to freeze behaviour rather than observe it, `Object.freeze` says so directly. And a Proxy adds hidden control flow: a reader of `user.name = x` has no syntactic hint that arbitrary code runs. Use it where the dynamism is the point, and keep the wrapped surface small and documented.