5 ms·

I know this proposal has been sitting around forever, but it really can't come fast enough imho. I don't know how to help show my support for its inclusion, how

I know this proposal has been sitting around forever, but it really can't come fast enough imho. I don't know how to help show my support for its inclusion, however. Can anyone help elucidate?

mirthflat83 7y ago
It’s been so long I forgot that this proposal even existed
galacticdessert 7y ago
According to the article, and companion Babel blog ( https://babeljs.io/blog/2019/07/03/7.5.0 https://babeljs.io/blog/2019/07/03/7.5.0 ), this is usable already in combination with Babel. Now, I understand how it might be desirable to NOT having to use Babel to run code, especially on Node. On the other hand, some amount of transpilation has become inevitable for js in the browser and I don't see this need going away soon, as JS evolves much quicker than browser adoption.
- IggleSniggle 7y ago
  Yes, I know...but I live in TypeScript world where functional styles and types go together especially wonderfully. Babel solutions to TypeScript are messy and in some cases break the things I like about TypeScript. At least last I checked. But getting native TypeScript support is dependent on the feature actually making it into the official spec.
  - jkoudys 7y ago
    Been through that here, trying to get my whole dev env working nicely with both pipes and types. Very painful. I was surprised and a bit disappointed that pipelines seemed to be progressing years ago, then suddenly stalled. Nullish and optional chains are in ts already but pipelines aren't even on the horizon. From what I hear from tc39 people, method extraction is one of the biggest must-haves holding this thing up. They want a nice way to bind contexts to an entry in the pipe. Ironically the difficulty of figuring this out for JS is keeping pipes out of TS, but it wouldn't be that hard a problem in TS which has ways to treat `this` as special already. That, and the many competing proposals we already have. I'm fine doing an incremental rollout that doesn't need the placeholder `?` right now.
hopia 7y ago
I always wondered why does it take such a long time to formalize this in Babel's specs. It seems something fairly unequivocally useful, but I guess its implementation has some major hurdles in JS.
- andersns 7y ago
  Babel doesn't have a spec per se. They try to be compliant with the ECMAScript spec, but implement popular proposals behind presets or plugins. You can read about their relationship to ECMAScript and the TC39 committee on their blog: https://babeljs.io/blog/2018/08/27/7.0.0#babels-role https://babeljs.io/blog/2018/08/27/7.0.0#babels-role. Getting something through the TC39 is a pretty lengthy process, you can read about it here https://tc39.es/process-document/ https://tc39.es/process-document/.
IggleSniggle 7y ago
I decided to answer my own question and visit the tc39 website. The lazy answer is that you must be part of a company that is willing to pay ~$70000 to have a voice, and have access to your companies representative to tc39. There are other categories of members (like Mozilla), but here's the short list of "Ordinary members." More info at https://www.ecma-international.org/memento/members.htm https://www.ecma-international.org/memento/members.htm If you are part of one of these companies and interested in this proposal, it'd be super cool to see who you need to talk to to influence this decision. Facebook Google Hitachi IBM Intel Konica Minolta Microsoft PayPal Stripe, Inc.
- gambler 7y ago
  It's worth reflecting on why the most popular language in the world has syntax so inflexible that a simple operator like this requires begging some ubercorp for a compiler change. Smalltalk had user-definable binary/infix operators in 1980. They didn't require you to muck around with the compiler at all. Ironically, JavaScript has the extensibility mechanisms and object-oriented features inspired by Smalltalk that could allow for pretty much the same thing. However, most of the community doesn't seem to even realize that this is a possibility.
  - TomMarius 7y ago
    It's worth saying that mostly the same companies are building WebAssembly as a solution to this problem.
    - jkoudys 7y ago
      It's wasm. It could be written in Hindi numerals and unicorn emojis for all I care. So long as llvm can make sense of it.
    - xkriva11 7y ago
      Really? If you would try to do an effective Smalltalk implementation in WebAssembly, you would immediately see that WebAssembly is making things even much worse.
wwwigham 7y ago
If I recall correctly, it's because the proposal[1] was last presented to committee in March 2018[2], and since then it's been essentially deadlocked as the committee members can't agree upon an "f#" style operator vs a "hack" style operator vs a "smart mix" of the two. Personally, I hate placeholder sigils and magic "context" variables (and hope they have no place in JS), so a simple "left operand becomes first argument in call to right operand" is all I'd really want. [1] https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator [2] https://github.com/tc39/notes/blob/master/meetings/2018-03/mar-22.md#10ive-pipeline-operator https://github.com/tc39/notes/blob/master/meetings/2018-03/m...
- jkoudys 7y ago
  Same - the context variables are really for method extractions (e.g. the many times people used to call Array.prototype.slice on something). It's be easy in TS since `this` is already treated as special in function-arg contexts.
jkoudys 7y ago
I loved it, but came to an impasse when I had to decide between pipeline and TS. For a while I was running both a babel and TSC watch, where my babel build dir fed into the TSC watch. Dealing with two daemons when one/both screwed up, and needing to read errors in transpiled code, was annoying. What decided it was being unable to run prettier, since I could either use the babel parser for pipelines, or the tsc parser for the types. I'd be very happy if we could put pipelines back in and not break our tools and tax the two cores on my MacBook Air to the limit.

I know this proposal has been sitting around forever, but it really can't come fast enough imho. I don't know how to help show my support for its inclusion, however. Can anyone help elucidate?

mirthflat83 7y ago

It’s been so long I forgot that this proposal even existed

galacticdessert 7y ago

According to the article, and companion Babel blog ( https://babeljs.io/blog/2019/07/03/7.5.0 https://babeljs.io/blog/2019/07/03/7.5.0 ), this is usable already in combination with Babel. Now, I understand how it might be desirable to NOT having to use Babel to run code, especially on Node. On the other hand, some amount of transpilation has become inevitable for js in the browser and I don't see this need going away soon, as JS evolves much quicker than browser adoption.

IggleSniggle 7y ago
Yes, I know...but I live in TypeScript world where functional styles and types go together especially wonderfully. Babel solutions to TypeScript are messy and in some cases break the things I like about TypeScript. At least last I checked. But getting native TypeScript support is dependent on the feature actually making it into the official spec.
- jkoudys 7y ago
  Been through that here, trying to get my whole dev env working nicely with both pipes and types. Very painful. I was surprised and a bit disappointed that pipelines seemed to be progressing years ago, then suddenly stalled. Nullish and optional chains are in ts already but pipelines aren't even on the horizon. From what I hear from tc39 people, method extraction is one of the biggest must-haves holding this thing up. They want a nice way to bind contexts to an entry in the pipe. Ironically the difficulty of figuring this out for JS is keeping pipes out of TS, but it wouldn't be that hard a problem in TS which has ways to treat `this` as special already. That, and the many competing proposals we already have. I'm fine doing an incremental rollout that doesn't need the placeholder `?` right now.

hopia 7y ago

I always wondered why does it take such a long time to formalize this in Babel's specs. It seems something fairly unequivocally useful, but I guess its implementation has some major hurdles in JS.

andersns 7y ago
Babel doesn't have a spec per se. They try to be compliant with the ECMAScript spec, but implement popular proposals behind presets or plugins. You can read about their relationship to ECMAScript and the TC39 committee on their blog: https://babeljs.io/blog/2018/08/27/7.0.0#babels-role https://babeljs.io/blog/2018/08/27/7.0.0#babels-role. Getting something through the TC39 is a pretty lengthy process, you can read about it here https://tc39.es/process-document/ https://tc39.es/process-document/.

IggleSniggle 7y ago

I decided to answer my own question and visit the tc39 website. The lazy answer is that you must be part of a company that is willing to pay ~$70000 to have a voice, and have access to your companies representative to tc39. There are other categories of members (like Mozilla), but here's the short list of "Ordinary members." More info at https://www.ecma-international.org/memento/members.htm https://www.ecma-international.org/memento/members.htm If you are part of one of these companies and interested in this proposal, it'd be super cool to see who you need to talk to to influence this decision. Facebook Google Hitachi IBM Intel Konica Minolta Microsoft PayPal Stripe, Inc.

gambler 7y ago
It's worth reflecting on why the most popular language in the world has syntax so inflexible that a simple operator like this requires begging some ubercorp for a compiler change. Smalltalk had user-definable binary/infix operators in 1980. They didn't require you to muck around with the compiler at all. Ironically, JavaScript has the extensibility mechanisms and object-oriented features inspired by Smalltalk that could allow for pretty much the same thing. However, most of the community doesn't seem to even realize that this is a possibility.
- TomMarius 7y ago
  It's worth saying that mostly the same companies are building WebAssembly as a solution to this problem.
  - jkoudys 7y ago
    It's wasm. It could be written in Hindi numerals and unicorn emojis for all I care. So long as llvm can make sense of it.
  - xkriva11 7y ago
    Really? If you would try to do an effective Smalltalk implementation in WebAssembly, you would immediately see that WebAssembly is making things even much worse.

wwwigham 7y ago

If I recall correctly, it's because the proposal[1] was last presented to committee in March 2018[2], and since then it's been essentially deadlocked as the committee members can't agree upon an "f#" style operator vs a "hack" style operator vs a "smart mix" of the two. Personally, I hate placeholder sigils and magic "context" variables (and hope they have no place in JS), so a simple "left operand becomes first argument in call to right operand" is all I'd really want. [1] https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator [2] https://github.com/tc39/notes/blob/master/meetings/2018-03/mar-22.md#10ive-pipeline-operator https://github.com/tc39/notes/blob/master/meetings/2018-03/m...

jkoudys 7y ago
Same - the context variables are really for method extractions (e.g. the many times people used to call Array.prototype.slice on something). It's be easy in TS since `this` is already treated as special in function-arg contexts.

jkoudys 7y ago

I loved it, but came to an impasse when I had to decide between pipeline and TS. For a while I was running both a babel and TSC watch, where my babel build dir fed into the TSC watch. Dealing with two daemons when one/both screwed up, and needing to read errors in transpiled code, was annoying. What decided it was being unable to run prettier, since I could either use the babel parser for pipelines, or the tsc parser for the types. I'd be very happy if we could put pipelines back in and not break our tools and tax the two cores on my MacBook Air to the limit.