41 comments

[ 2.4 ms ] story [ 66.7 ms ] thread
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...

Very appealing.
Sad that the pipe operator proposal seems to have stalled.

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

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

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

> “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.

Nice! I love it when a language introduces new syntax for things that weren't remotely difficult in the first place!
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.
That is a big enough DX problem that I would veto using this on a project.

You’ve implied what I’ll state clearly:

Pipes are for composing transformations, one per line, so that reading comprehension doesn’t nosedive too fast with accumulation of subsequent operations.

Chaining on the same line is shit for readying and worst for git merges and PR reviews.

(comment deleted)
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.
It would be nice to have well-maintained fluent/pipe/streaming API solution for Python.
is this solving a problem people actually have?

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

This kind of stuff is why C++ developers has an almost overly allergic reaction to operator overloading.
Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
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.

This cargo seem to give magical superpowers.
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 + '!!!');
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.
That's clever! But I still want JS to get the actual pipeline operator.
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"]

    new Proxy(function(){}, {
      get(_, prop) {
        if (prop === Symbol.toPrimitive)
          return () => ...
As opposed to, you know, just defining a method. Proxy has apparently become the new adding custom methods to built-in prototypes.
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'
In another comment, I mentioned a vanilla JavaScript function I published in 2024 called Chute. https://github.com/gregabbott/chute

In a similar way to the featured project, Chute also uses proxies to work like a pipeline operator. But like in your reply, Chute uses a dot-notation style to chain and send data through a mix of functions and methods.

You might like to see how Chute uses proxies, as it requires no `chainWith` or similar setup step before use. Without setup, Chute can send data through global or local, top-level or nested, native or custom, unary, curried or non-unary functions and methods. It gives non-unary functions the current data at a specific argument position by using a custom-nameable placeholder variable.

The Chute page describes some more of its features: https://gregabbott.pages.dev/chute/