The JavaScript Pipeline Operator

> I even think we could be better without classes

Absolutely. Classes are also a big part of why there's still a lot of bikeshedding for some new features (class properties, decorators, private fields, etc).

Classes are familiar to most developers these days, but they're an absurdly complicated construct. The current implementation in javascript is "maximally minimal", in that the TC39 pushed the minimum they could that was still kind of sortoff useful to get the wheel rolling...but it's still not good enough. They'll need several more updates before they're truly useful. And even when that's all there, they still won't offer much that wasn't already doable, arguably better if less familiar.

At the end of the day, ES6 classes were designed back in the days where OOP was getting big in JavaScript. It took so long to release that by the time they were, the field had changed a lot.

You could just use ramda https://ramdajs.com/docs/#pipe

Not quite as seamless and it would be nice to have |> but ultimatles introduces a lot of complexity.

The only good reason I could see is if there is a performance benefit a JavaScript JIT could take advantage of by having the |> operator?

Thanks! Sounds a bit too scientific to my ear but good to know

A pipe operator compiles directly into the AST and completely disappears before execution.

    64 |> Math.sqrt |> Math.sin
    Compiles in the AST to
    Math.sin(Math.sqrt(64))

    //curries variables away from functions
    var realPipe = (a, ...args) => (...initParams) => {
      var acc = a(...initParams);
      for (var i = 0; i  
      (typeof a === "function")
        ? realPipe(a, ...args)
        : realPipe(...args)(a)

I'd note that this pipe implementation also bleeds its abstraction. JS has first-class functions, but this will never treat a function as data. You must be aware of how it works so if you are passing a function (for example, a getter function), you must manually curry it afterward.

This complication is why most pipe implementations don't actually mess with that data attribute part (they just skip to the realPipe implementation), but since the pipe operator can handle it, I figured I'd try to as well to show the issues.

With the way syntax for function calls works, the innermost thing is executed first, and you end up reading stuff from right to left:

   third(z, second(y, first(x)))

With the pipeline operator (and assuming a language that allows partial application), the order in which things execute matches the order in which you read it:

  first x |> second y |> third z

The benefits start getting more noticeable when you're talking about stuff like manipulating sets of data. For example:

  myList
  |> filter (x -> x.color == 'red')
  |> sortBy (x -> x.count)
  |> first

compared to these sorts of pyramids of doom:

  first(
    sortBy(
      x -> x.count,
      filter(
        x -> x.color == 'red',
        myList
      )
    )
  )