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.
{ [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.
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();
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...
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 });
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
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
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:
- Function expressions
- Object literal
- Array literal
- try/catch
- do ...while
- switch
- Regexp
- 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.
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 ...
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 aclass
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.