What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#341

Post by baron816 » Tue, Jul 30, 2019, 10:09 PM UTC

tazard wrote: post #55

vmasto wrote: post #54

Earlier quoted context omitted.

What would some common/helpful use cases be?

I often use Object.entries so that I can use Array.filter/map/foreach on an object, but then I need to use Array.reduce to hack it back into an object. Object.fromEntries solves this.

Yeah this is what I’m most excited for. filter and map and my preferred array traversal methods. reduce can be awkward though, and people abuse it by using it to replace or combine filter and map. fromEntries almost makes reduce unnecessary when working with objects.

Re: What’s New in ES2019

#342

Post by sdegutis » Tue, Jul 30, 2019, 10:10 PM UTC

Roboprog wrote: post #336

sdegutis wrote: post #201

Earlier quoted context omitted.

TypeScript is becoming the de facto type annotations proposal.

Let me know when (type inference of) partial function application and object literals are easy in Typescript and I’ll consider it.

Do you have a specific example of code that's hard to annotate in TypeScript? I've been using it for about a year without major issues (except somewhat slow compile times).

Re: What’s New in ES2019

#343

Post by thrownblown » Tue, Jul 30, 2019, 10:14 PM UTC

mmartinson wrote: post #177

qudat wrote: post #149

Earlier quoted context omitted.

From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are no…

> Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that…

This came up in my teams standup today. We were analyzing old dependencies and Lodash was in the list and none of us could justify why we needed it anymore. So I guess that point is nowish. Same for jQuery.

Re: What’s New in ES2019

#344

Post by Already__Taken » Tue, Jul 30, 2019, 10:18 PM UTC

Why does flatmap exist? What's against `sentence.map().flat()`

Re: What’s New in ES2019

#345

Post by TheRealPomax » Tue, Jul 30, 2019, 10:48 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…

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need?

I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.

Re: What’s New in ES2019

#346

Post by runarberg » Tue, Jul 30, 2019, 10:54 PM UTC

mantap wrote: post #258

stevenmays wrote: post #112

Earlier quoted context omitted.

I dig it too, but you could previously flatten an array with concat, and the spread operator. [].concat(...array) Lodash wasn't necessary.

No this is not an alternative, it will fail if the array is too large, as you will exceed the maximum number of arguments a function will accept (which is implementation defined). In general the spread operator should only be used for forwarding arguments not for array operations.

> In general the spread operator should only be used for forwarding arguments not for array operations.

Not quite. You should also use the spread operator when you are spreading an iterable into an array:

    const unique = [...new Set(arr)];

Re: What’s New in ES2019

#347

Post by andybak » Tue, Jul 30, 2019, 10:59 PM UTC

eropple wrote: post #298

irrational wrote: post #295

Earlier quoted context omitted.

The biggest issue I've seen with these is that at some point they do break and then you need a knowledgeable person to fix it. The pipeline is basically a black box unless you possess the knowledge of how all the parts work and interact with each other.

I dunno how to put this in a non-controversial way, but...at some point, I switched from thinking a desirable, throw-the-money-at-them developer is somebody who writes a lot of code to somebody who understands things and is capable of understanding new ones when they arise. I'm not saying that to excuse thrash . Thrash is bad. But like..."oh, at some point you'll have to have somebody who actually understands how the…

> somebody who understands things and is capable of understanding new ones when they arise.

Some of us won't let go of the crazy dream that things should be simpler. I want this not because I'm lazy or because I don't understand them but because - dammit - things should be simpler.

Re: What’s New in ES2019

#348

Post by maxwellg » Tue, Jul 30, 2019, 11:13 PM UTC

Ravengenocide wrote: post #262

dmitriid wrote: post #183

Earlier quoted context omitted.

I wonder if there are enough use-cases for .flat to not default to Infinity. It's also confusing that `arr.flatMap()` is not equivalent to `arr.map().flat()`, but to `arr.map.flat(Infinity)`

According to MDN `arr.flatMap()` is indeed equivalent to `arr.map().flat()` (without the Infinity). [1] Testing in the Chrome Devtools it also seems to be the case: x = [[[1, 2]], [[2, 3]], [[3, 4]]] x.flatMap(x=>x) output: [[1,2], [2,3], [3,4]] x.map(x=>x).flat() output: [[1,2], [2,3], [3,4]] x.map(x=>x).flat(Infinity) output: [1, 2, 2, 3, 3, 4] [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... >…

Is there any reason it isn't called mapFlat? FlatMap indicates to me that there's a flattening, then a mapping, not the other way around.

Re: What’s New in ES2019

#349

Post by tracker1 » Tue, Jul 30, 2019, 11:14 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…

If you target modern browsers only, and if you're building non-web facing apps, you should be able to... you can absolutely use this stuff today.

Right now, for example, the apps I'm working on require at least async/await support as a minimum test.

Re: What’s New in ES2019

#350

Post by tracker1 » Tue, Jul 30, 2019, 11:21 PM UTC

baddox wrote: post #234

pault wrote: post #158

Earlier quoted context omitted.

> It's popular to be sure but handwritten javascript is not that rare nowadays, is it? Long time front end developer here. In the last couple of years I can't recall seeing even a single project without a build pipeline (not that they don't exist, I just haven't encountered them at my day job, first or third party).

I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly in the browser, which of course anyone can still do. For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to ex…

I'm using Webpack + Babel... but literally only for features after async/await. All major, current browsers support it. That's the baseline support for the apps I'm working on now.

The payload to fill promises, regenerator and async are huge, and without them, my payload is significantly smaller. for preset-env...

      {
        loose: true,
        modules: false,
        useBuiltIns: 'usage',
        corejs: 3,
        targets: {
          browsers: ['edge 15', 'safari 10.1', 'chrome 58', 'firefox 52', 'ios 10.3'],
        },
        exclude: ['transform-async-to-generator', 'transform-regenerator'],
      },

from here, I only need the features not part of stage 4 that I want to add. I have the following in a test script...

    try {
      eval('(function() { async _ => _; })();');
      if (typeof fetch === 'undefined') throw new Error('no fetch');
    } catch (e) {
      window.location.replace('/auth/legacy.html');
    }

With async functions, and fetch api available, you get a LOT in the box.