Upcoming talk on ES6 in Russia

Axel Rauschmayer axel at rauschma.de
Sat Mar 23 11:41:02 PDT 2013

> Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?

There are two camps, each of which has strong feelings:

1. JavaScript is good enough as it is, don’t change anything, don’t ruin the language. [I’m writing this without irony.]
2. JavaScript needs to evolve. Quirks need to be cleaned up, features need to be supported directly by the language.

I don’t think either camp will ever completely convince the other one. Let me try, anyway; I consider myself (cautiously) in camp 2.

> The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here.

Note: JSON has always been a subset of JavaScript: It doesn’t support properties whose values are functions, unquoted property keys, etc.

> A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.

It is indeed a soup, it demonstrates all new features at once:

  let name = 'foo';
  let obj = {
      __proto__: SomeObject                 // special prop (1)
      myMethod(arg1, arg2) {           // method definition (2)
          super.myMethod(arg1, arg2);    // super reference (3)
      [name]: 123,                 // computed property key (4)
      bar                       // property value shorthand (5)

Let’s look at feature separately:

1. Rarely used, handy if you want to set up a prototype chain or explain how prototypes work.

2. Useful if you work with an object that has many methods. Compare:
    let component = {
        doThis(...) { ... },
        doThat(...) { ... },
        doSomethingElse(...} { ... }
    let component = {
        doThis: function (...) { ... },
        doThat: function (...) { ... },
        doSomethingElse: function (...} { ... }

3. Intensely ugly in ES5, clean, simple and universal in ES6.

4. Rarely used, needed for symbols (which make JS much more configurable and cleanly so). Should we use symbols for privacy then this will also allow us do private data elegantly . I’d argue that the latter is much simpler and much more JavaScript-y than what we are doing now (privacy via closures).

5. Rarely used inside object literals, often used for destructuring (pattern matching):
    let {x,y} = computePoint();
    function (required, { opt1, opt2 }) { ... }
    // Also useful for returning things:
    function computePoint() {
        let x = computeX();
        let y = computeY();
        return { x, y };

> I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript which is adopted only by a small subset of JavaScript developers who are mainly Rubyists. The fact that some things seem to them as 'acceptable' doesn't mean that comfort with the JavaScript standards and conventions. JavaScript,like all other languages, is not a language to that fits to everyone.

Good point! The new syntax will take a while to get used to, just as JavaScript takes a while to get used to. This is completely new territory, there are no precedents.

Arrow functions are a good example: A more JavaScript-y syntax would have been `fn`:
    let squares = [1,2,3].map(fn(x) { return x*x });
    let squares = [1,2,3].map(fn(x) x*x);
However, due to backward compatibility that syntax wasn’t possible. I think arrow functions are still nice enough:
    let squares = [1,2,3].map(x => x*x);


Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130323/3dc00bb6/attachment.html>

More information about the es-discuss mailing list