Pipe reads top-to-bottom in source code: the first function receives the input, and each subsequent function transforms the previous result. Array.prototype.reduce over the function list with the input as the seed is the entire implementation. This is the order most developers find intuitive (data flows left-to-right, like a Unix shell pipeline) and it matches the proposed pipe operator (|>). Use pipe whenever the human reading the call site cares more about data flow than about mathematical composition.

Compose runs the rightmost function first, mirroring math notation f(g(h(x))). Switching reduce to reduceRight is the only change versus pipe. This convention is the default in Haskell, Ramda, and Redux's middleware composition, so it keeps muscle memory consistent for developers coming from those ecosystems. Whether you prefer compose or pipe is mostly stylistic, but in mixed teams pick one and stick with it: stacking both in the same module is the surest way to confuse the next reader.

Real-world pipelines mix sync and async steps (parse JSON, then fetch, then transform). pipeAsync awaits each step before passing the result to the next, so any function in the chain can be either synchronous or async and the chain just works. The explicit for..of (instead of reduce) is necessary because reducing across Promises requires either then-chaining manually or a top-level await, and the loop form is the cleanest expression of "resolve, then continue". Pair this with retry / timeout decorators to build full data pipelines in user code.