②ality – JavaScript and more

Plans for supporting Web Components in AngularJS and Ember.js

2013-05-23T14:10:00.001+02:00

Web Components [1] are an upcoming standard for custom HTML5 user interface elements. Those UI elements will eventually become interchangeable between frameworks. Now the people behind AngularJS and Ember.js have described their plans for supporting Web Components.

Below, you’ll see mentions of Google’s new framework, Polymer [1]. It is built directly on top of Web Components. One of Polymer’s goals is to help refine and fully figure out that standard.

AngularJS

In an entry on Google Groups, AngularJS co-creator Miško Hevery writes:

We're in early stages of designing Angular 2.0, but some of our goals are:

Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)

Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.

Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library).

We're working actively with the MDV, Web Components, and Polymer teams to make sure that our approaches remain compatible as all these projects evolve (and they will still evolve).

Ember.js

Yehuda Katz, one of Ember‘s creators, has written a Gist with the title “Ember and Web Components”:

The goal of this document is to describe how Ember could adopt semantics similar to web components and MDV. It relies on the HTMLBars templating engine, which allows Ember to directly control how templates are parsed and converted into DOM. [HTMLBars uses the same Handlebar syntax as current Ember, but compiles it to code that constructs DOM nodes instead of code that concatenates strings. That leads to the above mentioned increase in control.]
It builds on the work of Rafael Weinstein and the Polymer team, and attempts to harmonize that work with Ember's architecture.
Ember's scope is much wider than components, and is mostly focused on application architecture and URL-driven design. Today, we need a system to manage the lifecycle of data-binding and custom views, so we include such a system alongside our architectural tools.
Once the web provides its own tools for managing components, and eventually data bindings, Ember will embrace them and transition away from our Ember-specific solution. This document is how we get from here to there, continuing to build ambitious and stable applications in the meantime.
[...]

The document is a great primer on how Web Components differ from Ember.

Reference

Google’s Polymer and the future of web UI frameworks [describes both Web Components and Polymer]

JavaScript quirk 7: inadvertent sharing of variables via closures

2013-05-23T11:46:00.000+02:00

[This post is part of a series on JavaScript quirks.]

Closures are a powerful JavaScript feature: If a function leaves the place where it was created, it still has access to all variables that existed at that place. This blog post explains how closures work and why one has to be careful w.r.t. inadvertent sharing of variables.

Closures

Let’s start with an example of a closure:

    function incrementorFactory(start, step) {
        return function () {  // (*)
            start += step;
            return start;
        }
    }

This is how you use incrementorFactory:

    > var inc = incrementorFactory(20, 2);
    > inc()
    22
    > inc()
    24

During all of its lifetime, the inner function (*) has access to the variables start and step of the outer function incrementorFactory. Thus, incrementorFactory returns not only the function, but somehow attaches the variables start and step. The data structure in which both variables are stored is called an environment. An environment is very similar to an object – it maps names to values. The function that is returned above contains a reference to the environment that was active at its birth, its outer environment. The combination function + environment is called a closure. The name stems from the fact that an environment “closes over” a function: It provides values for variables that were declared outside the function (so-called free variables).

When a function f is invoked, a new environment is created for its parameters and local variables. There is always a chain of environments:

f’s environment
f’s outer environment
The outer environment of f’s outer environment
...
The environment for global variables (the global environment)

When looking up the value of a variable, the complete chain is searched, starting with f’s environment.

The quirk: inadvertent sharing

Closures don’t get snapshots of a certain point in time, they get “live” variables. The following is an example where that causes a problem.

    var result = [];
    for (var i=0; i < 5; i++) {
        result.push(function () { return i });  // (*)
    }
    console.log(result[3]()); // 5 (not 3)

When a function is created in line (*), the variable i has a certain value. You might expect that function to always return that value. Instead, the connection to the “live” i is never broken. That is, all functions in the array result share the same i, via their outer environment. And after the loop is finished, i has the value 5.

One possible fix is to copy the current value of i via an IIFE [1]:

    for (var i=0; i < 5; i++) {
        (function (i2) {  // snaphot of i
            result.push(function () { return i2 });
        }(i));
    }

You can also use bind(), with a similar effect:

    for (var i=0; i < 5; i++) {
        result.push(function (i2) { return i2 }.bind(null, i));
    }

Another possibility is using forEach and the range() function of the Underscore.js library:

    _.range(5).forEach(function (i) {
        result.push(function () { return i });
    });

The above works, because forEach creates a new variable i, each time it calls its argument.

A practical example

Let’s conclude with a more practical example. Two days ago, I implemented a user interface for the game Connect Four, as a demonstration of the DOM. It contained the following code snippet, which adds event listeners to links above the columns of the board.

    for(var col=0; col < board4.DIM_X; col++) {
        document.getElementById('columnClick'+col)
                .addEventListener('click', function (col) {
                    currentState.columnClick(col);
                    event.preventDefault();
                }.bind(null, col));
    }

An alternative is to use CSS classes instead of IDs and rewrite the above code:

    Array.prototype.forEach.call(
        document.getElementsByClassName('columnClick'),
        function (elem, col) {  // (*)
            elem.addEventListener('click', function () {
                currentState.columnClick(col);
                event.preventDefault();
            });
        });

Again, each invocation of the function (*) creates a new variable col and no inadvertent sharing occurs.

The last post in this series will explain how ECMAScript 6 helps with the problem of inadvertent sharing.

Reference

JavaScript quirk 6: the scope of variables

Google’s Polymer and the future of web UI frameworks

2013-05-18T14:17:00.000+02:00

Update 2013-05-23: Plans for supporting Web Components in AngularJS and Ember.js

At Google I/O 2013, Google presented a new web user interface (UI) framework called Polymer. The way it works is indicative of the future of all web UI frameworks.

Polymer

Polymer is composed of the following layers:

Foundation (platform.js): Foundational building blocks. Most, if not all, of these APIs will eventually become native browser APIs.
Core (polymer.js): Helpers complementing Foundation.
Elements: UI and non-UI components built on Core.

The Foundation layer (platform.js)

The Foundation layer comprises the following technologies:

DOM Mutation Oberservers and Object.observe() (probably ECMAScript 7): for observing changes to DOM elements and plain JavaScript objects.
Pointer Events: handle mouse and touch in the same manner, on all platforms.
Shadow DOM: encapsulate structure and style inside elements (e.g. custom ones).
Custom Elements: define your own HTML5 elements. The names of custom elements must contain a dash, which is a simple way of namespacing them and distinguishes them from standard elements.
HTML Imports: package custom elements. Such packages include HTML, CSS and JavaScript.
Model-Driven Views (MDV): Does data-binding directly in HTML. Not yet in the process of being standardized.
Web Animations: API unifying several of the web’s animation approaches.

APIs 3–5 are part of Web Components, a component model for the web. Web components are the most important foundation of Polymer.

platform.js shims these APIs on browsers where they are not (yet) available. It is only 31KB (if minified and gzipped). One of the declared goals of Polymer is to field-test HTML5 UI APIs before standardizing them.

Layers: Core and Elements

