Babel 7.5 | Hacker News Reader

Babel 7.5

babeljs.io

81 pointsducaale35 comments

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?

I guess it's because of potential ambiguity, it's discussed here: https://github.com/tc39/proposal-pipeline-operator/issues/14...

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.

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

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.

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

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.

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

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

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.

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

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

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.

Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).

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.

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.

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

But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening.

That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example:

    Promise.resolve(document.querySelectorAll('.requestedIds'))
      .then(p => Array.from(p))
      .then(p => p.map(el => fetch(`//address/${el.value}`)))
      .then(p => Promise.all(p))
      .then(p => p.map(re => re.json())
      .then(p => Object.fromEntries(p))
      .then(p => processResponse(p))

But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.

Hopefully there will be no issue adding a breakpoint to see the structure of obj, a common debugging necessity

Chrome dev tools let you put breakpoints inside promises, and debug promises in general. I guess they'll update the tools to let you set breakpoints inside pipes (at least I'm hoping so :) )

How does it read in your internal monologue? "await pound" doesn't convey a whole lot of semantic meaning to me.

I'm curious how others read it.

Perl programmers read "$_" as "it".

So you could read the expression above as "fetch url, then await it, then get its json then await it, then get its ID"

Although I don't know why a syntax needs to be verbally legible, seems like an odd requirement to me.

There's a reason why Pearl is considered a write-only language.

Programming languages typically opt for either verbal legibility or having their symbols represent some understood structural / visual cue (like an arrow, for example). There's nothing about the character "#" that indicates the directionality of the operation visually, so I assumed there was some verbal mapping that I wasn't familiar with. ("Hash", "pound", "number", etc).

Typically programming languages are used to communicate procedures in ways that would allow human people with a similar set of cultural references to understand what is going on by reading it. Having verbal legibility allows people who know the language to explain very quickly to new people what is meant by a given symbol. Otherwise why #? It could be any symbol.

Communicating meaning for humans might not be the intent for javascript moving forward, given where WASM and transpilation is headed, so :shrug:

The pipe operator has was introduced to R a few years ago. It is one of those things I miss the most in js.

Debugging is an issue though. I commonly find myself splitting up the pipes into section in order to inspect the results and find exceptions. Breakpoints and stepping through code is probably the features I most often struggle with.

You should pity people debugging very different constructs than this.

This is clear as day, and I haven't even read the proposal...

I never said understanding, I said debugging. There are 4 implicit objects here (discounting proxies and wrappers), so unless you know them by heart, you have now idea what's in there. Then of course most debuggers will consider that one line, so to debug, you will hall have to split it in several ones to have the right to know what's going on. Plus, now that you have done it, what ? You put them back as they were ?

That's also hoping your code map files and your browser work well together, which is often not the case. Transpiled code is always a pain to debug at one point or another.

And that's just one line, a code back "full of those" will let you do the dance again and again. A very slow dance at that, cause babel is not the fastest horse in town.

Finally I'll pray your intern doesn't have to do it. But we all have teams full of good programmers right ?

But that's wishful thinking, you could be wrong about what that code does.

Not really. There's no magic in the code, it's a pretty well established construct, used in other languages for decades...

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?

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.

Is there any chance, there will be codemods?

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.

it's part of the stage 1 preset, and in the future it will either disappear from the stage 1 preset or move to the stage 2 preset.

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.

Decorators are in stage 2. Have I missed something?

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

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

Reply on news.ycombinator.com