Performance concern with let/const
We've begun deeper investigations of implementation practicalities related to let/const, and two significant performance concerns have been raised. I think these both merit re-opening discussion of two aspects of the let/const design. Temporal dead zones For reference on previous discussion of temporal dead zone see [1]. I've expressed concerns with the performance overhead required for temporal d
A plan to help TC39 become more open up to community contributions and participations
TopicsNotesAboutA plan to help TC39 become more open up to community contributions and participations A plan to help TC39 become more open up to community contributions and participations (This is a continuation of a previous discussion) So, to summarize, while rules and platforms currently in place do allow for community contributions, they are hardly friendly ones. A few issues: The mailing list
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Symbol history
weakref proposal update
Clarification regarding "top level" arrow functions and "this"/"arguments"
Officially support a shebang line
Expected function parameter scoping behavioor
Strict Relational Operators
ES RegExp parser
Do settled promise chain handlers fire in the same turn?
Why can't we `let s = super`?
Is Narcissus dead?
Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)
Hash style comments
RegExp.escape()
Why ES6 introduced classes yet `Symbol` not to be used with `new`?
Suggestion: Object.symbols
Conditional catch clause
Tracking proposals should be standardized with issues
Error stack strawman