Skip to content

Instantly share code, notes, and snippets.

@rwaldron
Last active December 15, 2015 14:28
Show Gist options
  • Save rwaldron/5274178 to your computer and use it in GitHub Desktop.
Save rwaldron/5274178 to your computer and use it in GitHub Desktop.
This is in response to Peter van der Zee's blog post, 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.

@rwaldron
Copy link
Author

@mathiasbynens but destructuring isn't "new", like @brycebaril says it's existed in many other languages and even in JS via SpiderMonkey for years

@WebReflection
Copy link

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

AS2 (ES4) was compatible with AS1 (ES3) ... they called it AS2 regardless, it was new syntax (or better, just sugar at AS2 time).

You must admit ES6 is marking the end of ES3 compatible syntax, which was the most successful goal of ES5

The mantra, and the reason ES4 didn't make it, was that it was breaking the web.
Today things are really confusing for JS ...

  • OdinMonkey just went out with the excuse that it was not breaking the already working JS in all engines: asm.js is the future
  • ES6 won't work in any of already working JS, ES6 is the future too (so we've got two of them already)
  • TypeScript introduced by its own types ... that would be great and easier than asm.js bytecodish syntax but it breaks the web, as well as ES6 and CoffeeScript do

I believe Peter simply wrote down his concern/disappointment about a direction that will create a complete abstract mess in term of how to read and write JavaScript ... and there will be two JavaScript indeed: the new one and the old one we all know, we learned these years, we create amazing stuff, even with a 1KJS constrain (Peter is behind that awesome challenge too).

I write JS since IE4 and created polyfills for it in order to make it compatible with IE5 too ... try/catch a part the rest was working pretty much the same so I would say we could cover with current ES3 or ES5 syntax about 14 years of devices and JS engines out there ... then we put a => or a class in the code and nothing will work anymore ...

Can you see what's happening with ES6 is somehow the ES4 history repeated except this is in a time where we have more tools to make that happen?

Regardless, there are still developers like me, Peter, and I believe you too, that liked that language and all it was already able to do for all these years.

Please note developers like us are not pushing back progress, we'd like to see a different progress for this language.

We've seen JS performance boosted as never a scripting language ever had before and we all always bet on JS

Today that futuristic JS does not look anymore like that winning bet we did a while ago when we chose it instead of AS2/AS3 Flash programming ... (and I've always been convinced that the plug-in is just half of the story. I am even certified AS2 developer and never liked it over AS1)

As summary: I respect both rants, from you trying to make new things awesome and as easy and natural as possible to understand, and from him, that maybe would simply like to really write once and deploy everywhere: in 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.

@WebReflection
Copy link

@zenparsing I am sorry but yu should get real too ...

  • external code is loaded through require or AMD, yes, there is a way to do that if needed ..
  • OOP has always been expressed in JS more than you think ... uh wait, you meant classical OOP instead of prototypal one ... I see ....
  • JS has lambdas all over and shortcuts for lambdas too since ever ... l('x', 'x*x') works as you want
  • multiline strings has been always there but not spec'd, if that count, but is that really a language missing thing? 'cause string concatenation works quite well 'till now, as weel as joining through new lines, not those your editor decided, those you decided through the join contatenation string

Is not that if you arrive here and say let's get real things are more real than ever been ... you know what I mean? Not sure where you come from but that's not JS, am I right?

@pvdz
Copy link

pvdz commented Mar 30, 2013

So confused.

Rick, since when was I so unapproachable that you have to burn me here with sort of personal attacks, rather than tell me this so I could just change this? Just wow man.

Now, let me retort.

Computer properties / concise methods

{ [foo](bar) { } }

First you say this isn't valid syntax. Ok, fine. I got that snippet from a tweet by Juriy. But the fact that I'm willing to believe this might/could be valid in ES6....

Then below you say you'll take this example "modified", but it's not modified. The example that follows doesn't relate to the snippet in any way. Can you explain what you meant to do there?

Destructuring

They are reasonable, although allow for very hard to read code when combined with other features.

Maybe you could respond to that instead?

Fat arrow

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.

There has certainly been talk about this. And I recall reading this in revision 6 (July?), though I'm going to look that up to confirm, later. If the restriction is out, then great. Is it for other things as well? Is all of es6 available in "sloppy mode"?

Symbols

WTF is this?

See Axel's (original) slides, page 28: http://dl.2ality.com/es6.pdf

Rest

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

I'm pretty sure this wasn't true at some point. But maybe it was just a suggestion that never made it to the spec...

Versions

Oh really? Prior to ES3, none of these existed:

Okay. I'll keep that in mind.

they're making JS less like JS.

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

I believe I do, but I wonder if the tc39 still does.

Now if you'll excuse me, I'm going to enjoy my Easter weekend. Jezus.

@crazycactuz
Copy link

After reading peters blog i must say this was a quite impolite and immature way of replying. He clearly stated that he did not follow the latest changes and on several places he said the changes worked but was a bit hard to follow. The fact that you do no agree with everything does not warrant this kind of behaviour. The fact that addy osmani thought this a good response also saddens me.

@robdodson
Copy link

I gotta agree with @crazycactuz...

@robotlolita
Copy link

@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.

@pvdz
Copy link

pvdz commented Apr 2, 2013

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

I'm still confused by your first example.

@sandro-pasquali
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment