What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#221

Post by MikeSchurman » Tue, Jul 30, 2019, 3:50 PM UTC

Crinus wrote: post #216

syntheticcdo wrote: post #199

Earlier quoted context omitted.

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler, the executable will work for everyone on that platform once built. Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.

> If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.

parent means if code starts using C99 features that won't work in C89, then the person with a C89 compiler needs to upgrade their compiler.

Re: What’s New in ES2019

#222

Post by tlrobinson » Tue, Jul 30, 2019, 3:51 PM UTC

mmartinson wrote: post #101

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…

Having these features in the standard gives browsers and transpilers a common, well-specified target to work towards.

If you only need to support a subset of browsers you can turn off compilation/polyfills for specific features, which sometimes leads to better performance and smaller bundles.

I think of it like TypeScript and Babel running ahead experimenting with new ideas, ES following along turning the good ideas into a spec, and browsers taking up the rear implementing the spec. It’s a pretty decent system.

Re: What’s New in ES2019

#223

Post by bryanrasmussen » Tue, Jul 30, 2019, 3:57 PM UTC

I think the flatMap method is pretty solid evidence for my contention the language is really getting bloated now.

Re: What’s New in ES2019

#224

Post by root_axis » Tue, Jul 30, 2019, 3:58 PM UTC

syntheticcdo wrote: post #218

root_axis wrote: post #212

Earlier quoted context omitted.

Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.

If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doe…

> If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all.

I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.

Re: What’s New in ES2019

#225

Post by tlrobinson » Tue, Jul 30, 2019, 3:59 PM UTC

padolsey wrote: post #113

mmartinson wrote: post #101

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…

IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported

I agree. 10 years ago I wouldn’t believe the language would be evolving (mostly improving) at the pace it currently is.

Re: What’s New in ES2019

#226

Post by root_axis » Tue, Jul 30, 2019, 3:59 PM UTC

semigroupoid wrote: post #215

root_axis wrote: post #212

Earlier quoted context omitted.

Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.

Sure, but JavaScript isn't compiled but typically interpreted (or JITed).

Sure, but this is a distinction without a difference from the perspective of the end-user.

Re: What’s New in ES2019

#227

Post by ihuman » Tue, Jul 30, 2019, 4:04 PM UTC

bitwize wrote: post #165

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...

I think it's been changed after you posted this comment. It now shows that 15^2 is 225.

Re: What’s New in ES2019

#228

Post by sbergot » Tue, Jul 30, 2019, 4:05 PM UTC

cocoflunchy wrote: post #148

ojosilva wrote: post #138

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() ) {…

Also see assignment expressions recently adopted in python 3.8: https://www.python.org/dev/peps/pep-0572/

In Python things are a bit different because declarations and assignments are ambiguous.

Re: What’s New in ES2019

#229

Post by abecedarius » Tue, Jul 30, 2019, 4:06 PM UTC

ohaideredevs wrote: post #187

rglover wrote: post #78

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.

flatMap is always so unituitive (not a word) for me for some reason. I messed with it a bunch in C#'s LINQ and RxJS and I already forgot the purpose. Not sure what it is that makes it so unnatural for me.

FWIW, I called the same function 'gather' in some of my code. You're producing lists of results for each member, and gathering them all together in order.

'map' as a function name isn't great either, since we have the same name for a data structure. What it has in its favor is being short and traditional.

Re: What’s New in ES2019

#230

Post by lucasmullens » Tue, Jul 30, 2019, 4:12 PM UTC

mmartinson wrote: post #101

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…

We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.