Skip to content

Instantly share code, notes, and snippets.

View littledan's full-sized avatar

Daniel Ehrenberg littledan

View GitHub Profile

In this proposed alternative to sloppy-mode function hoisting semantics, sloppy-mode FunctionDeclaration are always single var-style bindings. The var is set to the value of the function at the top of the block where the FunctionDeclaration occurs. I believe these semantics roughly match IE10 and earlier sloppy mode function hoisting semantics.


  • Maintain compatibility at the intersection of what browsers have supported for a long time
  • Support is self-defining functions defined in blocks (tc39/ecma262#162)
  • If possible, be intelligible for users and implementors (simple semantics win out when they make sense)
  • Preserve strict-mode lexical scoping of FunctionDeclarations (this proposal only affects sloppy mode)


  • Make a lexical binding in sloppy mode, and generally try to make sloppy mode block-scoped FunctionDeclarations act like lexical bindings, including suppressing errors, when possible

Reconsidering @@species

ES2015 added the @@species feature, where subclassing of builtins is enhanced by creating instances not of this.constructor but of this.constructor[Symbol.species]. There are a few issues with @@species:

  • @@species is called in some places but not others in a way that feels a bit inconsistent (from instance methods but not static methods). See bugs 1 2 (Kevin Smith)
  • @@species feels a bit unnecessary. It was motivated initially by ensuring Zepto's strange use of proto would continue to work. There's already an extension point by overwriting the constructor field, a simpler fix would have been possible, and Zepto was updated a year ago to not use these patterns.
  • @@species will be a lot of work to implement across standard libraries of all JS engines without a performance regression.

This document explo


Zepto compatibility concerns

@@species came up on TC39's agenda in an attempt to preserve compatibility with Zepto. A patch was merged on October 21, 2014 to remove the problematic use of __proto__, but the old code can be found here. Here's the relevant snippet:

  zepto.Z = function(dom, selector) {
    dom = dom || []
    dom.__proto__ = $.fn
    dom.selector = selector || ''
    return dom
View silly-promise-bench.js
var resolve;
var promise = new Promise(r => resolve = r);
async function foo(i) {
if (i > 100000) return promise;
return foo(i+1);
littledan /
Last active September 27, 2017 06:25
Proposed TC39 pull request process document

TC39 accepts changes through two processes--the four-stage proposal process and pull requests. Staged proposals are governed by the process document, whereas pull requests are lighter-weight, working through informal rules and conventions, as administered by the editor. This document attempts to codify a process for pull requests, mostly through writing down current practice (to help others follow along what's happening, and to help the next editor if there is a transition), but a change from current practice is included in bold.

Algorithm for getting a PR merged:

  1. If the PR is purely editorial or to support layering, tag it as 'editorial' or 'layering'.
  2. Otherwise, tag it as 'normative', as it makes an observable semantic change.
  3. If the PR is about reflecting what some web browsers' behavior is, tag it as 'web reality'.
  4. Get consensus on the PR. If this is difficult or time-consuming, mark 'needs consensus' as it is gaining consensus.
  5. If the PR is tagge
littledan / header.jsidl
Created December 4, 2017 18:12
Should JavaScript use a header file format (a la WebIDL) to define its standard library?
View header.jsidl
class Math {
static abs(x: Number): Number; // Types optional; provide cast on input and assertion on ouptut
static LOG10E: Number;
// ...
View operator-overloading.js
class Vec {
constructor(x, y, z) {
this.#x = x;
this.#y = y;
this.#z = z;
littledan / gist:cdee21a5782b9169e0844f6c94e30204
Created April 10, 2018 17:02
WebAssembly spec compatibility issues
View gist:cdee21a5782b9169e0844f6c94e30204
A summary of the issues for WebAssembly that Dan has been thinking about:
- CSP --
- When the checks happen
- What the checks are
- Resource limits --
- Should we align resource limits?
- How should the limit on local variables be interpreted?
- What are the magic numbers? (These have already had to rise due to lack of implementation)
- Memory objects limit -- do we have consensus that there should be no limit?
npm install -g test262-harness
npm install -g babel-cli
npm install -g jsvu
git clone
test262-harness --test262Dir test262 --babelPresets stage-3 --hostType d8 --hostPath ~/.jsvu/v8 test262/test/intl402/*
View lexical-friends.js
// In the following code, take `private` and `friend` to be extremely early strawperson names
private #x; // Declare a private name
let obj = { outer #x: 1 };
class MyClass {
outer #x;
constructor(x) { this.#x = x }