What’s New in ES2019

Post by orange8 » Wed, Jul 31, 2019, 2:49 AM UTC

eropple wrote: post #328

coldtea wrote: post #122

Earlier quoted context omitted.

> 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. For one, not everyone works on the client. I can write for Node and use ev…

> I can write for Node and use everything v8 supports without ever touching Babel and Typescript. You totally can do that--but you probably shouldn't, because writing TypeScript is better for you and for future you. ;)

Post by dawhizkid » Wed, Jul 31, 2019, 3:23 AM UTC

kevlened wrote: post #363

dawhizkid wrote: post #233

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.

Infinity was originally the default (which feels intuitive), but here's the argument for changing it [0]: "I think Array#flatten should be shallow by default because it makes sense to do less work by default, it aligns with existing APIs like the DOM Node#cloneNode which is shallow by default, and it would align with the existing ES3 pattern of using Array#concat for a shallow flatten. Shallow by default would also a…

Post by kdmccormick » Wed, Jul 31, 2019, 4:01 AM UTC

codenirvana wrote: post #332

kdmccormick wrote: post #169

Earlier quoted context omitted.

Nice. I like use of the let/var/const keyword to disambiguate from the accidental `if (x = y)` when intending to use `==`.

Only helps with const. Better use linting to avoid such issues.

Post by vimslayer » Wed, Jul 31, 2019, 5:30 AM UTC

SomeOldThrow wrote: post #325

snek wrote: post #162

Earlier quoted context omitted.

In JS, the pattern is the type. That is the point of duck typing.

> In JS, the pattern is the type. How do you match against a `Buffer` pattern/type?

    case (value) {
        when { constructor: Buffer } ->
            console.log("It's a Buffer!")
    }

Post by masswerk » Wed, Jul 31, 2019, 5:52 AM UTC

igneo676 wrote: post #316

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…

A few off the top of my head: 1. Node.js greatly benefits from these features. Transpiling is not as prevalent there 2. Some people do exclusively target "evergreen" browsers and don't care about IE support 3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers