| 12:16 | <annevk> | zcorpan: did https://github.com/whatwg/html/pull/4079 affect any other implementations? |
| 12:16 | <annevk> | zcorpan: it'd be good to have impl bugs in that case |
| 12:21 | <zcorpan> | annevk: yes. I'll file |
| 12:21 | <annevk> | zcorpan: thanks, I also have a PR coming up with an editorial nit |
| 12:26 | <zcorpan> | firefox doesn't seem to run the test to completion |
| 12:26 | <zcorpan> | oh wait no it did |
| 12:29 | <zcorpan> | but noopener doesn't seem to do anything in firefox for this test. Did it work before? |
| 12:33 | <annevk> | i don't actually know |
| 12:33 | <annevk> | perhaps it was blocked on figuring out the interaction with CSSOM stuff? |
| 12:34 | <annevk> | hmm no, no open bugs |
| 12:35 | <annevk> | (about that in particular) |
| 14:00 | <zcorpan> | Help (need to sync html5lib-tests to wpt)? https://bugs.chromium.org/p/chromium/issues/detail?id=704534#c8 |
| 16:32 | <`slikts> | the streams api faq calls observables a bad fit for i/o -- why is that? |
| 16:32 | <`slikts> | just because of no backpressure? |
| 16:46 | <annevk> | Multiple consumers also seems like a key difference |
| 16:48 | <annevk> | Note also how streams has a bunch of branching to do bytes really well |
| 16:51 | <`slikts> | doing bytes well would be a reason why streams are better, not why observables are bad for io, and I'm not sure why multi-consumer is bad for io |
| 16:51 | <`slikts> | just trying to understand |
| 16:52 | <`slikts> | the only thing clear so far is that since there's no (async) backpressure, too much streaming would degrade the performance for other things running in the thread |
| 16:56 | <annevk> | Multi-consumer means memory bloat to some extent |
| 16:56 | <annevk> | And backpressure is imp |
| 16:57 | <`slikts> | you could still have just one subscriber even with observables, though |
| 16:58 | <`slikts> | just like you can fork streams and have more, it's just single by default |
| 17:01 | <`slikts> | I don't particularly like observables, though, based on this presentation: https://docs.google.com/presentation/d/1r2V1sLG8JSSk8txiLh4wfTkom-BoOsk52FgPBy8o3RM |
| 17:02 | <`slikts> | where it compares how much simpler implementing the combinators becomes with async iterables and generators |
| 17:14 | <annevk> | Yes but you’d need to buffer in case someone else subscribes later? Maybe that is not how that works, but it seems transferables would break down at least |
| 17:20 | <`slikts> | subjects don't buffer; they're like event emitters, the events go nowhere if there's no subscribers |
| 17:22 | <`slikts> | I'm not deeply familiar with observables, though, so not confident about anything |
| 17:27 | <annevk> | Transferables only work 1:1 |
| 17:58 | <zcorpan> | good times http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6278 |
| 18:06 | <Domenic> | `slikts: as annevk briefly mentioned, you lose data with observables since they only push out to current subscribers. You can layer stuff on top of obesrvables (or EventTarget) to fix this, like adding your own buffering. But it's awkward and nonstandard. |
| 18:09 | <`slikts> | Domenic: I see, thanks |