TC39 June 2019 Notes

[pemrouz]

Emitter moved to Stage 1 at the June meeting 🎉. There was also lots of productive conversations, support and ideas I want to explore before thinking about Stage 2:

• @codehag and Felienne introduced some empirical approaches to moving the language forward. Use of a more objective framework to answer questions can help lead to a better design as well make discussions more likely to converge. Before this meeting we had some sessions where we let developers use the library and just observed. There was insightful feedback (e.g. @rpamely expected running and evaluating to be the same, where run either returns the value or a promise for the value rather than separate sync/async concepts for this). I'm hoping we can follow up to colloborate on a larger scale for this proposal:
  • Design a series of problems we can give to a few training class of students and observe how they solve it. @erights articulated this well: that the theory people develop is often different to what the original authors intended. Even if this doesn't lead to any visible API tweaks, it will help us teach this better rather than try to explain how it's derived from first principles.
  • We want the library of operators to be high power-to-weight ratio, avoid a proliferation of hundred's of operators, and hence not keep coming back to the committee for lots of tiny additions. Even if we consciously break it down across different proposals, at least we all understand the longer term vision and reason for staggering. The initial refined set proposed has been sufficient across all the use cases trialled so far, however it would be good to create a broader, public survey of things people would like to see move from common utility libraries into the platform, categorise and rationalise the results to amend the proposed list with.
• We ideally want to ensure we can effectively replace existing popular third-party libraries. Publishing as a library to npm and iterating to work towards would be a indicator of achieving that goal. There wasn't consensus on replicating particular cases (replicating some things were considered actively harmful), or a particular adoption rate being a requirement for stage advancement, as we don't require that for other proposals and there's also other ways to achieve this. Validating with and incorporating developer feedback is the main goal, as you can embed into a deeply entrenched npm dependency and reach high counts without that feedback, and you can get that feedback without embedding into a deep dep to reach a certain count.
• Several companies mentioned they have backed out of using Observables (including the champions). Will set up some meetings to discuss further and see if we can colloborate more closely to evaluate how this scales up in different companies.
• There was some interesting discussions on how the stats libraries might benefit from this. I want to start thinking ahead sooner about that use case and will kick start a separate working group to start thinking about the requirements. If anyone has thought or worked on this before, please let me know!
• Will set up a meeting with @erights and XS engine folks to discuss from the perspective of resource-constrained devices. This should be a significant upgrade for applications in terms of not having to pull in additional libraries for most cases, memory profile since it does not serialise intermediate representations by design, and CPU performance as the hot path of sending values can be optimised relative to other approaches.
• Very useful to sit down with @annevk and @domenic to discuss and resolve some finer details related to the use case of improving the ergonomics of EventTarget:
  • The send operation and unsubscription should remain synchronous.
  • This means interacting with preventDefault/stopPropagation/stopImmediatePropagation which causes side-effects works fine. Need to check in test cases, particularly for the return value of dispatchEvent, and capturing phase.
  • element.on('click') vends a different Emitter every time it's called. This is good, as you don't want one consumer resolving it to stop other consumers. stopImmediatePropagation means whether the platform internally creates one listener or different ones for each is not an implementation detail: there needs to also be different listeners created for each. @domenic also mentioned didn't think stopImmediatePropagation was generally a great idea, so if platfom doesn't want to support that here then they would have flexibility on this.
  • There's already a way to identify when an event is not preventable that can be used (event phase none) if a user e.g. tries to prevent an event after a second etc.
  • Need to support additional options of addEventListener: passive and capture. Target phase not needed. once: true is not necessary, the once helper is better for this (notably, node already shipped something similar).
  • Did not think the node PR to make emitter.on('event') async iterable was a good idea (turning push to pull) and would prefer to hold off for now. My plan is to prioritise working with @mcollina / @MylesBorins to get something working behind a flag as experimentation is a bit easier there. I'll set up a regular recurring working group meeting for interested parties, once every two months between the committee meetings to discuss and agree on issues like this together (e.g. what the async iterator should do).
• @annevk also mentioned it would be great to support the newer Observer API, being able to create an Emitter and allow developers to benefit from the same set of utility methods. These platform API did not use EventTarget since it was quite bloated/slow. I don't have many thoughts on this atm, so welcome any ideas. I'll create a gist with some options for discussion and review later on.
• We changed the concurrency example in the final deck with @robpalme and @syg: separate limit operator (previously buffer), rather than part of the runner (run.limit). @bterlson also suggested this. The trade-off is that this is more readable, and powerful/composable to be able to constrain the flow at any part of the pipeline, but may not be as efficient (need to investigate).
• There was an early example in WeakRefs material about the event listener use case and was something I wanted to previously explore. After thinking about it, I couldn't see which use case we'd be improving (if either the pointer to a parent and/or child is weakly held), and may even make things worse (e.g. relying on GC-semantics to trigger unsubscription logic). @tschneidereit confirmed this would not be a good idea with some useful insights from how they did it in ActionScript. This saves us a month or two of work 💯.
• Will catchup with @gsathya to discuss relation and collaboration with the collection helpers proposal once we're both in London. They can be largely be expressed as a transform followed by serialising a new particular collection (identifiable via constructor/species). In that sense, they can be useful shortcuts for the common case of creating new collections of the same type, but comes down to whether we want to encourage that pattern which will create redundant copies rather than lazily creating the final one. Also it's been great to have @syg's feedback/intuition as an implementor. I'll create some documentation on architecture for more feedback from implementors.
• Work with more partners on drafting spec text