First example doesn't work though:

    const greeting = pipe('hello')
       | upper
       | ex('!!!')

    await greeting.run() // → "HELLO!!!"

If you look at the tests file, it needs to be written like this to make it work:

    let greeting;
    (greeting = pipe('hello')) | upper | ex('!!!');
    await greeting.run();

Which is not anymore as ergonomic.

    const greeting = pipe('hello');
    greeting | upper | ex('!!!');
    await greeting.run(); // → "HELLO!!!"

    const greeting = pipe('hello');
    greeting / upper * ex('!!!');
    await greeting.run(); // → "HELLO!!!"

Further proof that JavaScript accidentally became the new C++.

“Aren’t you surprised that this syntax works?” is not praise for a language design.

I love the idea! The creativity of (ab)using JavaScript type coersion is really neat. I did something similar using proxies to create a chainable API.

https://dev.to/sethcalebweeks/fluent-api-for-piping-standalo...

  const shuffle = (arr) => arr.sort(() => Math.random() - 0.5);
  const zipWith = (a, b, fn) => a.slice(0, Math.min(a.length, b.length)).map((x, i) => fn(x, b[i]));
  const log = (arr) => {
    console.log(arr);
    return arr;
  };

  const chain = chainWith({shuffle, zipWith, log});

  chain([1, 2, 3, 4, 5, 6, 7, 8, 9])
    .map((i) => i + 10)
    .log() // [ 11, 12, 13, 14, 15, 16, 17, 18, 19 ]
    .shuffle()
    .log() // e.g. [ 16, 15, 11, 19, 12, 13, 18, 14, 17 ]
    .zipWith(["a", "b", "c", "d", "e"], (a, b) => a + b)
    .log() // e.g. [ '16a', '15b', '11c', '19d', '12e' ]
    [0]; // e.g. '16a'

Since this library leverages Symbol.toPrimitive, you may also use operators besides bitwise-OR. Additionally, the library does not seem to dispatch on the `hint` parameter[0]. Now I want to open a JS REPL, try placing this library's pipe object into string template literals, and see what happens.

Overall, cool library.

[0] https://tc39.es/ecma262/multipage/abstract-operations.html#s...

In case it might interest anyone, I wrote a similar vanilla JS function last year called Chute. Chute chains methods and function calls using dot-notation.

https://github.com/gregabbott/chute

Neat, but I think that functions already do what we need.

For one thing, the example isn't the most compelling, because you can:

    const greeting = 'hello'.toUpperCase() + '!!!';

or

    const greeting = 'HELLO!!!';

That said, there is already:

    function thrush(initial, ...funcs) {
        return funcs.reduce(
            (current, func) => func(current),
            initial);
    }

    const greeting = thrush('hello', s => s.toUpperCase(), s => s + '!!!');

  const greeting = thrush(
    'hello',
    s => s.toUpperCase(),
    s => s + '!!!'
  );

  const upper = asPipe(s => s.toUpperCase())
  const ex = asPipe((s) => s + '!!!')
  const greeting = pipe('hello')
    | upper
    | ex
  await greeting.run()

If you're interested in the Ruby language too, check out this PoC gem for an "operator-less" syntax for pipe operations using regular blocks/expressions like every other Ruby DSL.

https://github.com/lendinghome/pipe_operator#-pipe_operator

  "https://api.github.com/repos/ruby/ruby".pipe do
    URI.parse
    Net::HTTP.get
    JSON.parse.fetch("stargazers_count")
    yield_self { |n| "Ruby has #{n} stars" }
    Kernel.puts
  end
  #=> Ruby has 15120 stars

  [9, 64].map(&Math.pipe.sqrt)           #=> [3.0, 8.0]
  [9, 64].map(&Math.pipe.sqrt.to_i.to_s) #=> ["3", "8"]

Sad that the pipe operator proposal seems to have stalled.

The F# version of the proposal was probably the simplest choice.

This kind of stuff is why C++ developers has an almost overly allergic reaction to operator overloading.

Nice! I love it when a language introduces new syntax for things that weren't remotely difficult in the first place!

is this solving a problem people actually have?

other libraries like rxjs use .pipe(f,g,h) which works just fine.

Pipes are great in environments where "everything is a string" (bash, etc), but do we really need them in javascript? I have yet to see a compelling example.

Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.

