You need a framework-free way for a plain JavaScript service object — a data store, not a DOM node — to notify subscribers. What does `class Store extends EventTarget` give you, and what does it not?

## The one-line emitter Before `EventTarget` became constructible, giving a non-DOM object events meant pulling in an emitter library or writing a `Map` of callback arrays by hand. Now the platform supplies it: ```js class Store extends EventTarget { #state = { count: 0 }; get state() { return this.#state; } increment() { this.#state = { count: this.#state.count + 1 }; this.dispatchEvent(new CustomEvent('changed', { detail: this.#state })); } } const store = new Store(); store.addEventListener('changed', (e) => render(e.detail.count)); store.increment(); ``` The subclass inherits `addEventListener`, `removeEventListener` and `dispatchEvent`. You can also use `new EventTarget()` directly as a standalone bus if you do not want a class. ## What you genuinely get **A familiar API.** Anyone who has used the DOM already knows how to subscribe. There is no `.on`/`.off`/`.emit` dialect to learn and no divergence between how you listen to a button and how you listen to your store. **The standard listener options.** Because subscription goes through the real `addEventListener`, the options come along: `{ once: true }` for one-shot subscriptions, and `{ signal }` so an `AbortController` can drop many subscriptions at once. A component that already aborts its DOM listeners on teardown can pass the same signal to the store and unsubscribe everything in one call. **Synchronous, isolated delivery.** Listeners run inline during `dispatchEvent`, and one throwing listener does not break the others or the emitter. **Structured payloads.** `CustomEvent`'s `detail` is a documented slot, so subscribers always know where the data lives. ## What you do not get **Anything tree-shaped.** A standalone EventTarget has no parent, so there is nothing for an event to bubble to. Setting `bubbles: true` or `composed: true` on an event dispatched at a bare EventTarget is harmless but meaningless — the dispatch path is just the target itself. If you want events from a child store to reach a parent store, you must forward them explicitly. **Introspection.** There is no API to list listeners, count them, or ask "is anyone subscribed to `changed`?". `dispatchEvent` returns `true` whether ten listeners ran or none did. If you need lazy work only when someone is listening, track subscription yourself by wrapping `addEventListener` — you cannot query it after the fact. **Errors flowing back.** A listener that throws produces a reported uncaught error, not an exception at your `dispatchEvent` call site. The emitter cannot detect subscriber failure; a subscriber that must report failure has to do it through the payload. **Loose argument passing.** Emitter libraries typically let you write `emit('changed', a, b, c)`. Here every emission allocates an Event object and everything must be packed into `detail`. That is slightly more ceremony and a small allocation per emit — irrelevant at UI frequencies, worth measuring in a very hot loop. **Any wildcard or namespacing.** There is no `on('*')`, and matching is exact string equality on the type. ## Design notes for real use Subclassing versus composing is a real choice. `extends EventTarget` is the least code, but it puts `addEventListener` and `dispatchEvent` on your public surface — meaning any caller can dispatch a fake `changed` event on your store. If that matters, hold a private EventTarget instead and expose narrow methods: ```js class Store { #bus = new EventTarget(); subscribe(fn, options) { this.#bus.addEventListener('changed', fn, options); } #emit(detail) { this.#bus.dispatchEvent(new CustomEvent('changed', { detail })); } } ``` This keeps emission private while still reusing the platform's listener bookkeeping and option handling. Second note: subscription is a retention edge. A listener registered on a long-lived store keeps its closure, and whatever the closure captures, alive until it is removed. The `signal` option is the cleanest discipline — tie every subscription to the subscriber's lifetime and abort once. Finally, keep event names namespaced and their `detail` shapes documented. Once several modules subscribe to the same store, those names are an API in every sense, and the fact that the platform will happily accept any string makes it your job, not the platform's, to keep them coherent.