Interesting that String padding made it in -- sort of jumps out as the simplest of these additions. I wonder how much of that had to do with negative PR for JS-land due to left-pad-gate.
Thanks for sharing! Interesting to me that separate repositories are used for each proposal, which is news to me. Although I can see some nice benefits to doing so.
This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.
What matters is the ongoing standardisation process. New JS features are proposed, then graduate through four stages. Once at stage four, they are "done" and guaranteed to be in the next annual ES edition write-up. Engines can confidently implement features as soon as they hit stage 4, which can happen at any time of year.
For example, async functions just missed the ES2016 boat. They reached stage 4 last July [1]. So they're officially part of ES2017 – but they've been "done" for almost a year, and landed in Chrome and Node stable quite a while ago.
I would really love to see an object map function. I know it is easy to implement, but since they seem to be gaining ranks through syntax sugar, why not just have a obj.map( (prop, value) => ... ) ? :)
I believe that one of the main reasons not to do this is that adding anything to `Object.prototype` means that now everything inherits that new method.
So you have weird things like `'foo'.map()`, `( 42 ).map()`, `new WeakMap().map()`, `false.map()`, etc.
What I wish ECMAScript had was true support for number types other than the default 32-bit float. I can use 32 and 64 bit integers using "asm.js", but this introduces other complications of its own -- basically, having to program in a much lower level language.
It would be nice if EcmaScript could give us a middle ground -- ability to use 32/64 bit integers without having to go all the way down to asm.js or wasm.
In the last couple of years we've seen a small number of significant improvements like async/await but mostly small tepid improvements like string padding, array.map(), etc. It's like TC39 are simply polishing JS.
I'd like to see TC39 tackling the big problems of JS like the lack of static type checking. I'm tired of looking at a method and having to figure out if it is expecting a string, or an object.
We had EcmaScript4 about 10 years ago with plenty of great features but TC39 killed it. And yeah, it probably made sense since the browser vendor landscape was very different back then. Today it would be possible to implement significant changes to the language much like the WebAssembly initiative.
"The versions of Unix are numbered in a logical sequence: 5, 6, 6PWB, 7, 4.1, III, 4.3, V, and V.3." -- quoted from memory from The Unix-Haters Handbook
So you see, they're following long-standing industry practice :-)
ES2017 is the conventional name now that there's annual publications of the spec. ES8 is someone reading the edition number on the document and trying to be terse. ECMA-262 is the formal name of the spec document, not the language the spec defines. All slightly different things, only one of which names the language itself, officially.
Is calling it "Javascript" even still correct, or should it be called "ECMAScript"? If someone says they write "Javascript using ES2017" are they talking utter nonsense?
I can find some references to "Javascript" being an implementation of ECMAScript, but doesn't appear to true [1]. Mozilla's implementation is SpiderMonkey, Google's is V8, and Microsoft has Chakra and JScript.
I found it helpful to go through the airbnb style guide. They have lots of examples of the "bad" (often old) way to write something, along with the "good" (often new) way. Then I updated one of my projects to follow those guidelines.
http://www.react.express is intended as a learning resource for those used to ES5 Javascript. Granted, it's for learning React through modern Javascript, so it may not be exactly what you're looking for, but it has interactive sections for new ES6 and ES7 features.
Regardless of what gets included in the spec, I hope people think critically about what to use and what not to use before they jump in. Just because something is shiny and new in JS, it doesn't mean you have to use it or that it's some sort of "best practice."
I've been looking at the stage 2 and 3 proposals. I have a difficult time finding use for any of them except for Object spread/rest. The stage 4 template string proposal allowing invalid \u and \x sequences seems like a really bad idea to me that would inadvertently introduce programmer errors. I do hope the ECMAScript standardization folks will raise the barrier to entry for many of these questionable new features that create a maintenance burden for browsers and ES tooling and a cognitive burden on programmers. It was possible to understand 100% of ES5. I can't say the same thing for its successors. I think there should be a freeze on new features until all the browser vendors fully implement ES6 import and export.
I'd like to be able to capture object modifications like Python's magic __getattr__ __setattr__ __delattr__ and calling methods that do not exist on objects. In the meantime I am writing a get, set, delete method on my object and using those instead
[+] [-] thomasfoster96|8 years ago|reply
* Object.values/Object.entries - https://github.com/tc39/proposal-object-values-entries
* String padding - https://github.com/tc39/proposal-string-pad-start-end
* Object.getOwnPropertyDescriptors - https://github.com/ljharb/proposal-object-getownpropertydesc...
* Trailing commas - https://github.com/tc39/proposal-trailing-function-commas
* Async functions - https://github.com/tc39/ecmascript-asyncawait
* Shared memory and atomics - https://github.com/tc39/ecmascript_sharedmem
The first five have been available via Babel and/or polyfills for ~18 months or so, so they’ve been used for a while now.
[0] https://github.com/tc39/proposals/blob/master/finished-propo...
[+] [-] yahelc|8 years ago|reply
[+] [-] a13n|8 years ago|reply
[+] [-] michaelmior|8 years ago|reply
[+] [-] bjacobel|8 years ago|reply
[+] [-] callumlocke|8 years ago|reply
What matters is the ongoing standardisation process. New JS features are proposed, then graduate through four stages. Once at stage four, they are "done" and guaranteed to be in the next annual ES edition write-up. Engines can confidently implement features as soon as they hit stage 4, which can happen at any time of year.
For example, async functions just missed the ES2016 boat. They reached stage 4 last July [1]. So they're officially part of ES2017 – but they've been "done" for almost a year, and landed in Chrome and Node stable quite a while ago.
[1] https://ecmascript-daily.github.io/2016/07/29/move-async-fun...
[+] [-] HugoDaniel|8 years ago|reply
[+] [-] thomasfoster96|8 years ago|reply
[+] [-] sghiassy|8 years ago|reply
[+] [-] kevincennis|8 years ago|reply
So you have weird things like `'foo'.map()`, `( 42 ).map()`, `new WeakMap().map()`, `false.map()`, etc.
[+] [-] raquo|8 years ago|reply
[+] [-] nevir|8 years ago|reply
[+] [-] ihsw2|8 years ago|reply
https://kripken.github.io/emscripten-site/docs/porting/pthre...
Granted it may be limited to consumption via Emscripten, it is nevertheless now within the realm of possibility.
For this that cannot grok the gravity of this -- proper concurrent/parallel execution just got a lot closer for those targeting the browser.
[+] [-] flavio81|8 years ago|reply
It would be nice if EcmaScript could give us a middle ground -- ability to use 32/64 bit integers without having to go all the way down to asm.js or wasm.
[+] [-] pier25|8 years ago|reply
I'd like to see TC39 tackling the big problems of JS like the lack of static type checking. I'm tired of looking at a method and having to figure out if it is expecting a string, or an object.
We had EcmaScript4 about 10 years ago with plenty of great features but TC39 killed it. And yeah, it probably made sense since the browser vendor landscape was very different back then. Today it would be possible to implement significant changes to the language much like the WebAssembly initiative.
[+] [-] pi-rat|8 years ago|reply
[+] [-] ScottBurson|8 years ago|reply
So you see, they're following long-standing industry practice :-)
[+] [-] wwwigham|8 years ago|reply
[+] [-] gregmac|8 years ago|reply
I can find some references to "Javascript" being an implementation of ECMAScript, but doesn't appear to true [1]. Mozilla's implementation is SpiderMonkey, Google's is V8, and Microsoft has Chakra and JScript.
[1] https://en.wikipedia.org/wiki/ECMAScript#Implementations
[+] [-] 43224gg252|8 years ago|reply
[+] [-] elevenE|8 years ago|reply
The last one is for ES6.
https://github.com/getify/You-Dont-Know-JS
[+] [-] stevula|8 years ago|reply
[+] [-] peterkelly|8 years ago|reply
https://ponyfoo.com/articles/tagged/es6-in-depth
[+] [-] flavio81|8 years ago|reply
ES6 (very comprehensive!) http://es6-features.org/#Constants
ES7 (succint, easy to read) https://h3manth.com/new/blog/2015/es7-features/
[+] [-] gabergg|8 years ago|reply
[+] [-] jacobwylie|8 years ago|reply
If applicable there are examples of both before and after conventions as well as links to more technical external resources.
[+] [-] samerbuna|8 years ago|reply
[+] [-] pgl|8 years ago|reply
And some interesting tweets by Kent C. Dodds: https://twitter.com/kentcdodds/status/880121426824630273
Edit: fixed KCD's name. Edit #2: No, really.
[+] [-] sjclemmy|8 years ago|reply
https://en.wikipedia.org/wiki/Ken_Dodd
[+] [-] choward|8 years ago|reply
No you didn't.
[+] [-] baron816|8 years ago|reply
[+] [-] drinchev|8 years ago|reply
Everything is supported, except "Shared memory and atomics"
[1] http://node.green
[+] [-] speg|8 years ago|reply
[+] [-] samerbuna|8 years ago|reply
https://github.com/tc39/proposals/blob/master/finished-propo...
[+] [-] correctsir|8 years ago|reply
[+] [-] rpedela|8 years ago|reply
[+] [-] giaour|8 years ago|reply
[0]: https://github.com/tc39/proposal-bigint
[+] [-] elmigranto|8 years ago|reply
[+] [-] jadbox|8 years ago|reply
[+] [-] gregjw|8 years ago|reply
[+] [-] ashnehete|8 years ago|reply
[+] [-] ascom|8 years ago|reply
[+] [-] danielsamuels|8 years ago|reply
[+] [-] emehrkay|8 years ago|reply
[+] [-] wilgertvelinga|8 years ago|reply
[+] [-] espadrine|8 years ago|reply