You basically need a lightweight pub/sub mechanism that doesn't carry the baggage of events

I'm curious about this statement. What's the baggage? What if, for example, ElementInternals inherited EventTarget, and that's where those events were dispatched?

You basically need a lightweight pub/sub mechanism that doesn't carry the baggage of events

I'm curious about this statement. What's the baggage? What if, for example, ElementInternals inherited EventTarget, and that's where those events were dispatched?

I’m not actually sure, but my understanding was that the web platform got a bunch of Observer objects for certain things (MutationObserver, IntersectionObserver, ResizeObserver, etc) because using events for it would have been too slow. If events are acceptable, that is obviously a better solution. Though whatever API is chosen should work with native elements too. Would it be possible to get access to their ElementInternals object?

MutationObserver just needed a callback so that's why it was designed that way. I strongly suspect the other observers are copypasta. I don't think it had to do with cost per se. The cost of having to call into JS from C++ prolly dwarfs the cost of an event listener callback vs a regular callback.

EventListener callback itself isn't really any different to other callbacks.
Event dispatch through DOM does add overhead, since one needs to create DOM path for the dispatch, but that cost doesn't really apply if the event doesn't propagate outside its target (which is the case with non-DOM-Node-non-IndexedDB EventTargets).

The reason for MutationObserver (which is the first *Observer) design is that we wanted to optimize out dispatching tons of events all the time, like what happens with Mutation Events. And since MutationObserver didn't really have any need for being an EventTarget (since it handles only one types of 'events'/'notifications') it was enough to give it a callback.

composing multiple listeners from different sources

I don't understand what this means. Is this about multiple inheritance? Like

class WebComponentA extends HTMLElement {
  connectedCallback() {
    console.log('A');
}

class WebComponentB extends WebComponentA {
  connectedCallback() {
    super.connectedCallback();
    console.log('B');
}

@NickGard Multiple inheritance is orthogonal, but would also require this problem to be solved.

Here’s an example of using helpers to add element behaviors:

ElementClass.js:

import { defineProps, makeFormAssociated } from "util.js";

class ElementClass extends HTMLElement {
	// stuff, including doing stuff when element is connected
}

defineProps(ElementClass);
makeFormAssociated(ElementClass);

util.js:

function defineProps (ElementClass) {
	// Do stuff when ElementClass instance is connected, among other things
}

function makeFormAssociated (ElementClass) {
	// Do stuff when ElementClass instance is connected, among other things
}

Lit has a reactive controller pattern which I think could work well, if something like ElementInternals exposed more of the element's mechanics, such as lifecycle hooks. Lit's model is more like:

class MyElement extends LitElement {
  #mouse = new MouseController(this);
}

MouseController inherits from ReactiveController which co-operates with LitElement to hook into the lifecycle callbacks. I imagine the lit team (@justinfagnani can likely confirm) would benefit from there being a more general "lifecycle event dispatch" object, even if that were for example ElementInternals; so the ReactiveController can become a bit like "Friends" in the C++ sense.

class MyElement extends HTMLElement {
  #internals = this.attachInternals();
  #mouse = new MouseController(this.#internals);
}