Hacker Newsnew | past | comments | ask | show | jobs | submit | aadams's commentslogin

Please have someone on your team take a good hard look at the current proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator

It started as a Function Composition proposal (using the pipe operator |>) but after a change of leadership it has turned into something much different. We might need another perspective on the current trajectory of this proposal, as in its current form it seems to many in the community it might take JS in the wrong direction.

Thanks!


If you want a feedback, I do not find |> versions much (if at all) easier to read. The noise is as high as in a regular function-based chaining:

  await chain(
    Object.keys(envars)
      .map(envar => `${envar}=${envars[envar]}`)
      .join(' '),
    text => `$ ${text}`,
    text => chalk.dim(text, 'node', args.join(' ')),
    colored => console.log(colored),
  )
I don’t want to sound too negative, but this seems like a pointless extension only to bring the burden of support for some syntactic flavor.

React example is special though. It feels like very helpful in expr-only context, but in-array ifs and fors would do better there:

  <ul>
    {[
      for (v of vs) {
        const text = foo(v)
        yield <li>{text}</li>
      },
      if (vs.length == 0) {
        yield <li>No items</li>
      },
    ]}


How does this square with OWC's dock: https://appleinsider.com/articles/21/01/07/owc-debuts-refres...

From the article:

" It connects to a computer via a single Thunderbolt port, and can drive up to two dual 4K displays or a single 5K, 6K, or 8K display. " "


Will you provide links?


They’re asking for this to make it harder for the competition. Simple. Happens in many industries too.


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: