proposal: rewrite source in typescript

[zgover]

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 EventEmitter properties are iterable #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

[RangerMauve]

Interesting idea.

Would it be worth it to maybe create a new library which includes all this fancy TS stuff?

[zgover]

@RangerMauve I have made that consideration, but also considered existing consumer experience to avoid adoption discovery. The implementation architecture for consuming the library would ultimately remain the same, but providing strongly typed source code to support clarity of maintenance and logic.

Did you have a specific reservation or objection to migrating the current library?

[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. 😁

[zgover]

I can clearly see who is against TypeScript in a general perspective (@DigitalBrainJS ), or usage strongly typed languages, or rather is it just new technologies still existing under the sum total adoption?

In any answer, with respect; sadly your objection is weight purely by informal and formal fallacious arguments so I have to refute most of your listed objections. A majority of your bullet items are subjective and are indicative of a biased opinion. Likely due to limited visibility, experience, knowledge of migration success rates of heavily adopted libraries, or negative peers, articles which made objections in a similarly shared approach using inferred subjective speech; detailing a couple issues with truthiness within a finite number of workflows easily avoided or substituted with minor degradation if any. Then surrounding it with own objections to influence disproportionate interpretation to manipulatively persuade holistic opinionated beliefs. Maybe even showing a statistical analysis and/or graph easily identifiable as fake, lacking authenticity or validity after completing the first week of statistics class.

Contextually speaking, amongst vendors and engineering teams whom of which history has proven observable empirical evidence of maintaining strict contribution guidelines, often deny and close PRs/Issues simply due to roadmaps and/or frequent mentions lacks evidence of the request, or even more commonly seen with arbitrary edge cases; in perspective, core maintainers, owners and directors have focused targets possessing dedications demonstrating the acknowledgment of constituting facets comparative to maintainability, readability, supporting all major and minor adoptions of surrounding technologies to enable reaching the largest potential number of targeted consumer audience from providing compatibility in both progressive and backwards direction.