Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScript depending on the projects and it's been great.<p>One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?). I saw that they will be introducing a new function "replaceAll(...)" to avoid the weird semantics of "replace(...)" (stopping after first occurrence unless a 'global' RegExp is passed as argument). And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start. I hope to be wrong on this one!
Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.
[This comment is wrong; see masklinn’s response for my misunderstanding.]<p>> <i>Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code:</i><p>> <i>JSON.stringify('\uD83D');</i><p>> <i>// '"\\ud83d"'</i><p>I’m inclined to consider this a misfeature, unbreaking something that I’m <i>glad</i> was broken and should have <i>remained</i> broken.<p>Unpaired surrogates are (to simplify terminology a little) basically invalid Unicode. On the web platform, the <i>only</i> situation where unpaired surrogates should be encountered is as a transient state on user input, on platforms that send non-BMP characters through in two pieces (which is most browsers on Windows). Beyond that, nothing should <i>ever</i> deal in unpaired surrogates, because they <i>will</i> make things blow up and your life miserable.<p>Unpaired surrogates cannot be represented in UTF-8, or in well-formed UTF-16 (and that’s where JavaScript did the annoyingly bad thing that we’re paying for decades later, going with UTF-16 and not requiring well-formedness). Hence I’d quibble with the description of the result as “valid UTF-8/UTF-16 code”. (Sure, the actual JSON byte stream will be valid, but it contains an escaped string that is not valid.) U+FFFD REPLACEMENT CHARACTER was at least as valid, arguably more valid.<p>Various JSON parsers will choke on such strings, as observed in what I’d consider the canonical JSON spec: <a href="https://tools.ietf.org/html/rfc7159#section-8.2" rel="nofollow">https://tools.ietf.org/html/rfc7159#section-8.2</a>.<p>In the I-JSON restricted subset, which is what I’d say everything should <i>actually</i> limit itself to, such strings are disallowed and will cause parse failure: <a href="https://tools.ietf.org/html/rfc7493#section-2.1" rel="nofollow">https://tools.ietf.org/html/rfc7493#section-2.1</a>.
> Optional catch binding<p>Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was part of a conversation somewhere, and I wonder why they chose not to go that far.
I don’t mean to hate on ECMAScript, but is anyone else slightly surprised these features weren’t in earlier?<p>Like I wonder how many bugs were introduced because the developer didn’t realize Array.sort() was unstable.
fromEntries(), aside from the symmetry with entries() is a really neat feature.<p>For example `Object.fromEntries(new URLSearchParams(window.location.search))` will parse a query string into a nice JS object. This works because the iterator of the search params class returns tuples.<p>What is already available today is `new URLSearchParams(Object.entries(params))` for turning a "params" object into a query string.
No pipe operator, no TCO, no pattern matching- <i>sigh</i>.<p>I wonder if Java will get pattern matching before JS <a href="https://medium.com/better-programming/top-5-new-features-expected-in-java-14-82c0d85b295e" rel="nofollow">https://medium.com/better-programming/top-5-new-features-exp...</a>
One thing I would fix about JavaScript is that currently "return" followed by a newline returns undefined. I would say that only return followed by ';' should return undefined. Else it should return the value of the expression following "return", whether on the same line or not, until the next ";".<p>Not sure how how much backwards compatibility this would break, but at some point we must allow for newer better less error-prone versions of the language to co-exist in different modules. That is not difficult at all. Consider the case of "use strict"; which does just such a thing. We could have "use strict 2020" etc.
Demanding a stable Array.sort is surprising. I find it questionable, as it implies a performance trade-off. Why not add a new stableSort function?<p>Trying to retroactively fixing bugs in code that did not follow the standard is not a good idea IMHO.
These features are good (except I think Function.prototype.toString is a mistake).<p>(An alternative to String.prototype.trimStart would be to use String.prototype.replace, although trimStart would probably be more efficient.) Still some things missing includes: a goto command, ability to disable automatic semicolon insertion, macros, enhanced regular expressions, and a built-in regular expression quotation function (it is easily enough to implement in JavaScript, but it seem to me the kind of thing that should be built-in).
Good stuff! Normally I cringe to see new language features, but these are pretty good (Java after lambdas, even arguably after generics, is pretty crufty, IMHO)<p>One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things. I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to skip an entry and the easiest way to do this is just return `undefined`.
I love Javascript and TypeScript, but with all the technologies gravitating around JS, the setup for a project gets clunkier and clunkier.<p>But overall, loving the direction JS is taking.
I've wished for a stable sort. But there doesn't seem to be any reliable way to determine whether the current implementation is stable or not. For most language features, you can do detection to find out whether you can use it or not. This one seems to be different.