It would be nice to have well-maintained fluent/pipe/streaming API solution for Python.

This is just different syntax for nesting function calls (i.e. c(b(a(value))) becomes value | a | b | c), right? Definitely would make code more readable if this was just something in JS or a compiler where it’s the same as normally calling functions.

Won’t work in TS.

I would actually love extension of TS with operator overloading for vector maths (games, other linear algebra, ML use cases). I wouldn’t want libraries to rely on it, but in my own application code, it can sometimes be really helpful.

    // Examples
    var cmd = Cli.Wrap("foo") | (stdOut, stdErr);

    var target = PipeTarget.Merge(
        PipeTarget.ToFile("file1.txt"),
        PipeTarget.ToFile("file2.txt"),
        PipeTarget.ToFile("file3.txt")
    );

    var cmd = Cli.Wrap("foo") | target;

Overengineered in my view, what is wrong with `x | f` is `f(x)`? Then `x | f | g` can be read as `g(f(x))` and you're done. I don't see any reason to make it more complicated than that.

Alternatively just use F# and Fable

Pipe "operator" for the rest of us:

    Object.prototype.pipe = function(fn) { return fn(this) }

    'hello'.pipe(upper).pipe(ex('!!!'))

Or code golf version:

    Object.prototype.P=function(...F){return F.reduce((v,f)=>f(v),this)}
    'hello'.P(upper,ex('!!!'))

I know that it's wrong but I love it.

I am wondering if it could be useful for libraries:

    grid.columns.name.format(v => v | trim | truncate | bold)
    form.fields.name.validate(v => v | trim | required | email)

That's clever! But I still want JS to get the actual pipeline operator.

Piping syntax is nice for reading, but it's hard to debug. There's no clear way to "step through" each stage of the pipe to see the intermediate results.

I'm not sure this is at all a good idea but thanks to the great discussion here at Hacker News - it is now up on npm:

npm i aspipes

Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.

It's simultaneously a miracle and deeply wrong that this worked.

> “Aren’t you surprised that this syntax works?” is not praise for a language design.

It's a clever hack. This is Hacker News. Let's try to appreciate clever hacks while here.

It is not a surprise that overriding the implementation of an operator’s type coercion works and overrides the behavior of the operator’s type coercion.

Is there a language that can’t be contorted in surprising ways that I’m unaware of?

Nothing new. This was 15 years ago:

https://github.com/tbtlr/def.js

No way dude, this does a disservice to the insanity that is C++'s syntax. Wake me up when you have 6 different initialization syntaxes or fun things like 4[array]

Agreed!!!!

Serious q: but how does this sentiment change with LLMs? They can pickup new syntax pretty fast, then use fewer tokens...

Pipes are great where you want to chain several operations together. Piping is very common in statically typed functional langauges, where there are lots of different types in play.

Sequences are a common example.

So this:

    xs.map(x => x * 2).filter(x => x > 4).sorted().take(5)

In pipes this might look like:

    xs |> map(x => x * 2) |> filter(x => x > 4) |> sorted() |> take(5)

In functional languages (of the ML variety), convention is to put each operation on its own line:

    xs 
    |> map(x => x * 2) 
    |> filter(x => x > 4) 
    |> sorted() 
    |> take(5)

Note this makes for really nice diffs with the standard Git diff tool!

But why is this better?

Well, suppose the operation you want is not implemented as a method on `xs`. For a long time JavaScript did not offer `flatMap` on arrays.

You'll need to add it somehow, such as on the prototype (nasty) or by wrapping `xs` in another type (overhead, verbose).

With the pipe operator, each operation is just a plain-ol function.

This:

    xs |> f

Is syntactic sugar for:

    f(xs)

This allows us to "extend" `xs` in a manner that can be compiled with zero run-time overhead.

    take(sorted(filter(map(xs, x => x \* 2), x => x > 4)), 5)

    xs |> map(x => x \* 2) |> filter(x => x > 4) |> sorted() |> take(5)

    xs
      |> map(%, x => x * 2)
      |> filter(%, x => x > 4)
      |> sorted(%)
      |> take(%, 5);

    xs.map(x => x * 2)
        .filter(x => x > 4)
        .sorted()
        .take(5)