A classic for loop runs the predicate exactly once per element and pushes into one of two buckets. Returning a tuple [pass, fail] lets the caller destructure cleanly: const [yes, no] = partition(...). Compared to [arr.filter(p), arr.filter(notP)], this version is twice as fast on large inputs and correct even when the predicate is impure (e.g. randomised, time-based, or one that mutates a counter). The third predicate argument matches the Array.prototype.filter contract (item, index, array), so any predicate that works with filter is a drop-in here.

When the codebase prefers expression-style helpers (no statements, no temporary let), reduce produces the same result with a single traversal. The accumulator is a pre-built [[], []] tuple and the predicate decides which bucket index (0 or 1) receives the item. Performance-wise this version and the imperative one are within a few percent in V8, so pick whichever reads better in your codebase. Avoid the temptation to write acc[predicate ? "pass" : "fail"] with object keys; the array-of-arrays shape is what makes destructuring at the call site so ergonomic.

A two-bucket split breaks down quickly: tri-state validation (valid / invalid / pending), HTTP status classes (2xx / 4xx / 5xx), or transaction sign (debit / zero / credit). partitionBy generalises by letting the classifier return any label and bucketing into a Map. Map keys preserve insertion order, which is why iterating later yields buckets in the order their first-seen labels appeared. This is essentially groupBy, but framing it as a partition emphasises that every item goes into exactly one bucket and the labels are typically a small fixed enum rather than free-form keys.

Real production data often arrives as a stream: rows from a paginated API, lines of a log file, messages off a queue. Using an async iterable with for await keeps memory bounded to whatever the source yields per tick, instead of materialising the entire dataset before partitioning. The predicate stays synchronous here, but the same loop trivially supports await predicate(item) if classification needs a lookup. The trade-off is that the result is fully materialised at the end; if even the buckets are too large, switch to writing each item to two output streams instead of two arrays.