Safari was against an explicit tail call syntax [0], and as part of that were against "TCO" as an optional optimization, however they are the first to implement PTC.
[0] https://github.com/tc39/ecma262/issues/535
In Cancelable Promises: Why was this proposal withdrawn?tc39
ecma262
HTML2015–2026
tc39 / ecma262
ecma262
Status, process, and documents for ECMA-262
44Distinct people
46Mentions
1Explicit recommenders
15.7KGitHub stars
What to know before exploring
What it is
Status, process, and documents for ECMA-262
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
It would be interesting if browsers supported more languages but I don't mind the monoculture. I have spent a lot of time investing in languages, frameworks and tools, so much…
benoau used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- tc39/proposal-ptc-syntax · linked in 4 of the same discussions
- tc39/proposal-object-rest-spread · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year46 dated mentions
Observed mentions: 2015-05-22 08:40:24 UTC to 2026-10-29 16:46:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 3 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 3 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
ECMAScript
This repo
This repository contains the source for the current draft of ECMA-262,
the ECMAScript® Language Specification.
This source is processed to obtain a human-readable version,
which you can view here.
If you want to explore how the specification was written, you can also view the source with its history in searchfox.
Current Proposals
Proposals follow the TC39 process and are tracked in the proposals repository.
Finished Proposals
Active Proposals
Stage 1 Proposals
Stage 0 Proposals
Inactive Proposals
Contributing New Proposals
Please see Contributing to ECMAScript for the most up-to-date information on contributing proposals to this standard.
Developing the Specification
After cloning, do npm install to set up your environment. You can then do npm run build to build the spec or npm run watch to set up a continuous build. The results will appear in the out directory, which you can use npm run clean to delete.
Community
ES discourse: Forum for ECMAScript discussion and questions
Matrix: Chat
Read the full README on GitHubWhat Hacker News says
9 sourcesDocument.all willful violation
2 points · Open discussioncompatibility, same as the first one
https://bugs.chromium.org/p/v8/issues/detail?id=4942#c4
> Per https://www.chromestatus.com/metrics/feature/timeline/popula..., this syntax is still seen on the web, and any such pages would be broken by this change.
https://github.com/tc39/ecma262/issues/260
In Safari Tech Preview 8 achieves 100% ES6 supportSorry for the inaccurate shorthand; maybe that should read that SpiderMonkey supports it. Eric Faust of SpiderMonkey is a co-champion of the proposal, and spoke against implicit PTC at the March 2016 TC39 meeting. It's hard to get much stronger in support of a proposal than being a champion, and Eric works for Mozilla. From that discussion, it also sounded like there was support from the Mozilla devtools team as well.
I'm interested in getting everyone's point of view. We've been discussing pros and cons at https://github.com/tc39/proposal-ptc-syntax/issues and https://github.com/tc39/ecma262/issues/535 , and it'd be great to have your input, including the overturning-prior-consensus issues you raised in committee and anything else that comes to mind.
EDIT: How do you like the new wording "For these reasons, the V8 team strongly support d
Read the rest
enoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft." ?
The author posits that "Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc."
There's a very good reason that Babel doesn't, and we should actually be fairly grateful that the Babel team have made the considered decision not to include such things.
First off, neither async/await nor decorators are actually part of ES2015. They're both TC39 proposals, at various stages of completion: https://github.com/tc39/ecma262. Very justifiably, neither Babel 5 nor Babel 6 transpiled those out-of-the-box by default; for novice programmers, using language features that are unstable proposals that have not finalized is quite dangerous – what are you going to do if those proposals change, as the decorators proposal actually has changed?
More specifically, there are meaningful issues with both
Read the rest
of those transforms if used without further thought. Babel's stock transpilation of async/await brings in an entire runtime component in the form of the Regenerator runtime, and additionally requires that Promises exist in the JavaScript environment, which requires polyfills in the general case.
For decorators, the proposal itself is still in flux. The current version of the proposal (https://github.com/wycats/javascript-decorators/blob/master/...) is actually quite different from the old proposal, which was the one that was implemented in Babel 5. Additionally, the current proposal isn't even fully nailed down yet. Certainly one should not expect Babel to implement a language feature for which there isn't even yet a stable proposal!
This isn't to say that Babel 6 is perfect, but the specific counterexamples the author of this post brings up are extremely weak, and if anything demonstrate very good choices on the part of the maintainers of Babel.
/\p{Lt}/.test(str) would be much more compact, but Unicode properties still aren't available in Javascript regular expressions. It doesn't look like they will be anytime soon. I guess they have some staging system and it's still at stage 0 (https://github.com/tc39/ecma262/blob/master/stage0.md), grouped with lookbehind assertions, named captures, and mode modifiers.
In NPM and Left-Pad: Have We Forgotten How to Program?Yeah this is a long way off and lots of things need to happen before node can even consider this…
1. TC39 needs to get async functions to stage 4:
https://github.com/tc39/ecma262/blob/master/README.md
2. V8 needs to implement: https://github.com/nodejs/promises/issues/4
3. Node then needs to use this updated V8, and to be able to use this reliably, this V8 will need to reach an LTS release: https://github.com/nodejs/LTS/blob/master/schedule.png
4. Also Node API needs to become promises-compatible, which is god-knows how long away: https://github.com/nodejs/promises
In Node 5.7.0 (stable) releasedasync/await isn't part of any standard yet. It's a stage 3 proposal at this time, which means it may not even land in ES 2016: https://github.com/tc39/ecma262
The last thing we want is native support for pre-standard features. As long as it's not in a spec (or draft at least), it's sci-fi.
Besides, node doesn't implement language features, V8 does. Here's the relevant issue: https://bugs.chromium.org/p/v8/issues/detail?id=4483
In Node 5.7.0 (stable) releasedI think this is the intent. A proposal is brought to TC39. It gets discussed. Someone champion's it (implements it in the wild). Adoption and usefulness are determined. New standards are accepted.
I think this is a much better practice than a bunch of dudes just deciding what browsers will support and how they support it without actually trying it on first.
It's pretty much all in the open. No need for conspiracy theories. The environment is significantly different than it was during the early IE days.
https://github.com/tc39/ecma262
In YouTube change served lower-quality video to Firefox 43 for 2 weeks