Polymer itself is almost like native HTML5: “attributes in, events out”. One example of using the UI widget polymer-panels:

    <polymer-panels
        on-select="panelSelectHandler"
        selected="{{selectedPanelIndex}}">
    </polymer-panels>

Its architecture is very component-oriented, its components being HTML elements. Some of the elements don’t even have a user interfaces themselves. For example, animations are elements (you can nest them etc.), they have no user interface, but instead point to UI elements that they animate. Responsive design is built into many widgets, which means that they will transform so that they work best on a given platform (cell phone, tablet, desktop, etc.).

Interoperability

Polymer is designed to be à la carte: you pick and choose what you need. Thanks to Web Components, its elements are also highly interoperable. In one demo given at I/O, an element coming from the Mozilla project X-Tag (that is similarly based on Web Components) was shown as working inside Polymer.

When can I use it?

Polymer is still pre-alpha and thus not yet really ready for public consumption. It is, however, developed in the open and you can already play with its code.

Polymer versus other frameworks

Polymer is not the framework to end all other frameworks. Instead, existing frameworks can be based on the same foundations. In fact, the functionality of most of the APIs that were mentioned above should look familiar to you if you have already used a UI framework such as Ember.js or AngularJS. As for AngularJS, a recent tweet explains how it will evolve:

AngularJS will use Polymer for its widgets. It's win-win.

What does it all mean?

Nobody actually wants to use frameworks. We only want to build web user interfaces efficiently and frameworks help. The most important pieces missing from native HTML are:

A rich set of widgets. In my opinion, this is the biggest deal about Web Components (and, to a lesser degree, about Polymer). We finally get a large set of widgets that we can use anywhere.
User interface layout. I have high hopes for CSS Grid Layout here. Grid Layout is native HTML, so it complements Web Components quite naturally.
“Glue” to combine widgets (e.g. data binding).

Currently, frameworks are largely incompatible: they usually come with their own tool chain, inheritance API, widget infrastructure, etc. The developments described in this post, along with ECMAScript 6’s classes and modules, point to a future where everything will be much more interoperable. The benefits for the web development ecosystem are obvious.

Resources

If you want to know more about Web Components and Polymer, you have the following resources at your disposal:

Talks at Google I/O 2013:
- “Web Components: A Tectonic Shift for Web Development” by Eric Bidelman
- “Web Components in Action” by Matthew McNulty, Alex Komoroske [builds on the previous talk, covers Polymer]
HTML5 Rocks: articles on Web Components.
Polymer homepage: polymer-project.org

JavaScript quirk 6: the scope of variables

2013-05-15T20:33:00.001+02:00

[This post is part of a series on JavaScript quirks.]

In most programming languages, variables only exist within the block in which they have been declared. In JavaScript, they exist in the complete (innermost) surrounding function:

    function func(x) {
        console.log(tmp); // undefined
        if (x < 0) {
            var tmp = 100 - x;  // (*)
            ...
        }
    }

The cause of the above behavior is hoisting: Internally, the declaration at (*) is moved to the beginning of the function (the assignment stays where it is). That is, what a JavaScript engine actually executes looks like this:

    function func(x) {
        var tmp;
        console.log(tmp); // undefined
        if (x < 0) {
            tmp = 100 - x;
            ...
        }
    }

But there is a trick to limit the scope of a variable to a block, it is called Immediately Invoked Function Expression (IIFE, pronounced “iffy”). Below, we use an IIFE to restrict the scope of tmp to the then-block of the if statement.

    function func(x) {
        console.log(tmp); // ReferenceError: tmp is not defined
        if (x < 0) {
            (function () {  // open IIFE
                var tmp = 100 - x;
                ...
            }());  // close IIFE
        }
    }

We wrapped a function around the insides of the block, creating a new scope for them. Then we immediately called that function. tmp only exists inside the IIFE. Note that the parentheses at the beginning and the end of the IIFE are necessary. They lead to the function being interpreted as an expression, which is the only form in which it can be be immediately invoked.

Netflix’s technology and hiring practices

2013-05-14T17:00:00.000+02:00

In the article “Netflix, Reed Hastings Survive Missteps to Join Silicon Valley's Elite”, Ashlee Vance profiles Netflix and its CEO Hastings for Businessweek. The article mentions a few interesting tidbits about the company’s technology and hiring practices:

Netflix data comprises a third of the incoming data in North American homes.
Their infrastructure is based on Amazon Web Services.
In off-peak hours, Netflix’s systems are repurposed to analyze data. The results are used to pre-cache data and to determine the likelihood of success of a show that Netflix might finance.
As an employer, Netflix pays well:
Managers routinely survey salary trends in Silicon Valley and pay their employees 10 percent to 20 percent more than the going rate for a given skill. Fired employees also get ultragenerous severance packages; the idea is to remove guilt as an obstacle to management parting ways with subpar performers.
And they prefer to have older employees:
Netflix also tends to employ older people than its peers. “We hire fully formed adults,” says Cockcroft. “We let them do five years at Google before taking them on.”

JavaScript history: undefined

2013-05-11T22:51:00.001+02:00

Two tweets by Brendan Eich shed light on the history of JavaScript having both undefined and null [1].

The first version of JavaScript did not have exception handling, which is why JavaScript so often converts automatically [2] and/or fails silently (tweet).

JavaScript copied Java’s approach of partitioning values into primitives and objects [3]. null is the value for “not an object”. The precedent from C (but not from Java) is to convert null to 0 (C has pointers, not references and lets you perform arithmetic with pointers).

Remaining problem: In JavaScript, each variable can hold both primitives and objects. In Java, a variable’s static type limits it to either kind of value. We therefore need a value for “neither a primitive nor an object”. That value could be null, but at the time, Eich wanted something that wasn’t “reference-y” (associated with objects) and did not convert to 0 (tweet). Now you know why undefined and null are converted to different numbers:

    > Number(undefined)
    NaN
    > Number(null)
    0

References:

Beyond “always on”

2013-05-10T22:48:00.000+02:00

Current technology encourages us to be continuously connected. This blog post predicts that that will change.

Always on

The direction that technology currently takes us could be described as “always on”. The goal is to give us more updates, more quickly. Three recent examples. First, Facebook Home. The website describes the “always on” vision quite well (emphasis is mine):

With Home, everything on your phone gets friendlier. From the moment you turn it on, you see a steady stream of friends’ posts and photos. Upfront notifications and quick access to your essentials mean you’ll never miss a moment. And you can keep chatting with friends, even when you’re using other apps.

Second, Google Glass, where there is always a screen in front of your eyes. Third, existing and rumored smart watches which are also about receiving notifications more directly.

Beyond “always on”

Notifications are a form of stimuli. And, for evolutionary-biological reasons, those are hard to resist for humans. They are mental sugar, if you will. However, we need periods of rest. Thus, my prediction is that health concerns and decreasing interest in social media (et al.) will eventually lead people to look for alternatives. Historically, communication has (roughly) gone through the following stages:

very sporadic and asynchronous (letters)
sporadic and synchronous (traditional phones)
sporadic and asynchronous (non-mobile email)
continuous and synchronous (mobile dumbphones)
continuous and asynchronous, with the occasional synchronous communication (mobile smartphones)

