Seems good to me

Thank you @Fedik!

Having now been pointed at this in #11299, I feel the need to ask why we need Joomla.Event.dispatch and Joomla.Event.listenOnce but instead of providing Joomla.Event.listen we require window.addEventListener?

Arguments for providing Joomla.Event.listen:

1. Style & elegance
2. If at a later date we want to change the way Events work.

require window.addEventListener?

Yes, that’s basic and fundamental browser js API. We are not jquery creating our own API that is a proxy to to the native API the only cases we do it is by creating a helper eg Joomla.request()

So why do we create Joomla.Event.dispatch when there is a window.dispatchEvent native API?

And why not have:

Joomla.Event.list = function(element, name, callback) {
    element.addEventListener(name, callback);
}

which only has a tiny overhead on registering the listener and no impact when the event happens, but provides both an consistent solution and also one which is potentially extendable if for any reason we ever want to extend the model beyond the standard one.

@Sophist-UK the main direction is to use nativ JS,

Joomla.Event.dispatch is just a shurtcut/wrapper/helper, and way to say "Joomla! have it",
and instead of do:

var event = new CustomEvent('blablaevent', {
	detail:     params,
	bubbles:    true,
	cancelable: true
});
element.dispatchEvent(event);

we can do Joomla.Event.dispatch('blablaevent')

And in opposite to dispatchEvent, <element>.addEventListener is a very easy thing, where Joomla.Event.listen will be not a very helpful wrapper ?
And also we want that user use more native JS.

Also it make Joomla! more friendly to new/"non Joomla!" developers, as they can use skills which they already learned while worked with JavaScript somewhere else.

I do not mind if someone add Joomla.Event.listen, but it does not make much profit, and most of a time no one will use it.

but provides both an consistent solution and also one which is potentially extendable if for any reason we ever want to extend the model beyond the standard one.

We stick to a native events, and as long as they works, we do not have to worry about it ?

I am not disagreeing with the decision to go with native JS rather than using e.g. jQuery / MooTools, but as an example of how we might like to extend it, it might be nice to have the Javascript equivalent of the PHP Joomla Debug block if Joomla debugging is on. If you feed all Event and Ajax calls through lightweight helpers, then adding this is a small change with minimal overhead.

P.S. jQuery / Mootools exist because at the time they were written:

a. Native browser functionality did not exist for a lot of the functionality, and frameworks like these provided pre-written standardised ways of doing them; and

b. The functionality that browsers did have differed across browsers, and frameworks allowed those to be hidden and to have common code that ran on all browsers.

These problems have largely gone away - which is why ditching MooTools and jQuery makes sense. But that doesn't mean that there is never a need to add advanced functionality not provided by browsers natively.

@Sophist-UK I understood your idea

But let's keep it simple for now, we always can add it later if there will be more request for it ?

When I get the chance I will submit a PR to 4.0 to add the debugging capability.