Ben Lesh

So the goal of this is to do some additional processing to the raw stream data as it arrives? I think I see the issue, if you have some format...

(Sorry it took me so long to find this one, BTW) :(

It's funny, I actually spoke directly to @isaacs (the author of the Zalgo blog article) about this a long time ago (probably 2015) when I ran into him at a...

On the front of "hot" and "cold": Really what you're talking about is forced multicast. That comes with complications and overhead. `EventTarget#when` will _always_ be "hot" and force multicast. That's...

> Events emitted by the browser will always have a microtask checkpoint before going back into native code TIL, @esprehn, thanks! That's good news. However there are still issues with...

> Observable.from(AsyncIterable.from(e.data.rows)) This is a magic recipe though. Forced asynchrony adds unnecessary complexity and overhead to the type. It introduces a lot of unknowns and questions and untested behaviors that...

I'm totally willing to die on this hill, honestly. Even the title of this thread unfairly characterizes the behavior of this very basic type as "unpredictable", when it's in fact...

Thinking about this even more. If there was forced scheduling, testing observables becomes even more cumbersome. ```ts it('should handle events via an observable', async () => { const target =...

Now.. all of this said, if you _really_ wanted to consume an observable with forced asynchrony, it implements `Symbol.asyncIterator`. So all you'd have to do is consume it in a...

After the discussion the other day, I tossed together a "hot observable", for sake of helping me think through it, and it predictably raises questions: 1. Should it be reference...