from Hacker News

What’s New in ES2019

by davman on 7/30/19, 9:30 AM with 398 comments

by mmartinson on 7/30/19, 1:17 PM
Honest question, not meant to be inflammatory.
If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal.
I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.
by halfmatthalfcat on 7/30/19, 11:41 AM
Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things.
[1] https://github.com/tc39/proposal-pattern-matching
[2] https://github.com/tc39/proposal-optional-chaining
by ojosilva on 7/30/19, 1:53 PM
A year back I dropped a proposal idea at the EcmaScript discussion list, I hope it get's picked up sometime.
My idea is that `let`, `var` and `const` return the value(s) being assigned. Basically I miss being able to declare variables in the assertion part of `if` blocks that are scoped only during the `if()` block existence (including `else` blocks).
Something along these lines:
```
    if( let row = await db.findOne() ) {
         // row available here
    }

    // row does not exist here
```
The current alternative is to declare the variable outside the `if()` block, but I believe that is inelegant and harder to read, and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope.
As previous art, Golang's:
```
      if x:=foo(); x>50 {
        // x is here
      }
      else {
        // x is here too
      }
      
      // x is not scoped here
```
And Perl's
```
      if( ( my $x = foo() ) > 50 ) {
           print $x
      }
```
by afandian on 7/30/19, 10:18 AM
It's great to see JS getting some of the features of better planned languages.
But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation.
In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't know if you could retrofit features like const or mut. But, speaking personally, it might create enough safety-net to consider JS again.
(Maybe I'm missing an obvious feature?)
by rglover on 7/30/19, 12:38 PM
That array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.
by chriswwweb on 7/30/19, 11:59 AM
A read a similar article few days ago (might be interesting too) (not mine): https://medium.com/@selvaganesh93/javascript-whats-new-in-ec...
And also here is a good recap of ES 6/7/8/9 (just in case you missed something) (also not mine): https://medium.com/@madasamy/javascript-brief-history-and-ec...
by jeffwass on 7/30/19, 10:45 AM
Object.fromEntries will be super useful, surprised it’s taken this long to become a native feature.
by NKCSS on 7/30/19, 11:27 AM
Why did they create a flatMap method? What is wrong with .map(...).flat()? Can they improve the performance by combining it that much?
by dawhizkid on 7/30/19, 4:16 PM
arr.flat(Infinity) seems like a strange decision for flattening the entire array - wouldn't the most common number of levels to flatten an array be all levels, in which case I'd expect arr.flat() to flatten the whole array but in this case it's just 1 level.
by namelosw on 7/30/19, 12:04 PM
Finally, flatMap is here.
I really hope there could be syntactic sugar like do expression in Haskell, for in Scala, and LinQ in C# for flatMap instead of type limited version like async await.
Another thing is pipe operator seems to be very welcome among the proposals. There will be no awkward .pipe(map(f), tap(g)) in RxJS since then.
by swalsh on 7/30/19, 11:56 AM
Some half decent stuff in here, but I heavily disagree with changing the output of toString. That might cause problems if someone is expecting one output, but the new version creates something new. I don't see a reason why they couldn't have just added a new function functionCode() or something similar. It would give people the functionality they want, without destroying backwards compatibility.
by ahmedfromtunis on 7/30/19, 12:09 PM
Can someone please point me to the rationale behind the new toString() function?
by moomin on 7/30/19, 10:26 AM
That’s a surprisingly small amount of change. I’ll leave it to others to determine if that’s a good or bad thing.
by jonstaab on 7/30/19, 2:31 PM
Isn't the new function string representation backwards incompatible? Having struggled with javascript's lame error tooling I could see people actually using it in production too.
by intea on 7/30/19, 12:08 PM
Why are empty elements in an array allowed? oO
[1,2,,3]
by kuon on 7/30/19, 10:25 AM
The part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things.
I really love languages that force you to handle errors up to the top level.
by zitto on 7/30/19, 12:54 PM
It's very exciting to see how JavaScript is evolving!
by pier25 on 7/30/19, 7:25 PM
I feel after ES6 and async/await in ES7 we're getting pretty meager upgrades.
IMO the three features that would make a much more significant impact in front end work are:
- optional static types
- reactivity
- some way to solve data binding with the DOM at the native level
by bitwize on 7/30/19, 2:27 PM
Ummm... 25^2 is 625. 15^2 is 225 (see the Object.fromEntries example). I mean, I knew JavaScript math was a bit sloppy due to the use of floating point everywhere, but I hope it's not THAT bad...
by alexlur on 7/30/19, 11:19 AM
That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.
by mhd on 7/30/19, 2:54 PM
So, what coffeescript features are we still missing after this round?
by bryanrasmussen on 7/30/19, 3:57 PM
I think the flatMap method is pretty solid evidence for my contention the language is really getting bloated now.
by DonHopkins on 7/30/19, 4:50 PM
Is that all there is that's new? Maybe it's a good thing that JavaScript is finally slowing down.
by estomagordo on 7/30/19, 10:51 AM
Under symbol.description:
const test = Symbol("Desc");
testSymbol.description; // "Desc"
---------
Should testSymbol be replaced with test?
by Already__Taken on 7/30/19, 10:18 PM
Why does flatmap exist? What's against `sentence.map().flat()`
by john-foley on 7/30/19, 10:55 AM
Hard to believe that const arr4 = [1, 2, , 4, 5]; is valid.
by derefr on 7/30/19, 10:16 AM
.
by ZenPsycho on 7/30/19, 11:09 AM
seems like a real missed opportunity to add string.leftPad()
by la12 on 7/30/19, 3:50 PM
At this point, I'm convinced that Javascript is basically a jobs creation program.
We go on adding fancy new syntax for little or no gain. The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.
Similarly, python which was resistant to the idea of 20 ways to do the same thing, also seems to be going in the direction of crazy things like the "walrus" operator which seems to be increasing the cognitive load by being a little more terse while not solving any fundamental issues.
Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table.
Also, features should be removed just as aggressively as they are added, otherwise you end up with C++ where you need less of a programmer to be able to tell what a given expression will do and more of a compiler grammar lawyer who can unmangle the legalese.
by Dirlewanger on 7/30/19, 1:23 PM
Can we get some additions that replace the garbage one-liner `is-even`/`is-odd` npm libraries that are a scourge?
by jorangreef on 7/30/19, 2:37 PM
Most of this is sugar, e.g. flat() and flatMap(), out of scope for a language spec.
Function.toString being more accurate is helpful.
But real progress would be removing dangerous backtracking regular expressions in favor of RE2: https://github.com/google/re2/wiki/Syntax