While I agree both proposals share a common goalāwriting chainable codeāI think they don't necessarily address it at the same level.
The pipeline operator is mostly useful to the end-developer who needs to chain functions from multiple libraries. I find it very versatile but difficult to read.
The extension functions are great for library maintainers to export functions that can extend existing objects. They are very similar to classic functions and are easy to read/understand.
Also, the pipeline proposal seems a bit stuck ATM, but I'm not sure this is a good argument.
I'm a bit sad to admit it, but yes, a new syntax might be required.
To TC39 delegates: If I alter the proposal to include a new syntax, could it get a chance to be championed and proposed to a future TC39 meeting?
I myself donāt have the bandwidth to champion this proposal. But I can give a prediction that, for better or worse, all syntax proposals (except perhaps already-close proposals such as those related to import attributes) are unlikely to reach Stage 3 or 4 within the next few years.
As you may know, new syntaxes are generally much more complicated and costly to specify, implement, and perpetually maintain by the engines.
As a co-champion of the pipe operator and the bind-this operator proposals, I can say from experience that syntax proposals generally face a very high barrier to entry. Itās been more difficult than ever for even simple syntaxes to be added to the language. You may find the update I wrote for the pipe operator last spring relevant to this issue.
In fact, new syntaxes that do not add any behaviors that had been previously unimplementable by developersāthat is, new convenience syntaxesāironically may face increased scrutiny. This is because some members of the Committee perceive such convenience syntaxes as less beneficial for a still-high cost, compared to syntaxes that do bring new behaviors.
Even if this situation is unfortunate, I think itās also understandable how conservative the Committeeās consensus, particularly from the engines, is toward adding new syntax.
That is also probably one of the reasons why @hax has left his extensions proposal alone for the past few years. Thereās been other proposals for him to focus on, ones that are more likely to be accepted by the engines.
I apologize for being pessimistic. I think your proposal is interestingābut I also think itās good to be realistic about the prospects of any new syntax proposals in the near future. Thatās why Iāve been lately focusing more on new function-only APIs myself. I wish you luck with finding a champion.
Thank you very much @jschoi for taking the time to explain the situation. In fact, I did already read your update for the pipe operator andānaivelyāthought that my proposal isn't bringing any new syntax because it doesn't need any new operatorā¦ But I was wrong, it still requires to update how we parse the language.
To all other TC39 delegates, I'm still open to work on this proposal despite the pessimistic predictions.
Do you think this situation could be helped if the rationale for a proposal were more anchored to the end-user benefits? From what I can tell, most of the motivation for the pipeline and call-this proposals is framed as āmake clunky code more readableā but itās not immediately obvious why that benefits end-users.
Here is my basic line of thinking:
Dead code is a big problem slowing down the web (Gemini claims 30-70% of JS on the web is dead code).
prototype-based functions are particularly hard to tree-shake, resulting in more dead code.
prototype-based functions are also very popular because of how convenient they are for devs to define (class syntax) and invoke (method call, method-chaining, etc).
To get people to write more tree-shakable code, we need to offer a tree-shakable option that is as convenient as method-chaining. Then, developers will be willing to use that instead.
More tree-shaking == faster, lighter web == happier end users.
Iām sure there are holes and many details or other rationale I could fill out, but the main point is that ādeveloper convenienceā in this context is really just a means to the end of a faster user-experience for everyone.