
Babel 7.5 - ducaale
https://babeljs.io/blog/2019/07/03/7.5.0
======
ianwalter
I’m excited for pipelines but I think the simple pipeline feels much more
natural than the “smart” one and allows for destructuring props. Also, am I
the only one that feels like the way await is handled in pipelines is
backwards? Why not just add await before the function call like a normal
function call?

~~~
kristiandupont
I guess it's because of potential ambiguity, it's discussed here:
[https://github.com/tc39/proposal-pipeline-
operator/issues/14...](https://github.com/tc39/proposal-pipeline-
operator/issues/145)

~~~
ianwalter
Thanks for linking. It doesn’t look like that discussion includes the “F#”
arrow function style discussed in the babel release. I believe using this
style would get rid of the ambiguity they were discussing since it could be
handled in the same way as a async function outside of pipelines. I really
like the consistency of that approach.

------
bhurlow
I'm excited to use the pipeline operator but I was burned when I adopted a
library
([https://github.com/danprince/zaphod](https://github.com/danprince/zaphod))
which used the function bind operator only to find that lost major steam in
TC39 process

~~~
uhryks
It really is a bummer... Pipelines look cool and straightforward but the bind
operator is much more flexible and seems more adapted to the language's
semantics.

~~~
spion
With partial application the situation is mitigated somewhat but bind offers
other benefits by being a decent primitive to help explain how JS `this`
works.

I wonder if there is a way to revive the proposal...

------
netdur
For your own sanity, for your future own self and whomever poor soul that
maintain your code, do not use smart syntaxes, there's nothing smart about it,
those are just unreadable shortcuts, please use longer and simpler to read
syntaxes.

~~~
sametmax
I pity the guy who has to debug a code base full of:

    
    
        let newScore = fetch(url)
          |> await #
          |> #.json()
          |> await #
          |> #.ID;

~~~
frabert
I don't know, it seems pretty clear to me. It beats doing

    
    
      let newScore = (await (await fetch(url)).json()).ID
    

and no, a myriad of intermediate variables is not always a nice alternative.
This syntax gives a clear view of what happens to the data without having to
untangle deeps expressions. I like it.

~~~
dmitriid
The page shows a much more clear and readable alternative, F# pipelines:

    
    
      let newScore = fetch(url)
        |> await
        |> r => r.json()
        |> await
        |> obj => obj.ID;

~~~
Klathmon
Wouldn't this be a lot easier to understand and work with?

    
    
        let newScore = await fetch(url)
          .then(r => r.json())
          .then(obj => obj.ID)
    

I think another problem is that these are just examples that aren't
necessarily representative of real-life use cases but more just try to show
all the different ways of using the syntax in one small chunk.

~~~
ulucs
That example is wrapped perfectly, so it seems a bit unneeded. A more complex
example would be

    
    
        // helper for method calls in pipes
        const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}})
    
        document
          .querySelectorAll('.requestedIds')
          |> Array.from
          |> _.map(el => fetch(`//address/${el.value}`))
          |> Promise.all
          |> await
          |> _.map(re => re.json())
          |> Object.fromEntries
          |> processResponse
    

In this case, there is both methods and function calls, which complicates
reading quite a bit. Converted to pipes, it's simply from top to bottom.

~~~
spion
I'd like to see the type signature of that `_` construct.

It seems to me like the bind operator would've made the extra complexity
unnecessary.

~~~
ulucs
_.map is basically syntatic sugar for p => p.map, only written with today's
javascript capabilities. I just tried to implement the proposed #. Dynamic
access to methods doesn't yield very nice type signatures.

------
cupofjoakim
The F# pipelines look interesting, but how should one think about this? It's a
Stage 1 proposal, meaning it could actually not only be changed, but also be
dropped from the TC39 consideration. Will future babel versions under the 7
tree keep supporting it?

~~~
Klathmon
I would really avoid using this in anything that you aren't okay with
rewriting right now.

The pipeline proposal has multiple syntaxes right now that the community is
trying to pick from and discuss.

The chances that the F#-style syntax will be chosen AND will make it to the
language proper unchanged is VERY low in my opinion.

And if the community goes in a different direction, it's unlikely that the F#
style will be maintained for all that long because it's still such an early
stage proposal.

~~~
finchisko
Is there any chance, there will be codemods?

~~~
Klathmon
They could probably be made, but I still wouldn't rely on it.

Well working Codemods are difficult to make in many cases, and unless someone
is paying for it, I don't think there will be many calls for one to translate
between the syntaxes unless the proposal gains a lot of usage without settling
on one.

------
Lowkeyloki
I have a strong feeling that these pipeline operators are headed for the
purgatory that decorators are languishing in, at least as far as official ECMA
spec approval goes. But I hope to be proven wrong.

~~~
pier25
Decorators are in stage 2. Have I missed something?

~~~
tracker1
Decorators have been in stage 2 for a very, very, very long time at this
point.

------
microcolonel
Cool, a bit more powerful, like ->> and -> in Clojure.

