This is in response to Peter van der Zee's blog post, http://qfox.nl/weblog/282

response.md

In Response to http://qfox.nl/weblog/282

Peter van der Zee published this post on his personal blog and it was featured in this week's edition of JavaScript Weekly. The following sections each contain a piece of code copied directly from his post, followed by an irrefutable explanation of why it is either wrong or misleading.

EDIT, April 1, 2013: I've removed any harsh language, but the content and corrections remain the same.

These are facts.

Computed properties...

{ [foo](bar) { } }

On the table, but not definite. Also, this isn't legal syntax, it's a block body with non-sense in it, that isn't legal today or even in ES6 with concise methods.

Concise methods...

Assuming there is some issue with concise methods, from the previous example...

{ [foo](bar) { } }

However, to illustrate concise methods, this is more appropriate:

var o = { 
  method() {
    console.log("hi!");
  }
};

o.method();

Destructuring...

let { first: f, last: l } = {first:'Jane', last:'Doe'};
let { first, last } = { first: 'Jane', last: 'Doe' };
[x,y] = [y,x];

I disagree that this is hard to understand, but anything new will require some amount of time investment to fully grok.

The first binds f and l identifiers that have the values of the object's first and last properties.

Like this:

var o = {
  first: 'Jane',
  last: 'Doe'
}, f = o.first, l = o.last;

The second binds first and last identifiers that have the values of the object's first and last properties.

Like this:

var o = {
  first: 'Jane',
  last: 'Doe'
}, first = o.first, last = o.last;

The third flips the values at indexes 0 and 1...

Arrow Functions...

friends.forEach(friend => { ... })

Especially with some of it's restrictions, the fact that it's only available in "strict mode" (last I heard)

Wrong, there is no such restriction.

and its implicit return value...

How is this a restriction? Arrow Functions can absolutely have an explicit return—in fact, the form you show requires an explicit return, otherwise returns undefined by default:

[ 1, 2, 3 ].map(x => x * x);

[ 1, 2, 3 ].map(x => { return x * x });

Symbols...

Are a way to create unforgeable, unguessable objects that may be used as a string is used for property names (among other uses)

[sym](arg)

I'll defer to this very real example: https://gist.github.com/rwldrn/5225237

Misinformation...

function meh(a,b,...c,{d="hello", e="world"},[f,g],h){
  console.log(a,b,c,d,e,f,g,h);
  for (num of (for (x of (for (x of [1,2,3]) x)) x*x)) console.log(num);
}
meh(...[1,2,3,4,5,6,7,8,9],[10,11,12]);

Can you figure out the output? I don't even want to bother.

I wouldn't either, because it's not valid. The rest parameter must be the last parameter in the formal parameters list.

a and b eat up 1 and 2 (respectively), leaving the remainder of the spread array argument and the second array argument for the rest params as c [3,4,5,6,7,8,9, [10,11,12]].

The generator comprehension outputs:

1
4
9

Wrong...

While the previous versions of ES were mostly backwards compatible, especially in the syntax department...

...As far as I know, this was true for the transitions to ES2 and ES3 as well.

Prior to ES3, none of these existed:

1. Function expressions
2. Object literal
3. Array literal
4. try/catch
5. do ...while
6. switch
7. Regexp
8. Error

...I'm sure there is more, but this is based on a quick comparison of the two specs.

that I think we should start calling it JS2. Because really, that's what it is.

No, because that would imply that existing code could not run in successfully in ES6 runtimes, which is not true.

they're making JS less like JS.

If that's what you think, then you don't know the spirit of JS.

I gotta agree with @crazycactuz...

@zenparsing

It has an object model capable of expressing OOP and a standard library heavily object-oriented, but no easy way to create OOP abstractions.

I'm not sure what you mean. What isn't easy about the following?

var a = { a: 1, b: 2 }
var b = { __proto__: a, c: 3 }

Sure, __proto__ is not a standard yet (and I was hoping ES6 would standardise something like prototype*, which would be closer to Self, instead). But it's not that difficult to create a lightweight abstraction over the currently provided primitives. Yes, current ES5 doesn't provide the right primitives for the model of OOP the language has, but I'd argue that ES6 doesn't either. In fact, I'd argue ES6's direction fails at that, and yet provides the wrong primitives.

Primitives in a language should make it obvious and easy to reason about what's going on. The proposed Classes don't go into that direction, since they reinforce the notion of working with blueprints/contracts of things that can construct objects, rather than working directly with objects, which is the whole philosophy behind prototypical OO.

Thanks for your revision. Here's mine: http://qfox.nl/weblog/282

I'm still confused by your first example.

Andrea has pointed out the reasons for this conflict.

Unfortunately a decade of pre-1996 Javascript work has been lost to the minds of a generation of developers raised on jQuery.

This has led to mistaken claims about Javascript's capabilities, mostly due to inexperience and the wrong kind of laziness.

For example, the OO vs Prototype debate assumes that OO is simply better, and JS suffers from its absence. In fact, the movement away from OO for representing highly complex data relationships is a real trend, due in part to the well known inability of humans to make sustainable generalizations about the future (aka Classification, Classes -- Objects). When the terrain doesn't match the map we trust the terrain, in other words. We create new impressions which may or may not make use of older impressions -- prototypes. As data becomes larger and more complex we are in greater need of dynamic languages which can accomodate fuzziness -- not brittle languages structurally dependent on rigid materials, on rivets and iron instead of polymers.

A great deal of time is being spent by supposedly well-meaning people to artificially enforce a domain mismatch.

The claim that JS needs fundamental changes in order to support "enterprise-level" development is simply untrue, on its face.

And I want to echo webreflection's lament, because it speaks to the heart of the problem when inmates run the asylum:

"[we wanted write-once run-everywhere and after] 14 years we got really close ... now it will be again everything from the scratch: a lot of development experience on top of the most adopted language simply lost"

The "irrefutable explanation" tone of this post (amusingly refuted) is the threat to the success of browser-based software, not prototypes, not dynamic typing, not semicolons or curly braces.