Dom: Make EventTarget subclassable

[domenic]

This isn't very hard. We just give it a useful constructor. Probably by default its "get the parent" always returns null.

I can try to spec something in this area sometime this quarter.

[annevk]

Yeah, if we leave "get the parent" out it's easier. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16487 was the previous iteration of this issue.

[andyearnshaw]

What about making addEventListener, removeEventListener and dispatchEvent intentionally generic? This would allow Object.create to be used to create event targets too. All the following could then work:

let event = new CustomEvent('foo');

let target1 = new EventTarget();
target1.dispatchEvent(event);

let target2 = Object.create(EventTarget.prototype);
target2.dispatchEvent(event);

let target3 = new (class A extends EventTarget {});
target3.dispatchEvent(event);

let target4 = Object.assign({}, EventTarget.prototype);
target4.dispatchEvent(event);

The steps to run through for these methods already make them sound very generic. The only thing that seems to imply otherwise is this sentence in the spec:

Each EventTarget has an associated list of event listeners.

This could be removed from the spec, with text added to addEventListener to "create an associated list of event listeners for target" if one does not already exist, with dispatchEvent and removeEventListener having a step to "fetch the associated list for target" and abort if null.

[domenic]

We're very unlikely to do that as no web platform methods are generic right now. Creating that capability would require extensive spec work in Web IDL and extensive implementation work in browsers, for marginal gain. It would also enable authors to create un-idiomatic "event targets" that don't extend EventTarget, which isn't a goal.

[andyearnshaw]

Fair enough.

[annevk]

Do we get into trouble with IDL if subclasses are do not have constructors? Or is that fine?

[domenic]

You mean, is it a problem that Node is not constructible? No, it should be fine.

[smaug----]

And script libraries will actually use this kinds of event targets without event target chain?

If that is the case, I support this, and the pr is ok. But I'd like to hear some reasoning for this, why we need this feature?

Do script libraries use event target -like objects in performance critical code? Would using native objects slow them? And if so, would they use native EventTarget?
Possibly a bit chicken-egg issue, implementations might get faster over time, but in current implementations there is the native<->JS layer.

[domenic]

And script libraries will actually use this kinds of event targets without event target chain?

Yes. We have a lot of evidence, e.g. people asking for it on StackOverflow (1, 2, 3, 4, see also linked "related questions" in the sidebar of each), or the fact that the browserify events package (which brings Node's hierarchy-less EventEmitter to the browser) is downloaded ~6.5 million times per month.

But I'd like to hear some reasoning for this, why we need this feature?

I see several big advantages over having people ship their own implementation:

• Less code down the wire, with attendant startup performance and bandwidth benefits
• Provides a common foundation multiple libraries can depend on; currently if you include several libraries, each of which needs event-firing functionality, you can often get multiple event implementations, which can be confusing for consumers in addition to causing code bloat.
• Provides pretty nice semantics compared to most library implementations. In particular, without self.reportException(), it's impossible to get the same error-reporting behavior. Most library implementations instead just allow the first throwing listener to block all other listeners, which is not great.

Do script libraries use event target -like objects in performance critical code? Would using native objects slow them? And if so, would they use native EventTarget?

This is a good question I'm not sure I can answer confidently. I can provide anecdotes from my experience as a web developer, which is that events were not that frequent, being used for signaling "changes" in data or "occurrences" from the outside world or similar. I'd guess maybe between 0-10 per second.