| 15:23 | <ljharb> | anything that encourages less use of classes helps DCE |
| 15:24 | <ljharb> | It removes a friction from function usage - thereby incentivizing plain functions more than currently |
| 15:27 | <ljharb> | call-this requires receiver-sensitive functions, which means it only helps with that subset. pipeline helps with function chaining. The two work in concert and simply don’t solve each other’s use cases. |
| 15:29 | <ljharb> | pipe doesn’t help with a single function call - it helps with multiple nested ones. |
| 15:31 | <ljharb> | “difficulty in making a mistake and realizing it” is far more important than “easy to fix”. Code is read far more often than it’s written, and readability should always trump writeability |
| 16:05 | <Richard Gibson> | your use of "solve" implies identification of problem statements which I think have not been sufficiently articulated (hence pipeline being at stage 2 for a long time, and call-this staying at stage 1). Pipeline at least has general agreement on something like "developer experience for linear data flow is bad" and I think just needs to get precise w.r.t. scope and cement a topic token (and finally face the consequences upon PFA). Call-this has thus far also made arguments around DX, which have not been well-received (and bizarrely seem to ignore Reflect.apply), but I think the recent developments can allow it to pivot to something like "class-oriented patterns (and more generally, receiver-sensitive functions) hinder tree-shaking, resulting in excessive delivery of unused code to end users", accepting that the solution for that problem might not actually include syntactic call-this (although that certainly seems to me like a plausible result) |
| 16:05 | <Richard Gibson> | how would you phrase them? |