6 ms·

Proposals [0] that made it into ES8 (“what’s new”): * Object.values/Object.entries - https://github.com/tc39/proposal-object-values-entries https://github.com/

Proposals [0] that made it into ES8 (“what’s new”): * Object.values/Object.entries - https://github.com/tc39/proposal-object-values-entries https://github.com/tc39/proposal-object-values-entries * String padding - https://github.com/tc39/proposal-string-pad-start-end https://github.com/tc39/proposal-string-pad-start-end * Object.getOwnPropertyDescriptors - https://github.com/ljharb/proposal-object-getownpropertydescriptors https://github.com/ljharb/proposal-object-getownpropertydesc... * Trailing commas - https://github.com/tc39/proposal-trailing-function-commas https://github.com/tc39/proposal-trailing-function-commas * Async functions - https://github.com/tc39/ecmascript-asyncawait https://github.com/tc39/ecmascript-asyncawait * Shared memory and atomics - https://github.com/tc39/ecmascript_sharedmem 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-proposals.md https://github.com/tc39/proposals/blob/master/finished-propo...

yahelc 9y ago
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.
- DelaneyM 9y ago
  You can read that disaster in two ways... I consider the fact that a stupid-simple package was depended-upon by so many mature libraries as an indication it should be a language feature. Working with network protocols I find myself needing padding functions all the time, and there isn't really an elegant way to do so inline, so I welcome this addition.
  - andersonk 9y ago
    Honestly, I feel most of the blame falls to NPM for allowing publishers to delete packages. This doesn't happen in other ecosystems (e.g. Java).
    - steveklabnik 9y ago
      Afterward, they changed their policies so that this can't happen again.
    - pluma 9y ago
      Most of the blame falls to npm Inc for bending over backwards to a corporation for a bogus trademark claim they weren't even involved in. Sure, left-pad being deleted was what resulted in most people's problems but this was just the fallout from npm Inc forcibly reassigning an actively used package name from a major open source contributor to appease a company that didn't even threaten them directly.
  - mbell 9y ago
    > I consider the fact that a stupid-simple package was depended-upon by so many mature libraries as an indication it should be a language feature. Unfortunately neither the npm module nor the browser version really do what most people want and string handling in javascript is still a minefield. '\u{1F4A9}'.padStart(5, '1') => "111" // oops (\u{1F4A9} is at the end of this, HN filter) '\u{1F4A9}'.length => 2 [...'\u{1F4A9}'].length => 1 //WTF? 'mañana'.padStart(7, '1') => "1mañana" // ok 'man\u0303ana'.padStart(7, '1') => "mañana" // oops 'man\u0303ana'.length => 7 [...'man\u0303ana'].length => 7 // WTF? Why doesn't this match the behavior of [...'\u{1F4A9}'].length ? 'man\u0303ana'.normalize('NFC').padStart(7, '1') => "1mañana" // OK I do understand the unicode issues here, but the inconsistency in the APIs from a user perspective and lack of any fully cross browser support for sane string processing in Javascript means we still have only a few options: 1) Don't do string processing in javascript at all. 2) Include a library to make it sane, these are usually huge as they usually need large lookup tables. 3) Accept that things won't always be correct. This is one example but the lack of a sane standard library in Javascript is one of the biggest problems the web has right now. I'd be curious to know how many bytes of JS are loaded on the average website just to work around the lack of standard library support for basic functionality, I'd bet it's a very large number. Another fun one: Try to parse a URL and append extra query params to it, correctly.
    - javajosh 9y ago
      It seems like certain code points (like '\u{1F4A9}' aka the poop emoji) are a single character but the string report a length of 2. That is the root of all of those problems. One of your "problems", the length of an array with a single string element, isn't a problem.
      - recursive 9y ago
        > One of your "problems", the length of an array with a single string element That's not what it is. Look again, and pay attention to the ... part.
        javajosh 9y ago
- hajile 9y ago
  I believe the string padding proposal predated the "leftpad" incident by a year or so.
