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

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.

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.

Yeah! As a hobbyI much around with scheme (mostly), Smalltalk (a couple of times a year) and factor (maintaining some old tools I wrote in it).

The result is that if I whine, I whine about the choice of language, not about how a particular part of a language sucks. Extensibility like that should be built in, and then probably mostly discouraged. If you really need to scratch an itch, you will be able to do so without resorting to what usually ends up as ugly, non-composable hacks.

It's worth saying that mostly the same companies are building WebAssembly as a solution to this problem.

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.

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.

You can go talk to TC39 delegates in #tc39 on freenode right now (it will be kind of quiet for the next few days though since there is an in-person plenary and people are not looking at IRC as much). We also use https://es.discourse.group/ for async communication.

Also, many entities listed on Ecma's membership page are not there for TC39, and talking to people working for them will not get you anywhere.

According to the article, and companion Babel blog ( 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.

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.

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.

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 [2] https://github.com/tc39/notes/blob/master/meetings/2018-03/m...

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.

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

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.

Getting something through the TC39 is a pretty lengthy process, you can read about it here https://tc39.es/process-document/.

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