Proposal to add EventEmitter to core [ES7]

Andrea Giammarchi andrea.giammarchi at
Mon Jun 1 09:54:48 UTC 2015

Dan Peddle wrote me without replying to all about the limit that is
configurable ... yes, I know that, but having no limit on core or a
configurable limit different from 10 would make again the new thing
inconsistent with current EventEmitter in node.

Again, I'd rather migrate to a new standard than bring EventEmitter as it
is from node.js world to core, and also using traits.


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

> 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