The most important technology for giving us freedom from “always on” is (fast) asynchronous communication. As we are moving away from being continuously connected, I expect many innovations in that area. Managing one’s attention is a competitive advantage, which increases the likelihood of good solutions being created – there is money to be made.

Pets in wheelchairs

2013-05-08T05:35:00.001+02:00

Cute: two pets lost their ability to use their hind legs, so their owners built them wheelchairs.

First: the piglet “Chris P. Bacon”.

Second: the kitten “Brigitta”.

JavaScript quirk 5: parameter handling

2013-05-05T09:15:00.000+02:00

[This post is part of a series on JavaScript quirks.]

The basics of parameter handling in JavaScript are simple, advanced tasks require manual work. This blog post first looks at the basics and then covers advanced topics.

The basics of parameter handling

Two facts form the core of JavaScript parameter handling.

Fact: you can always pass an arbitrary amount of parameters

When calling a function, you can pass as many or as few actual parameters as you want, independently of how many formal parameters are mentioned in the function declaration. Parameters that are missing have the value undefined. Parameters that are too many are ignored. Let’s use the following function for a demonstration:

    function f(x, y) {
        console.log('x: '+x);
        console.log('y: '+y);
    }

You can call this function with arbitrary many parameters:

    > f()
    x: undefined
    y: undefined

    > f('a')
    x: a
    y: undefined

    > f('a', 'b')
    x: a
    y: b

    > f('a', 'b', 'c')
    x: a
    y: b

Fact: all passed parameters are stored in `arguments`

All passed parameters are stored in the special, “Array-like” (see below for what that means) variable arguments. The following function lets us examine how that variable works.

    function g() {
        console.log('Length: '+arguments.length);
        console.log('Elements: '+fromArray(arguments));
    }

Function fromArray is shown below, it converts arguments to an array so that it can be logged. Using g():

    > g()
    Length: 0
    Elements: 
    > g('a')
    Length: 1
    Elements: a
    > g('a', 'b')
    Length: 2
    Elements: a,b

arguments is always there, no matter how many parameters have been explicitly declared. It always contains all actual parameters.

Has a parameter been passed?

If a caller does not provide a parameter, undefined is passed to the function. Because undefined is falsy [1], you can use an if statement to check whether the parameter “exists” or not:

    function hasParameter(param) {
        if (param) {
            return 'yes';
        } else {
            return 'no';
        }
    }

Thus, you get the same result if you omit a parameter and if you pass undefined:

    > hasParameter()
    'no'
    > hasParameter(undefined)
    'no'

The test works also well for truthy values:

    > hasParameter([ 'a', 'b' ])
    'yes'
    > hasParameter({ name: 'Jane' })
    'yes'
    > hasParameter('Hello')
    'yes'

With falsy values, however, you have to be careful. For example, false, zero and the empty string are interpreted as missing parameters:

    > hasParameter(false)
    'no'
    > hasParameter(0)
    'no'
    > hasParameter('')
    'no'

Still, this pattern has proven itself. You do have to be vigilant, but the code becomes pleasantly compact and it does not matter whether callers omit a parameter, pass undefined or pass null.

Default values for parameters

The following function should accept zero or more parameters. Parameters x and y should have the value 0 if they are missing. A simple way of doing that is:

    function add(x, y) {
        if (!x) x = 0;
        if (!y) y = 0;
        return x + y;
    }

Interaction:

    > add()
    0
    > add(5)
    5
    > add(2, 7)
    9

You can write add() more compactly by using the “or” operator (||). This operator returns the first operand if it is truthy and otherwise the second operand. Examples:

    > 'abc' || 'def'
    'abc'
    > '' || 'def'
    'def'
    > undefined || { foo: 123 }
    { foo: 123 }
    > { foo: 123 } || 'def'
    { foo: 123 }

Let’s use || to assign parameter default values:

    function add(x, y) {
        x = x || 0;
        y = y || 0;
        return x + y;
    }

An arbitrary number of parameters

You can also use arguments to accept an arbitrary number of parameters. One example is the following function format() that is modeled after the classic C function sprintf:

    > format('Hello %s! You have %s new message(s).', 'Jane', 5)
    'Hello Jane! You have 5 new message(s).'

The first argument is a pattern in which '%s' marks blanks. The following arguments are filled into those blanks. A simple implementation of format looks like this:

    function format(pattern) {
        for(var i=1; i < arguments.length; i++) {
            pattern = pattern.replace('%s', arguments[i]);
        }
        return pattern;
    }

Note: the loop skips the first parameter (arguments[0]) and thus ignores pattern.

Enforcing a certain number of parameters

If you want to force a caller to provide a certain number of parameters, you need to check arguments.length, at runtime:

    function add(x, y) {
        if (arguments.length > 2) {
            throw new Error('Need at most 2 parameters');
        }
        return x + y;
    }

`arguments` is not an array

arguments is not an array, it is only array-like: you can access the i-th parameter via arguments[i] and you can determine how many parameters there are via arguments.length. But you can’t use Array methods such as forEach and indexOf. Further details, along with solutions are discussed in quirk 8. As a preview, the following function converts an array-like value to an array.

    function fromArray(arrayLikeValue) {
        return Array.prototype.slice.call(arrayLikeValue);
    }

Reference

JavaScript quirk 1: implicit conversion of values [explains “truthy” and “falsy”]

Win a ticket for Fluent Conference

2013-04-30T09:54:00.000+02:00

Update 2013-05-03: A winner has been determined and received the ticket.

Fluent Conference takes place in San Francisco from May 28–30, 2013. Its tag line is “JavaScript & Beyond”. The 2ality blog raffles off a ticket for the last two days (excluding the workshop day). To win, tweet the following text:

I’d like to win a ticket for Fluent Conference. #2alityFluent
http://www.2ality.com/2013/04/fluent-raffle.html

The deadline is Friday, May 3rd, 2013, 14:00 GMT. I’ll contact the winner via Twitter, within a few hours of the deadline. (If the winner isn’t following me already, I’ll ask them to temporarily do so, so that I can send them a direct message.)

[Legal disclaimer: I make no guarantees w.r.t. to there being a winner. Contesting this raffle via legal means is not allowed.]

JavaScript quirk 4: unknown variable names create global variables

2013-04-28T15:58:00.004+02:00

[This post is part of a series on JavaScript quirks.]

Normally, JavaScript automatically creates a global variable if you use an unknown variable name:

    > function f() { foo = 123 }
    > f()
    > foo
    123

Thankfully, you get a warning in ECMAScript 5 strict mode [1]:

    > function f() { 'use strict'; foo = 123 }
    > f()
    ReferenceError: foo is not defined

Reference:

JavaScript’s strict mode: a summary

JavaScript quirk 3: normal equality (==)

2013-04-24T19:31:00.004+02:00

[This post is part of a series on JavaScript quirks.]

Let’s start with a simple rule: the normal equality operators == and != are so problematic that you should always use strict equality (=== and !==). Some people say that there are exceptions to this rule, I disagree [2]. Keeping this rule in mind, we can now take a look at what is strange about == without burdening our minds unnecessarily.