a13n 9y ago
I love the trailing commas for function calls. Wish we could get trailing commas for all of JSON too!
- pas 9y ago
  For that you'd need to wait until all major parser libraries support it, aaand that all deployments get updated. That means that little change is an at least 10 year long project.
- bfred_it 9y ago
  It's called JSON5 and it also has comments. The standard JSON will never "change"
- deleted 9y ago
  [deleted]
- ballenf 9y ago
  Why? I just don't find myself doing too much JSON manual editing. A few config files and such. Occasional editing of a server response or call for testing. I'm basing this on the assumption that the desire for trailing commas is making editing easier and reducing noise in diffs. Just curious if there are niches where people are spending a lot of time manually editing JSON or if the use case is something else entirely. I love them in code, despite initial resistance.
  - azernik 9y ago
    The use case for me is JSON blobs (mostly configuration files like package.json) that are checked into version control. Same motivations - reducing line-oriented diff noise.
- WalterSear 9y ago
  What I want are leading commas. Much tidier and one small thing you wouldn't have to edit/think about when adding and removing list items.
  - 9y ago
michaelmior 9y ago
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.
- thomasfoster96 9y ago
  I think that’s because a lot of proposals are initially developed away from TC39 by individuals or small groups.
bjacobel 9y ago
Please don't call it ES8. It contributes to confusion around the language. ES6 was renamed to ES2015. There is no such spec as ES7 or ES8.
- thomasfoster96 9y ago
  I know I’m technically wrong and it’s too late to edit the comment... ...but in my experience usage of ES6/ES7/ES8 as names far outweighs usage of ES2015/ES2016/ES2017. Calling it ES2017, while technically correct, would in my opinion be far more confusing to most people than calling it ES8.
  - neurotrace 9y ago
    In my experience, the usage has started swinging the other direction. While in general I agree that ES6, ES7, etc. would be less confusing, it will only confuse people more if the spec is officially called one thing but some people call it something else. If someone wanted to learn about, say, "ES10", they'd have to search for both ES10 and ES2019 to ensure they got what they wanted. I think it's better that everyone agrees to use the official naming scheme to avoid that kind of confusion. But, you know, that's just my opinion.
  - nickm12 9y ago
    This is switching and ES2017 is the name we should standardize on to avoid confusion. For example, Typescript accepts targets "ES6" or "ES2015" as synonyms, but it doesn't have targets "ES7" or "ES8", only "ES2016" and "ES2017". I personally prefer the terse version, but there are advantages to using the year-based naming.

yahelc 9y ago

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.

DelaneyM 9y ago
You can read that disaster in two ways... I consider the fact that a stupid-simple package was depended-upon by so many mature libraries as an indication it should be a language feature. Working with network protocols I find myself needing padding functions all the time, and there isn't really an elegant way to do so inline, so I welcome this addition.
- andersonk 9y ago
  Honestly, I feel most of the blame falls to NPM for allowing publishers to delete packages. This doesn't happen in other ecosystems (e.g. Java).
  - steveklabnik 9y ago
    Afterward, they changed their policies so that this can't happen again.
  - pluma 9y ago
    Most of the blame falls to npm Inc for bending over backwards to a corporation for a bogus trademark claim they weren't even involved in. Sure, left-pad being deleted was what resulted in most people's problems but this was just the fallout from npm Inc forcibly reassigning an actively used package name from a major open source contributor to appease a company that didn't even threaten them directly.
