Honest question, not meant to be inflammatory.<p>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.<p>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.
Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things.<p>[1] <a href="https://github.com/tc39/proposal-pattern-matching" rel="nofollow">https://github.com/tc39/proposal-pattern-matching</a><p>[2] <a href="https://github.com/tc39/proposal-optional-chaining" rel="nofollow">https://github.com/tc39/proposal-optional-chaining</a>
A year back I dropped a proposal idea at the EcmaScript discussion list, I hope it get's picked up sometime.<p>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).<p>Something along these lines:<p><pre><code> if( let row = await db.findOne() ) {
// row available here
}
// row does not exist here
</code></pre>
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.<p>As previous art, Golang's:<p><pre><code> if x:=foo(); x>50 {
// x is here
}
else {
// x is here too
}
// x is not scoped here
</code></pre>
And Perl's<p><pre><code> if( ( my $x = foo() ) > 50 ) {
print $x
}</code></pre>
It's great to see JS getting some of the features of better planned languages.<p>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.<p>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.<p>(Maybe I'm missing an obvious feature?)
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.
A read a similar article few days ago (might be interesting too) (not mine): <a href="https://medium.com/@selvaganesh93/javascript-whats-new-in-ecmascript-2019-es2019-es10-35210c6e7f4b" rel="nofollow">https://medium.com/@selvaganesh93/javascript-whats-new-in-ec...</a><p>And also here is a good recap of ES 6/7/8/9 (just in case you missed something) (also not mine): <a href="https://medium.com/@madasamy/javascript-brief-history-and-ecmascript-es6-es7-es8-features-673973394df4" rel="nofollow">https://medium.com/@madasamy/javascript-brief-history-and-ec...</a>
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.
Finally, flatMap is here.<p>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.<p>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.
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.
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.
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.<p>I really love languages that force you to handle errors up to the top level.
I feel after ES6 and async/await in ES7 we're getting pretty meager upgrades.<p>IMO the three features that would make a much more significant impact in front end work are:<p>- optional static types<p>- reactivity<p>- some way to solve data binding with the DOM at the native level
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...
That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.
Under symbol.description:<p>const test = Symbol("Desc");<p>testSymbol.description; // "Desc"<p>---------<p>Should testSymbol be replaced with test?
At this point, I'm convinced that Javascript is basically a jobs creation program.<p>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.<p>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.<p>Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table.<p>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.
Most of this is sugar, e.g. flat() and flatMap(), out of scope for a language spec.<p>Function.toString being more accurate is helpful.<p>But real progress would be removing dangerous backtracking regular expressions in favor of RE2: <a href="https://github.com/google/re2/wiki/Syntax" rel="nofollow">https://github.com/google/re2/wiki/Syntax</a>