... A community is writing the spec...

Alexandre Morgaut Alexandre.Morgaut at 4d.com
Wed Sep 10 08:17:07 PDT 2014


The way this discussion started looked very troll oriented, but let comment few things I more or less agree or not with

What I see is more functionality of the browser api then an actually language.

I actually work for 4D that provide JavaScript on the server in its Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value in ES6 for our developers on server-side

And I look into node promise and the spec promise on MDN... And I'm still not seeing the big picture. Could you give me a brief in your own words....

I think the first place I saw Promise as a specification for JavaScript was on the CommonJS mailing list and wiki

Then on WHATWG, first called Future (not anymore online) and via this github repository

Then in W3C drafts

Before finally going into JS core, then in ECMAScript

An interesting blog post about Promise history in JS:

It intends to make life better when chaining async callback calls which is absolutely not browser specific
It may have stay as a library, but then no Specification call rely on it, and many actually upcoming HTML5 features choose to rely on it

And this stupid ()=>{} arrow function... After seeing this I got the ideal of letting functions follow the same rules as for, if, while... That if it's one line of code, than let it be:
function add(arg0) console.log(arg++);

With out a body --curly braces--... Funny thing is that Firefox allow this syntax style.

var arr = [];

Copy & paste in Firefox to see.

I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for anyone that don't know them and confusing as potentially associated to "+=",  "*=", ...
- they have no room for a function name that would be useful in debugger stacks and closure scope names, or profilers function call counts

Still beware those are not only about syntax but also have different behaviors. The binding of "this" is different
I admit I fear more confusion when I see people choosing the Array forEach() to show an example
By default "this" in the forEach callback is bound to its second parameter, so some developers may have some surprises

And the generator function... Couldn't it have been: generator(args){
yield args += "gen";

Plus with a constructor:
new Generator();

This is a little different story
Using non reserved keywords will for sure break some existing code
But of course another more explicit option could have been to provide a new method on the Function native object
ex: Function.generator()

Anyone care to justify the use case for the proxy object?

Actually it's easy to justify with a very basic use case
ES5 getter / setter are great on Object but not reasonably usable when trying to catch operations on Arrays elements
(which is not at all browser specific)

Isn't the model of big new editions of spec over; in the times we live
now, with two-week frequent releases? I think ES6 will never see the
light when taken from this approach. That's why, shouldn't the release
policy be changed so that:

It has already changed, but not for ES6. ECMAScript 7 and later will
have fixed release dates. Only features that are ready at a given date
will be included.



That's all I felt necessary to say
Hope it didn't pollute and maybe even could help the group



[cid:246c92.png at d4cdef0d.498b4256]
Alexandre Morgaut
Wakanda Community Manager
Email : Alexandre.Morgaut at 4d.com<mailto:Alexandre.Morgaut at 4d.com>
Web :   www.4D.com<http://www.4D.com>

60, rue d'Alsace
92110 Clichy - France
Standard :      +33 1 40 87 92 00

[cid:ecce8b.png at 13230cc7.468344ee]<http://www.4d.com/fr/company/events/summiteu2014.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/02069845/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 246c92.png
Type: image/png
Size: 4628 bytes
Desc: 246c92.png
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/02069845/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecce8b.png
Type: image/png
Size: 91073 bytes
Desc: ecce8b.png
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/02069845/attachment-0003.png>

More information about the es-discuss mailing list