The “normal” equality operator (==) has many quirks. While it is forgiving, it does not adhere to the typical rules of truthy and falsy (see quirk 1):

    > 0 == false  // OK
    true
    > 1 == true  // OK
    true
    > 2 == true  // not OK
    false

    > '' == false  // OK
    true
    > '1' == true  // OK
    true
    > '2' == true  // not OK
    false

Apart from that, it lets you compare values that aren’t really comparable:

    > '' == 0
    true
    > '\n  123  \t' == 123
    true

The last check is true because conversion to number ignores leading and trailing whitespace in JavaScript.

If you are still interested in finding out how exactly == works, you can read up on it here: [1]. With strict equality (===), values of different types are never equal [1], which means that all of the above problems go away.

References:

Checking for undefined: === versus typeof versus falsiness

2013-04-19T17:02:00.003+02:00

There are several ways of checking whether a variable has the value undefined. This blog post explains the differences.

Checking via ===

Using strict equality [1] is the canonical way of checking for undefined:

    if (x === undefined) ...

Changing undefined

undefined is a property of the global object (and thus a global variable). Under ECMAScript 3, you could change its value. Under ECMAScript 5, you can’t do that, any more:

    > undefined = 123
    > undefined
    undefined

You can, however, shadow it in a function, either via a parameter or via a local variable:

    > (function () { var undefined = 123; return undefined; }())
    123

From now on, undefined is used to refer to the identifier, while undefined is used to refer to the actual value.

Because you could globally change the value of undefined under ECMAScript 3, two techniques were often used to ensure that it had the correct value. If you are targeting older browsers, these techniques are still relevant.

Technique 1: shadow undefined yourself.

    (function (undefined) {
        if (x === undefined) ...  // safe now
    }());  // don’t hand in a parameter

Above, undefined is a parameter whose value is undefined, because it has not been provided by the caller.

Technique 2: compare with void 0. The void operator [2] evaluates its operand, ignores the result and returns undefined. That means that void 0 will always evaluate to undefined.

    if (x === void 0)  // always safe

Checking via typeof

You can also check for undefined via the typeof operator [3]:

    if (typeof x === 'undefined') ...

This is more verbose and can be slower (though many engines optimize). It has two advantages: First, it is safe with regard to a changed undefined (not that important under ECMAScript 5). Second, it also works for unknown variables:

    > typeof iDontKnowThisVariable === 'undefined'
    true
    > iDontKnowThisVariable === undefined
    ReferenceError: iDontKnowThisVariable is not defined

Checking for falsiness

undefined is falsy (interpreted as false in boolean contexts, [4]):

    > Boolean(undefined)
    false

Hence, you can check for undefined like this:

    if (!x) ...

The usual caveat applies: The condition of the above if statement will also be true for: null, false, -0, +0, NaN, "".

Conclusion

Recommendation: check for undefined either via === undefined or via falsiness. It is normally more important for code to be easy to understand than to be completely safe. Therefore, checking via === void 0 is rarely a good choice.

References

News is bad for you

2013-04-18T14:03:00.003+02:00

Quoting “News is bad for you – and giving up reading it will make you happier” (by Rolf Dobelli for The Guardian):

In the past few decades, the fortunate among us have recognised the hazards of living with an overabundance of food (obesity, diabetes) and have started to change our diets. But most of us do not yet understand that news is to the mind what sugar is to the body. News is easy to digest. The media feeds us small bites of trivial matter, tidbits that don't really concern our lives and don't require thinking.

This has been on my mind for a long time: Most of the stuff you learn via the news is just as relevant for your actual life as, for example, the politics of Westeros. It’s too far away to matter, a single incident (that we can’t help but generalize), too limited a perspective (a single person writing about a general issue), etc. The uselessness of that knowledge can be easily demonstrated by looking at a newspaper from a year ago: how much of its content is still worth knowing today?

Furthermore, for biological reasons, negative things more easily attract our attention than positive things, which is why the former make up most of the news. But that skews our perception. To balance it, we would also need to know about people who are currently incredibly happy.

I don’t advocate ignoring news completely, but you should limit your exposure. It is not my only news source, but I find that Twitter filters the news quite nicely for me; there is a focus on creativity and fun. But I only follow a few, carefully selected people and try to avoid tweeters that complain too much.

For pop culture and society news, I’d love to see more positive reporting: highlighting creativity and encouraging multi-facted thinking, as opposed to “fashion fail” negativity and simplistic “she betrayed him” drama.

So, the next time you feel smug about knowing something about global politics (etc.) that someone else doesn’t – remember: you may only know simple factoids, that may not even be that useful.

JavaScript quirk 2: two “non-values” – undefined and null

2013-04-14T23:48:00.000+02:00

[This post is part of a series on JavaScript quirks.]

Most programming languages have only one value for “no value” or “empty reference”. For example, that value is null in Java. JavaScript has two of those special values: undefined and null. They are basically the same (something that will change with ECMAScript 6, as will be explained in the last post of this series), but they are used slightly differently.

undefined is assigned via the language itself. Variables that have not been initialized yet have this value:

    > var foo;
    > foo
    undefined

Similarly, JavaScript assigns undefined to missing parameters:

    > function id(x) { return x }
    > id()
    undefined

null is used by programmers to explicitly indicate that a value is missing. E.g. for JSON.stringify():

    > console.log(JSON.stringify({ first: 'Jane' }, null, 4))
    {
        "first": "Jane"
    }

Check: does a variable have a value?

If you want to know whether a variable v has a value, you normally have to check for both undefined and null. Fortunately, both values are falsy. Thus, checking for truthiness via if performs both checks at the same time:

    if (v) {
        // v has a value
    } else {
        // v does not have a value
    }

You’ll see more examples of the above check in the post for quirk 5 about parameter handling. There is one caveat: this check also interprets false, -0, +0, NaN and '' as “no value”. If that isn’t what you want then you can’t use it. You have two choices.

Some people advocate lenient non-equality (!=) to check that v is neither undefined nor null:

    if (v != null) {
        // v has a value
    } else {
        // v does not have a value
    }

However, that requires you to know that != considers null to be only equal to itself and to undefined. I prefer the more descriptive use of !==:

    if (v !== undefined && v !== null) {
        // v has a value
    } else {
        // v does not have a value
    }

Performance-wise, all three checks shown in this section are more or less the same. Hence, which one you will end up using depends on your needs and your taste. Some minification tools even rewrite the last check to a check via !=.

[Sponsor] Where are JavaScript and the web going?

2013-04-09T00:02:00.002+02:00

The Fluent conference co-chairs look ahead.

