In a JavaScript class body, where do a field declaration like count = 0 and a method declaration like inc() {} each end up at runtime, and what practical differences follow?

## Two different homes A class body looks uniform, but its declarations land in two different places. ```js class Point { x = 0; // instance field y = 0; // instance field move(dx, dy) { // prototype method this.x += dx; this.y += dy; } } ``` `move` is created once when the class is evaluated and stored on `Point.prototype`. `x` and `y` are created **again for every instance**, as own properties of the object being constructed. ## When field initializers run For a base class, the field initializers run immediately after the instance is created and **before** the constructor body. They run in source order, and each one may use `this`, so a later field can read an earlier one: ```js class Box { width = 4; area = this.width * this.width; // 16 — width already exists } ``` Reversing those two lines yields `NaN`, because `this.width` is still `undefined` when `area` initializes. A field written with no initializer, like `total;`, is still defined — as `undefined`. That matters: it is a real definition, not a no-op declaration. ## The exact property shape Each field becomes a data property with all three attributes set to `true`: ```js Object.getOwnPropertyDescriptor(new Point(), 'x'); // { value: 0, writable: true, enumerable: true, configurable: true } ``` Prototype methods, by contrast, are non-enumerable. That single attribute is why the two show up so differently: ```js const p = new Point(); Object.keys(p); // [ 'x', 'y' ] Object.entries(p); // [ [ 'x', 0 ], [ 'y', 0 ] ] JSON.stringify(p); // '{"x":0,"y":0}' ({ ...p }); // { x: 0, y: 0 } — no move Object.getOwnPropertyNames(Point.prototype); // [ 'constructor', 'move' ] ``` The spread result is the one that surprises people most often: spreading an instance gives you a **plain object with the data and none of the behaviour**. Any code that does `{ ...instance, extra: 1 }` and then calls a method on the result will fail. ## Define, not assign — the shadowing trap Field initialization does not perform `this.x = value`. It performs a property *definition*, the same operation as `Object.defineProperty`. Ordinary assignment walks the prototype chain and hands control to any setter it finds; definition does not. So: ```js class Base { set label(v) { console.log('setter ran with', v); } get label() { return 'from base'; } } class Derived extends Base { label = 'own value'; } const d = new Derived(); // the setter never runs d.label; // 'own value' ``` The derived instance now has an own data property named `label` that hides the inherited accessor completely — the getter is dead too. If your intent was to *feed* the base class's setter, the field declaration is the wrong tool; assign in the constructor body instead (`constructor() { super(); this.label = 'own value'; }`), because that is a real assignment and does find the setter. The same mechanism explains why declaring a field in a subclass silently discards whatever the parent constructor put in that property: the definition runs later and overwrites it. ## Cost and shape Because every field is materialised per instance, a class with many fields makes bigger objects than a class that computes values on demand through prototype accessors. This rarely matters for a handful of objects and can matter a great deal for hundreds of thousands. The reverse is also true for behaviour: everything you can put on the prototype is paid for once. A related consequence is testability and monkey-patching. A prototype method is reachable and replaceable through `Class.prototype.name`, which is how test doubles and instrumentation typically hook in. Anything stored per instance is not reachable that way — you would have to patch each object. ## Quick mental model Ask "is this **state** or **behaviour**?" State that differs per object belongs in fields. Behaviour that is identical for every object belongs on the prototype as a method. The moments to pause are when a piece of behaviour is stored as a field anyway (a bound callback), and when a field's name collides with an inherited accessor — both are cases where the placement rule, not your intent, decides what happens.