proposal: rewrite source in typescript

Proposing refresh ⟳ to rewrite core into TypeScript

It would be great to give this library a refresh ⟳ since its initial implementation design, additionally bringing some of the new ES2018+ features. I am more than willing to revel my efforts to achieve these goals.

This issue should serve the purpose of the TS rewrite proposal discussions and outline for new architectural updates (if any) and the new capabilities and/or ES+TS features desired.

---

ES/TS feature harnessing proposals

• ✓ [ ] 🅧 [ ] Generators or Iterators function* || closure, yield, next() for emit augment
• ✓ [ ] 🅧 [ ] TypeScript private || protected property accessors
• ✓ [ ] 🅧 [ ] ES #private truly private names, solves #178
• ✓ [ ] 🅧 [ ] (experimental) decorator support
• … to add more

Architectural change proposals

• ✓ [ ] 🅧 [ ] Functional programming for named module consumption
• ✓ [ ] 🅧 [ ] Functional composition instead of inheritance like developit/mitt
• ✓ [ ] 🅧 [ ] Handler result memoization for observability
• … to add more

[DigitalBrainJS]

IMHO there are no practical reasons to rewrite the lib in TS.

• the library is tiny for contributors to face type issues in the source code, this is definitely not a huge enterprise project
• the number of JS developers is much larger than the TS developers, which affects the number of potential contributors on which the survival of the project depends.
• low-level libraries like this need to have the best performance and support the maximum number of platforms, while using some kind of transpiler will kill both of them. Even some features of the latest ES standards provide slightly worse performance than ES3 / ES5, and transpiled code has much worse performance in most cases.
• In fact, TS users don’t care what language the package is written in as long as an external d.ts is provided and JS users don’t need TS at all.
• It is more logical to spend energy on bug fixing, optimizing, and developing the library than just on changing the code style.
• ES decorator is a plain data structure, it can be provided even by the package written in ES3 and importing in the project that uses the newest EСMA version. I may be wrong, but TS’s decorators are not ECMA compliant, so they cannot be used from ECMA source code. This library is primarily for the JS ecosystem.
• we can just use the Symbols properties to make inner props non-enumerable without any performance issues.

[RangerMauve]

Yeah, TS seems like it’s popular, but personally I’d like to prioritize what the maintainers are comfortable with, so it might be best to go with a new TS-specific EventEmitter library rather than changing this one so drastically.

Thank you for floating the idea by though!

Gonna close this for now unless some more maintainers are interested in discussing this further. 😁