[A blog post by Simon St. Laurent, originally published on the O'Reilly Programming Blog, republished with permission.]

JavaScript and HTML5 just keep moving. One day it’s form validation, the next animation. Then it becomes full-on model view controller stacks getting data from sensors on devices and communicating with back-end servers that are themselves largely JavaScript.

Peter Cooper and I have tried to capture some of this power in the upcoming Fluent conference, so that attendees can find their ways to the tools that work for them. Early registration for Fluent ends April 10. To get a 20% discount, use the registration code “2ALITY”.

Peter and I paused for a moment to talk about what we’re doing and where we see JavaScript and the Web heading. Though we work together on the conference, our perspectives aren’t quite the same, something I think works out for the better.

Highlights include:

Different tiers of technology adoption (discussed at the 2:41 mark)
“3-D demos don’t really interest the main market, whereas doing medical visualization, stuff like that, is more mass market” (5:42)
“The experimental end with robots … Nodecopter” (9:30)
JavaScript crossing over to the server with Node, or a polyglot world? (11:27)
Can frameworks or other languages that compile to JavaScript address modularization and code management questions? (14:50; and more on enterprise development at 17:43)
Learning from Ruby and Rails’ RJS experience (22:40)
Learning JavaScript “to get the job done” (26:08)

You’ll find our full discussion in the following video:

O’Reilly sponsors this week on 2ality.

JavaScript quirk 1: implicit conversion of values

2013-04-08T09:41:00.002+02:00

[This post is part of a series on JavaScript quirks.]

JavaScript is very tolerant when it comes to accepting values. For example, everywhere it expects a number, it does not reject values from other types, but tries to convert them:

    > '5' - '2'
    3
    > '5' * '2'
    10

Automatic conversion to boolean is rarely problematic and often useful. It is covered here as a preparation for later – we’ll use it to work around quirks. Automatic conversion to string, however, can cause problems.

Implicit conversion to boolean: “truthy” and “falsy” values

Whenever JavaScript expects a boolean value (e.g. for the condition of an if statement), any value can be used. It will be interpreted as either true or false. The following values are interpreted as false:

undefined, null
Boolean: false
Number: -0, +0, NaN
String: ''

All other values are considered true. Values interpreted as false are called falsy, values interpreted as true are called truthy. You can use Boolean as a function to test how a value is interpreted. It converts its argument to boolean:

    > Boolean(undefined)
    false
    > Boolean(0)
    false
    > Boolean(3)
    true

Implicit conversion of strings

In web development, you often get values as strings that are actually numbers or booleans. For example, when users enter this kind of data in a form. If you forget to explicitly convert these strings then JavaScript will surprise you negatively in two ways: First, there will be no warning. Second, the values will be converted automatically, but wrongly. The plus operator (+), for instance, is problematic, because it concatenates strings as soon as one of its operands is a string. During the following interaction with JavaScript, the assumption is that we are adding 1 to 5. Instead, we are concatenating the strings '5' and '1'.

    > var x = '5';  // wrong assumption: x is a number
    > x + 1
    '51'

Furthermore, there are a few falsy values that are truthy if converted to string. Example: false.

    > Boolean(false)  // truthy?
    false
    > String(false)
    'false'
    > Boolean('false')  // truthy?
    true

Example: undefined.

    > Boolean(undefined)  // truthy?
    false
    > String(undefined)
    'undefined'
    > Boolean('undefined')  // truthy?
    true

Implicit conversion of objects

Objects are only implicitly converted if JavaScript expects a number or a string. In the former case, the conversion takes three steps:

Call valueOf(). If the result is primitive (not an object) then use it and convert it to a number.
Otherwise, call toString(). If the result is primitive, use it and convert it to a number.
Otherwise, throw a TypeError.

Example for step 1:

    > 3 * { valueOf: function () { return 5 } }
    15

Example for step 3:

    > function returnObject() { return {} }
    > 3 * { valueOf: returnObject, toString: returnObject }
    TypeError: Cannot convert object to primitive value

If JavaScript converts to string, steps 1 and 2 are swapped: toString() is tried first, valueOf() second.

Best practice: explicit conversion

It is best to explicitly convert values to the desired types before using them. A minimal solution is to use the functions Boolean(), Number() and String():

    function handleFormData(formData) {
        var givenName = String(formData.givenName);
        var age = Number(formData.age);
        ...
    }

These functions always return a value (they never throw an exception). However, Number() returns the error value NaN [1] if it can’t convert a value:

    > Number('xyz')
    NaN
    > Number(undefined)
    NaN
    > Number(null)
    0
    > Number(true)
    1

A more elaborate solution would be to first check whether the value you are converting has the correct format (e.g. someone shouldn’t enter 'xyz' as their age) and to take appropriate measures if it doesn’t.

Reference

NaN and Infinity in JavaScript

12 JavaScript quirks

2013-04-08T08:42:00.003+02:00

A core of JavaScript (the so-called “good parts”) is elegant, but that core is often obscured by quirks. This introduction is the first of a series of blog posts that looks at twelve common quirks and how to best deal with them:

Implicit conversion of values
Two “non-values” – undefined and null
Normal equality (==)
Unknown variable names create global variables
Parameter handling
The scope of variables
Inadvertent sharing of variables via closures
Array-like objects
Subtyping constructors
Reading and writing of properties
this in real functions
The for-in loop

A concluding post will cover ECMAScript 6 [1], which will eliminate most of the above quirks.

The series will provide a good overview of JavaScript. It is a translation of a previous blog post in German. ECMAScript 5 will be used and a basic knowledge of JavaScript is required, but much will be explained. I will post one quirk per week.

Reference:

ECMAScript: ES.next versus ES 6 versus ES Harmony

Google’s Blink: a few interesting facts

2013-04-05T11:28:00.000+02:00

With Blink, Google has created a permanent fork of the WebKit HTML engine. This blog post mentions a few interesting facts that provide context for that decision.

How much did each company contribute to WebKit?

There are several interesting diagrams and numbers in the article “Reviewers and companies in the WebKit project” (by Daniel Izquierdo Cortázar for Bitergia). It’s remarkable how much Google has recently contributed to WebKit. Obviously, not all contributions are created equal: some benefit everyone, others only the contributor. We don’t know what the ratio between the two kinds is for Apple, Google, etc.

Why didn’t WebKit2 adopt Chrome’s multiprocess architecture?

Here is an Apple employee’s explanation of why WebKit2 has a multiprocess architecture that is different from Chrome’s:

Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

The link also contains answers from Googlers to that assertion.

How will WebKit change without Chrome support?

It will become simpler. For example, quite a few conditional code sections can be removed, especially those for supporting two JavaScript engines (JSC = JavaScriptCore and V8):

    #if USE(V8)
    #if !USE(JSC)
    #if PLATFORM(CHROMIUM)
    #if USE(GOOGLEURL)

GOOGLEURL is URL-handling code where Google uses its own library, Google-URL. It’s interesting that the split has existed since 2008.

Conclusion

It’s impossible to know Google’s exact motivations behind the fork (freedom to do their own thing, not wanting to help Apple, etc.). There probably was no single dominant motivation. The future will be interesting: How hard will Google push its own technologies Native Client and Dart? How will this affect the rest of Blink? How much will Google collaborate with other companies? It looks like they will continue their current strategy of hedging their bets. A good example is a recently filed issue for adding asm.js [1] support to V8. asm.js can be seen as a competitor to Native Client.

All things considered, forking WebKit seems the best solution for everyone involved, as far as the browser implementation side is concerned. Web developers will have to wait and see, but there are already many subtle differences between the variants of WebKit.

Reference

asm.js: closing the gap between JavaScript and native

Enforcing toString()

2013-04-04T07:58:00.002+02:00

JavaScript usually automatically converts values to the type that a method or operator needs, which can lead to a variety of bugs. As a counter-measure, Brian McKenna (@puffnfresh) suggests using the following code for your tests:

    Object.prototype.valueOf = function () {
        throw new Error('Use an explicit toString');
    };

What is the effect of this code? You now can’t use the plus operator to convert an object to string, any more:

    > var obj = {};

    > 'Hello '+obj
    Error: Use an explicit toString

    > String(obj)
    '[object Object]'
    > obj.toString()
    '[object Object]'

    > 'Hello '+String(obj)
    'Hello [object Object]'

How does this work? To convert an object to a specific primitive type T, it is first converted to any primitive value which is then converted to T. The former conversion happens in two steps [1]:

Call method valueOf(). If it returns a primitive, we are done.
Otherwise, call method toString(). If it returns a primitive, we are done.
Otherwise, throw an error.

The above order of first invoking valueOf() and then toString() is chosen if the final conversion is to a number. If the final conversion is to string then toString() is invoked first. The plus operator converts to either number or string, but it produces a first primitive via the “number” algorithm [2].

Without the code snippet at the beginning of this post, Object.prototype.valueOf() returns this (an object) and is inherited by all objects that don’t override this method:

    > var obj = {};
    > obj.valueOf() === obj
    true

The plus operator therefore eventually calls toString(). The code snippet prevents that and throws an error before the operator can get to that method. Note that the error message is not always completely correct:

    > Number(obj)
    Error: Use an explicit toString

But this trick can still be useful. If an object really wants to be converted to a number then it will bring its own valueOf(), anyway.

References

ECMAScript Harmony features in Node.js

2013-04-01T18:50:00.003+02:00

Quick tip (via David Klassen): The following shell command lists all (highly experimental!) ECMAScript Harmony [1] features that can be switched on in Node.js.

    node --v8-options | grep harmony

For example, Node.js 0.10.2 supports:

`--harmony_typeof`	enable harmony semantics for `typeof`
`--harmony_scoping`	enable harmony block scoping
`--harmony_modules`	enable harmony modules (implies block scoping)
`--harmony_proxies`	enable harmony proxies
`--harmony_collections`	enable harmony collections (sets, maps, and weak maps)
`--harmony`	enable all harmony features (except `typeof`)

Note: “harmony semantics for typeof” is something that (unfortunately) had to be rejected for Harmony. It would have consisted of typeof null returning 'null', but that change would break too much existing code.

Reference:

ECMAScript: ES.next versus ES 6 versus ES Harmony

Ecma wasn’t always Ecma

2013-03-28T06:51:00.001+01:00

Most people know that ECMAScript is the language standard behind JavaScript [1]. Fewer people know that its name comes from Ecma International, the organization managing this standard. Interestingly, that organization started as “European Computer Manufacturers Association (ECMA)”, but renamed itself to “Ecma International” in 1994. That was done to reflect its increasingly international focus. Ecma is now not considered an acronym, any more. Ecma International is located in Geneva. In contrast, TC39 [1], the Ecma-hosted committee evolving ECMAScript, is rather USA-centric (true to where JavaScript was created and who created it) and usually meets somewhere in California.

This little bit of history also explains why it’s spelled ECMAScript and not EcmaScript: That’s a remnant from when Ecma was still ECMA.

Reference:

ECMAScript: ES.next versus ES 6 versus ES Harmony

Parallel JS (River Trail): soon in Firefox

2013-03-24T19:27:00.000+01:00

Parallel JS will soon be included in Firefox Nightly builds. This project was initially called River Trail [1]. It automatically parallelizes code that uses the ParallelArray type and its array-like methods (map() etc.). [Source of this post: “Parallel JS lands” by Nicholas D. Matsakis.]

Time table:

Now: Only a limited subset of JavaScript is supported and you don’t get good feedback as to whether your code could be parallelized and if not, why not.
Medium term: All pure functions (that don’t mutate shared state, only data that they create and store in local variables) will be parallelizable; better diagnostics when parallelization is not possible.
Long term: Make parallelization as wide-spread in JavaScript as possible and evolve the API. One possible improvement is to bring parallelization to normal arrays. Currently, ParallelArray pulls double duty, it is both a lightweight array that can be manipulated in parallel and a capable multi-dimensional matrix. Matsakis proposes adding parallelizing methods to arrays (e.g. unorderedMap()), so that ParallelArray can focus on the latter duty.

Related blog post, with more information on Parallel JS:

JavaScript: parallel programming via River Trail coming to Firefox

ECMAScript 6: TC39’s January 2013 meeting

2013-03-21T02:12:00.003+01:00

TC39 [1] is the committe that currently plans ECMAScript 6 (code-named ECMAScript.next), the next version of the JavaScript language standard. January 29–31, they had another meeting. Thanks to Rick Waldron’s notes, we can read up on what has been decided. This blog post describes the highlights. Previous blog posts summarized prior meetings.

(Note: a blog post on the March TC39 meeting will be posted at some time in the future.)

January 29

Object.is(): strict equality (===) is safer than sloppy equality (==). But it still has the quirk of NaN not being equal to itself [2]. The original plan for ECMAScript 6 was to introduce an is operator that fixes this quirk, but those plans have been abandoned. Instead, you can use Object.is(op1, op2) if you need “stricter” equality [2]. Object.is() also distinguishes positive and negative zero [3] (which isn’t always desirable).
ECMAScript Internationalization API (ECMA-402): Chrome 24 shipped with an (unprefixed) implementation of the first edition of ECMA-402. Thanks to the API, the methods String.prototype.localeCompare, {Date,Number}.prototype.toLocaleString get meaningful implementations (until now, they didn’t do anything locale-specific on most JavaScript engines). Work to specify the second edition of ECMA-402 continues.

January 30

Static methods

ECMAScript 6 will allow one to define static methods (constructor methods) in classes. For example:

    class Point {
        constructor(x, y) {
            this.x = x;
            this.y = y;
        }
        static zero() {
            return new Point(0, 0);
        }
    }

This is the same as:

    class Point {
        constructor(x, y) {
            this.x = x;
            this.y = y;
        }
    }
    Object.mixin(Point, {
        zero() {
            return new Point(0, 0);
        }
    });

An `Array.prototype.map()` that doesn’t return an array

Arrays have several methods that create a new array based on the current one. For example, concat and filter. If those methods are invoked on a subtype of Array, it is obvious what type the result should have: the same type as this. For map, things are more complicated: that method is translating from one kind of value to another one and you sometimes might want to change the collection that the result is in, too. Hence, subtypes of Array will inherit the following method (Array-like types might get it, too):

    Array.from(iterable, mapFunction?, thisValue?)

Compared to a previous version [4], the second and third parameter are new. The receiver (this) of from() determines which subtype of Array the result will be stored in. Example from the Waldron’s notes:

    // Turn an array of nodeNames into NodeList of nodes
    NodeList.from( ["div"], node => document.createElement(node) );

Destructuring is refutable by default

Destructuring is used when a value is ready to be stored somewhere: it allows you to extract data from that value via patterns on the receiving end (left-hand side of an assignment, parameter definitions, etc.). Refutable matching means that the extraction can fail and throw an exception. It has been decided that refutability should be the default for destructuring in ECMAScript 6 (“fail-fast” operation). That is, destructuring only succeeds if the value to be stored completely matches the pattern:

    { first: f, last: l } = { first: 'Jane', last: 'Doe' };  // succeeds
    { first: f, last: l } = { first: 'Jane' };  // fails

You can, however introduce irrefutability by suffixing parts of the pattern with a question mark (rule of thumb: the question mark follows pattern parts, not variables):

    { first: f, last?: l } = { first: 'Jane' };  // succeeds
    console.log(l);  // undefined

Another possibility is to give a left-hand-side variable a default value:

    { first: f, last: l = 'Unknown' } = { first: 'Jane' };  // succeeds
    console.log(l);  // Unknown

A default value is triggered if the part of the pattern is missing or if its value is undefined:

    let { a: x = 1 } = { a: undefined }
    console.log(x);  // 1

You can also make all of a pattern irrefutable:

    let { foo: f }? = options;  // always succeeds

f becomes undefined if options is undefined or null or does not have a property foo. This example shows that irrefutability is “deep”: if you mark a part as irrefutable, the parts inside of it become irrefutable, too. A proposal on the ECMAScript wiki has details on refutable matching, but uses a slightly different syntax (prefix question marks).

Property `name` of functions

ECMAScript 6 will standardize the property name of functions. Its main use is debugging: you get a name if you log a function and debuggers can use the name, too. ECMAScript 6 will try to fill in the name as best it can: In addition to the obvious cases (function declaration, named function expression, method definition), a function will also get a name if it is the initial value of a variable declaration (var, let, const) or a property value inside an object literal.

TypedArray becomes part of ECMAScript

TypedArray is a JavaScript type that was created for WebGL to handle binary data. TC39 will move this standard into ECMAScript 6. In the process, it can become a more organic part of the language (e.g. become more similar to arrays).

January 31

Modules are still work in progress. The following subsections describe other decisions.

Refining the semantics of classes

Classes can’t extend non-constructors. If you write a class:

    class Foo extends X { ... }

Then X must be a constructor (X will become Foo’s prototype and X.prototype will become Foo.prototype’s prototype). You can, however extend null:

    class Bar extends null { ... }

Roughly, this is syntactic sugar for:

    function Bar() { ... }
    Bar.prototype = Object.create(null);
    ...

Map/Set comparator

You will be able to configure how these ECMAScript 6 data structures compare keys or values in order to implement the operations get, set, has, delete. The new signatures are (the second parameter is new):

    new Map(iterator = undefined, comparator = undefined)
    new Set(iterator = undefined, comparator = undefined)

If you don’t specify a comparator, a “default comparator” is used that works like === [6], but considers NaN to be equal to itself. Otherwise you wouldn’t be able do anything with NaN, apart from adding it to a collection. Alternatively, you can also specify the comparator to be 'is', which means that Object.is() will be used [2]. That function works like the default comparator, but distinguishes +0 and -0 [3].

Simplified syntax for array comprehensions and generator comprehensions

Previously, array comprehensions [7] looked like this:

    let arr = [x for x of itr if x > 0];

This has been changed to:

    let arr = [for (x of itr) if (x > 0) x];

Now the element expression comes last, which is more similar to the structure of an implementation that uses loops. The expression is preceded by zero or more comprehension clauses. Those clauses now have parenthesized syntax. There previously was a let clause, which may or may not be added after ECMAScript 6. Arguably, let would make comprehensions more complex, while their main appeal is simplicity. Details of the new syntax are described in a gist by David Herman.

References

Subclassing builtins in ECMAScript 6

2013-03-18T16:40:00.000+01:00

In JavaScript, it is difficult to create sub-constructors of built-in constructors such as Array. This blog post explains the problem and possible solutions – including one that will probably be chosen by ECMAScript 6. The post is based on Allen Wirfs-Brock’s slides from a presentation he held on January 29, during a TC39 meeting.

The problem

Creating sub-constructors of built-in constructors is difficult to impossible. The normal pattern for subtyping in JavaScript is (ignoring the property constructor [1]):

    function SuperConstr(arg1) {
        ...
    }
    function SubConstr(arg1, arg2) {
        SuperConstr.call(this, arg1);
    }
    SubConstr.prototype = Object.create(SuperConstr.prototype);

If you want to use this pattern with built-in constructors, you are facing problems. The following example demonstrates those problems for Array; they are similar for other builtins.

Trying to subtype Array

Take, for example, the following code, where we try to subtype Array.

    function MyArray(len) {
        Array.call(this, len);
    }
    MyArray.prototype = Object.create(Array.prototype);

This doesn’t work:

    > var a = new MyArray();
    > a[2] = 'abc';
    > a.length
    0

Compare: a normal array.

    > var b = [];
    > b[2] = 'abc';
    > b.length
    3

If you invoke a constructor C via new C(arg1, arg2, ...), two steps happen (in the internal [[Construct]] method that every function has):

Allocation: create an instance inst, an object whose prototype is C.prototype (if that value is not an object, use Object.prototype).
Initialization: Initialize inst via C.call(inst, arg1, arg2, ...). If the result of that call is an object, return it. Otherwise, return inst.

There are obstacles to both steps when you try to subtype Array.

Allocation obstacle: MyArray allocates the wrong kind of object

Array instances are special – the ECMAScript 6 specification calls them exotic. Their handling of the property length can’t be replicated via normal JavaScript. If you invoke the constructor MyArray then an instance of MyArray is created, not an exotic object.

Initialization obstacle: MyArray can’t use Array for initialization

It is impossible to hand an existing object to Array via this – it completely ignores its this and always creates a new instance.

    > var a = [];
    > var b = Array.call(a, 3);
    > a === b   // b is a new object
    false
    > b.length
    3
    > a.length   // a is unchanged
    0

Thus, the Array.call(...) in the first line of MyArray does not work.

Solutions

Solution: proto

On JavaScript engines that support __proto__ [2], you can do the following:

    function MyArray(len) {
        var inst = new Array(len);
        inst.__proto__ = MyArray.prototype;
        return inst;
    }
    MyArray.prototype = Object.create(Array.prototype);

Apart from changing the prototype of an existing object being a relatively costly operation, the biggest disadvantage of this solution is that you can’t subtype MyArray in a normal manner, either.

This is the only solution that works in current browsers (that support __proto__).

Non-solution: constructors make objects exotic

One could change the Array constructor so that it makes objects that are passed to it exotic. But then one faces difficulties: Some exotic objects have a special structure that you can’t add to an object after the fact. And it would allow one to add several exotic features to the same object (e.g. by first calling Array and then Date), which could lead to conflicts and other problems.

ECMAScript 6 solution: decouple allocation and initialization

Specification-wise, the new operator invokes the internal [[Construct]] method, which roughly looks like this:

    Function.prototype.[[Construct]] = function (...args) {
        let Constr = this;

        // Allocation
        let inst = Object.create(Constr.prototype);

        // Initialization
        let result = Constr.apply(inst, args);
        if (result !== null && typeof result === 'object') {
            return result;
        } else {
            return inst;
        }
    }

Array overrides this method to allocate an exotic object.

Eliminating the allocation obstacle. In a subtype of Array, we’d like to reuse method [[Construct]] of Array. In ECMAScript 5, we can’t, because the prototype of a constructor is always Function.prototype and never its super-constructor. That is, it doesn’t inherit [[Construct]] from its super-constructor. However, in ECMAScript 6, constructor inheritance is the default.

Additionally, Wirfs-Brock proposes to handle allocation in a separate, publicly accessible method whose key is the well-known symbol @@create (that can be imported from some module). Array would only override that method and default [[Construct]] would look like this for all constructors:

    Function.prototype.[[Construct]] = function (...args) {
        let Constr = this;

        // Allocation
        let create = Constr[@@create] || Object[@@create];
        let inst = create();

        // Initialization
        let result = Constr.apply(inst, args);
        if (result !== null && typeof result === 'object') {
            return result;
        } else {
            return inst;
        }
    }

Many builtins would have custom @@create methods: Array, String, Boolean, Number, Date, RegExp, Map, Set, Weakmap, ArrayBuffer, ... These builtins have exotic instances and/or custom values for the internal property [[Class]] [3].

Eliminating the initialization obstacle. Sub-constructors need to be able to use Array for initialization. Thus, it needs to distinguish two different kinds of invocation:

Used as a function: create a new instance.
Used for initialization (via new or via a super-call): set up this.

This is more tricky than it seems (and not something you should do for your own constructors). You might try the following:

    function Foo() {
        'use strict';
        if (this === undefined) {  // (*)
            // Invoked as a function
        } else {
            // Invoked for initialization
        }
    }

However, this fails if you put Foo into a namespace object:

    var namespace = {};
    namespace.Foo = Foo;
    namespace.Foo();   // not treated as a function call

In line (*), you need to ensure that this is not an instance of Foo:

    if (this === undefined || !(this instanceof Foo)) ...

You could also trigger the “function” case for instances of Foo that have already been initialized.

This solution will probably be adopted by ECMAScript 6. Its complexity will be largely hidden: You can either use the canonical way of subtyping shown above or you can use a class definition:

    class MyArray extends Array {
        ...
    }

When `new` does not initialize

The following problem is independent of the “function versus initialization” problem mentioned in Sect. 2.3: Some constructors, even when invoked directly via new, don’t initialize the instance that has been created, they throw it away. The following subsections describe when that happens.

Factory constructors

Use case. A factory constructor is “abstract”: it examines its arguments and, depending on their values, invokes one of its sub-constructors. Many class-based languages use static factory methods for this purpose.

Solution. You need to distinguish whether you are called directly via new or via a sub-constructor. It is conceivable to add language support for this. An alternative is to have a parameter calledFromSubConstructor whose default value is false. Sub-constructor set it to true. If it is true, you initialize. Otherwise, you return the result of a sub-constructor.

Cached instances

This use case is very similar to factory constructors. For example, constructor might put every instance it creates in a cache. If it is told to create an instance that is similar to one in the cache, it returns the cached one, instead. The solution is the same as for factory constructors. However, if you subtype, more work is probably needed, especially if the subtype has a different notion of similarity.

Returning an argument

Some constructors return their argument if it fulfills certain criteria. For example, Object:

    > var obj = {};
    > new Object(obj) === obj
    true

Again, this can be solved in the manner described in Sect. 3.1.

A few observations

The constructor as a method

In ECMAScript 6, the role of the constructor as a method that initializes an object increases. Take, for example, the following line from the [[Construct]] method:

    let result = Constr.apply(inst, args);

It is equivalent to:

    let result = inst.constructor(...args);

Furthermore, sub-constructors call super-constructors to help them with initialization. For example:

    function SubConstr(arg1, arg2) {
        super.constructor(arg1);  // or: super(arg1)
    }

Lastly, even though a class is internally translated to a constructor, the actual constructor body is inside a method:

    class MyClass {
        constructor(...) {
            ...
        }
        ...
    }

JavaScript becomes less prototypal

With constructors handling allocation via @@create, you can’t use the prototype to create an instance, any more:

    let inst = Object.create(MyConstr.proto);
    inst.constructor(arg1, arg2);

Instead, you have to do the following.

    let inst = MyConstr[@@create]();
    inst.constructor(arg1, arg2);

A method for post-initialization?

One could introduce @@postConstruct, a method that is invoked after all constructors have been executed. It is the inverse of @@create. Use case for this method: freeze an instance or make it non-extensible.

②ality – JavaScript and more

Plans for supporting Web Components in AngularJS and Ember.js

AngularJS

Ember.js

Reference

JavaScript quirk 7: inadvertent sharing of variables via closures

Closures

The quirk: inadvertent sharing

A practical example

Reference

Google’s Polymer and the future of web UI frameworks

Polymer

The Foundation layer (platform.js)

Layers: Core and Elements

Interoperability

When can I use it?

Polymer versus other frameworks

What does it all mean?

Resources

JavaScript quirk 6: the scope of variables

Netflix’s technology and hiring practices

JavaScript history: undefined

Beyond “always on”

Always on

Beyond “always on”

Pets in wheelchairs

JavaScript quirk 5: parameter handling

The basics of parameter handling

Fact: you can always pass an arbitrary amount of parameters

Fact: all passed parameters are stored in arguments

Has a parameter been passed?

Default values for parameters

An arbitrary number of parameters

Enforcing a certain number of parameters

arguments is not an array

Reference

Win a ticket for Fluent Conference

JavaScript quirk 4: unknown variable names create global variables

JavaScript quirk 3: normal equality (==)

Checking for undefined: === versus typeof versus falsiness

Checking via ===

Changing undefined

Checking via typeof

Checking for falsiness

Conclusion

References

News is bad for you

JavaScript quirk 2: two “non-values” – undefined and null

Check: does a variable have a value?

[Sponsor] Where are JavaScript and the web going?

JavaScript quirk 1: implicit conversion of values

Implicit conversion to boolean: “truthy” and “falsy” values

Implicit conversion of strings

Implicit conversion of objects

Best practice: explicit conversion

Reference

12 JavaScript quirks

Google’s Blink: a few interesting facts

How much did each company contribute to WebKit?

Why didn’t WebKit2 adopt Chrome’s multiprocess architecture?

How will WebKit change without Chrome support?

Conclusion

Reference

Enforcing toString()

References

ECMAScript Harmony features in Node.js

Ecma wasn’t always Ecma

Parallel JS (River Trail): soon in Firefox

ECMAScript 6: TC39’s January 2013 meeting

January 29

January 30

Static methods

An Array.prototype.map() that doesn’t return an array

Destructuring is refutable by default

Property name of functions

TypedArray becomes part of ECMAScript

January 31

Refining the semantics of classes

Map/Set comparator

Simplified syntax for array comprehensions and generator comprehensions

Fact: all passed parameters are stored in `arguments`

`arguments` is not an array

An `Array.prototype.map()` that doesn’t return an array

Property `name` of functions

Solution: proto

When `new` does not initialize