- mbell 9y ago
  > I consider the fact that a stupid-simple package was depended-upon by so many mature libraries as an indication it should be a language feature. Unfortunately neither the npm module nor the browser version really do what most people want and string handling in javascript is still a minefield. '\u{1F4A9}'.padStart(5, '1') => "111" // oops (\u{1F4A9} is at the end of this, HN filter) '\u{1F4A9}'.length => 2 [...'\u{1F4A9}'].length => 1 //WTF? 'mañana'.padStart(7, '1') => "1mañana" // ok 'man\u0303ana'.padStart(7, '1') => "mañana" // oops 'man\u0303ana'.length => 7 [...'man\u0303ana'].length => 7 // WTF? Why doesn't this match the behavior of [...'\u{1F4A9}'].length ? 'man\u0303ana'.normalize('NFC').padStart(7, '1') => "1mañana" // OK I do understand the unicode issues here, but the inconsistency in the APIs from a user perspective and lack of any fully cross browser support for sane string processing in Javascript means we still have only a few options: 1) Don't do string processing in javascript at all. 2) Include a library to make it sane, these are usually huge as they usually need large lookup tables. 3) Accept that things won't always be correct. This is one example but the lack of a sane standard library in Javascript is one of the biggest problems the web has right now. I'd be curious to know how many bytes of JS are loaded on the average website just to work around the lack of standard library support for basic functionality, I'd bet it's a very large number. Another fun one: Try to parse a URL and append extra query params to it, correctly.
  - javajosh 9y ago
    It seems like certain code points (like '\u{1F4A9}' aka the poop emoji) are a single character but the string report a length of 2. That is the root of all of those problems. One of your "problems", the length of an array with a single string element, isn't a problem.
    - recursive 9y ago
      > One of your "problems", the length of an array with a single string element That's not what it is. Look again, and pay attention to the ... part.
      - javajosh 9y ago
hajile 9y ago
I believe the string padding proposal predated the "leftpad" incident by a year or so.

a13n 9y ago

I love the trailing commas for function calls. Wish we could get trailing commas for all of JSON too!

pas 9y ago
For that you'd need to wait until all major parser libraries support it, aaand that all deployments get updated. That means that little change is an at least 10 year long project.
bfred_it 9y ago
It's called JSON5 and it also has comments. The standard JSON will never "change"
deleted 9y ago
[deleted]
ballenf 9y ago
Why? I just don't find myself doing too much JSON manual editing. A few config files and such. Occasional editing of a server response or call for testing. I'm basing this on the assumption that the desire for trailing commas is making editing easier and reducing noise in diffs. Just curious if there are niches where people are spending a lot of time manually editing JSON or if the use case is something else entirely. I love them in code, despite initial resistance.
- azernik 9y ago
  The use case for me is JSON blobs (mostly configuration files like package.json) that are checked into version control. Same motivations - reducing line-oriented diff noise.
WalterSear 9y ago
What I want are leading commas. Much tidier and one small thing you wouldn't have to edit/think about when adding and removing list items.
- 9y ago

michaelmior 9y ago

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.

thomasfoster96 9y ago
I think that’s because a lot of proposals are initially developed away from TC39 by individuals or small groups.

bjacobel 9y ago

Please don't call it ES8. It contributes to confusion around the language. ES6 was renamed to ES2015. There is no such spec as ES7 or ES8.

thomasfoster96 9y ago
I know I’m technically wrong and it’s too late to edit the comment... ...but in my experience usage of ES6/ES7/ES8 as names far outweighs usage of ES2015/ES2016/ES2017. Calling it ES2017, while technically correct, would in my opinion be far more confusing to most people than calling it ES8.
- neurotrace 9y ago
  In my experience, the usage has started swinging the other direction. While in general I agree that ES6, ES7, etc. would be less confusing, it will only confuse people more if the spec is officially called one thing but some people call it something else. If someone wanted to learn about, say, "ES10", they'd have to search for both ES10 and ES2019 to ensure they got what they wanted. I think it's better that everyone agrees to use the official naming scheme to avoid that kind of confusion. But, you know, that's just my opinion.
- nickm12 9y ago
  This is switching and ES2017 is the name we should standardize on to avoid confusion. For example, Typescript accepts targets "ES6" or "ES2015" as synonyms, but it doesn't have targets "ES7" or "ES8", only "ES2016" and "ES2017". I personally prefer the terse version, but there are advantages to using the year-based naming.