The pipeline operator |> is a proposed JavaScript feature that lets you chain operations in a more readable way. Instead of nesting function calls inside each other, you can write them left-to-right. This matters because deeply nested function calls are hard to read and a common source of bugs.

When you have to read code like h(g(f(x))), your brain has to work backwards from the inside out to understand what’s happening. The pipeline operator lets the code flow naturally from left to right, just like how we read.

The current TC39 proposal (Stage 2) uses Hack pipes, where % is a topic token representing the value from the previous step. This means you write the function call explicitly, placing % where the piped value should go.

How the Pipeline Operator Works

The pipeline operator takes a value on the left and passes it into the expression on the right, where % represents that value:

Each step in the pipeline evaluates the expression on the right with % bound to the result of the left side. If any step throws an error, the pipeline stops there.

A Practical Example

Processing text is a common task that often requires multiple transformations. Think of validating user input, cleaning content for a CMS, or normalizing data for a database. The pipeline operator shines in these scenarios:

The pipeline version shows exactly what happens to the data at each step. You can read it like a recipe: take the name, sanitize it, trim it, then capitalize it. The % topic token makes it explicit where the value goes — and it also works with multi-argument functions like name |> sanitize(%, 'strict'). If another developer needs to add a step (like checking for profanity or validating length), they can simply add a new line to the pipeline without restructuring nested function calls.

Current Status

The pipeline operator is a Stage 2 proposal, which means:

• It’s not part of JavaScript yet
• You need Babel to use it
• The syntax might change

To use it with Babel:

When to Use The Pipeline Operator

The pipeline operator excels at handling data transformations - when you need to process data through multiple steps. Think of functions that each take one main argument and return transformed data for the next step.

This approach makes testing straightforward - each function can be verified in isolation. You can check that calculateTotal works correctly without worrying about validation or tax calculations. When something goes wrong, you can quickly identify which transformation caused the issue since the data flows in a clear, trackable sequence.

Need to add a new step like fraud detection? Just add another function to the pipeline. No need to dig through nested function calls. Each function is also a standalone unit that can be reused in other contexts. Maybe you need to calculateTotal for a shopping cart preview, or formatForSaving for a draft order.

The Hack pipes variant was chosen over the earlier “minimal” (F#-style) proposal because the topic token % works naturally with multi-argument functions, method calls, and arbitrary expressions — not just unary functions.

The pipeline operator isn’t just about making code prettier - it’s about making it more maintainable, testable, and easier to reason about. When each transformation is a clear, single-purpose function, you build a toolkit of reliable operations that can be combined in different ways.