Proposal to add EventEmitter to core [ES7]

Andrea Giammarchi andrea.giammarchi at
Mon Jun 1 09:01:26 UTC 2015

Just to avoid misunderstanding ...

> without even reading what DOM had to offer before

I meant it went out through a pragmatic approach with a non Events based
emit model and few inconsistent choices regarding listeners in terms of
both interface and the inability to interfere with non owned ... we need a
better approach to EventListeners if it has to be implemented in core,
something that could work in both client and server world.

Again my 2 cents

On Mon, Jun 1, 2015 at 10:58 AM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> -1
> not only node implemented EventEmitter without even reading what DOM had
> to offer before, I see whatever EventEmitter proposal would land in ES7
> something related to lightweight traits, and not a class to extend.
> Extending EventEmitter without having the ability to extend something else
> looks like a poor choce to me, having a list of well known traits including
> the EventEmitter one would be better.
> About current node implementation:
>    1. it doesn't accept objects as listeners, a not so common but actully
>    widely used practice on the WEB
>    2. it does accept multiple times the same listener, a footgun on
>    DOM-land
>    3. it has a maximum amount of listeners per objects, a footgun on
>    DOM-land
>    4. it has an `on` method but not an `off`, not convenient on DOM where
>    an app doesn't have same listeners forever due Ajax/client<->server
>    interaction nature, I'd like a more consistent naming convention
>    5. it exposes the ability to remove/retrieve listeners you don't own,
>    again a footgun on DOM or anywhere the code is own by multiple libraries
>    and authors
> Just my 2 cents.
> Regards
> On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 <aakarsh1997 at>
> wrote:
>> Hi,
>> I propose the inclusion of the node/io EventEmitter class[1] in core
>> targeting ES7.
>> Reasoning:
>> The .on/.emit model is very popular[2] in the ECMAScript land, and it
>> suits the language a lot. We use events pretty much everywhere in the JS
>> land.
>> It makes sense for the standard EventEmitter class used commonly to be
>> included in core. With ES6 classes, userland code classes extending[3] the
>> EventEmitter class would be pretty common and useful even in environments
>> like browsers.
>> Notes:
>> I think the `.once` method from the node/io EventEmitter class _could_ be
>> left out from standard implementation mainly because we would rather use
>> Promises there. Although it would also make sense to keep it in for further
>> compatibility.
>> [1]
>> [2]
>> [3]
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list