What’s New in ES2019

Post by rgoulter » Wed, Jul 31, 2019, 5:57 AM UTC

Ajedi32 wrote: post #147

Dextro wrote: post #11

Earlier quoted context omitted.

Yes, this is a real problem and I've been bitten by it more times than I can count. Now I always keep this handy website ready: https://doesitmutate.xyz/

For what it's worth, there are only two, maybe three methods in that entire list that mutate where it's not obvious: sort, reverse, and (maybe) splice. All the other methods (like push, pop, fill, etc) are methods whose entire purpose is to mutate the array.

Post by masklinn » Wed, Jul 31, 2019, 7:56 AM UTC

simias wrote: post #139

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…

That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it. If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm s…

Post by contravariant » Wed, Jul 31, 2019, 9:10 AM UTC

masklinn wrote: post #128

steenreem wrote: post #41

Earlier quoted context omitted.

They could have also implemented flat in terms of flatMap: flatMap(x => x) I personally feel flatMap is a much more used method than flat, so if you want to remove one, I would remove flat.

> They could have also implemented flat in terms of flatMap: flatMap(x => x) Flat can flatten any level of nesting (it just defaults to 1), so would be difficult to implement in terms of flatMap.

    function flatten(x, n=1) {
        return n > 0 ? x.flatmap(y => flatten(y, n-1))
                     : x;
    }

Post by z3t4 » Wed, Jul 31, 2019, 11:07 AM UTC

jacobwilliamroy wrote: post #82

heavenlyblue wrote: post #51

Earlier quoted context omitted.

>> However, it still can be quite confusing. I don't know - it's never confusing to me. I just use the IDE that allows me to view the types of the variables whenever I need to see them. IDE also highlights the definitions and then the usages of the variable, including the syntax scope where it's used. You're definitely using the wrong tools for the job if you get confused with that little detail. >> Given that JS doe…

var and let tell the compiler the scope in which it should declare the variable (oversimplifying). If var or let are not present, the variable is declared in the global scope; unless you're in strict-mode, then you get a scolding. So var and let are only tangential to the whole declaration process and only indicate the scope in which the variable is bound. I feel confused. Why do you want your assignment statements t…

Post by z3t4 » Wed, Jul 31, 2019, 11:15 AM UTC

jarekkruk wrote: post #308

heavenlyblue wrote: post #86

Earlier quoted context omitted.

The truth is that if you need to declare a variable outside your current scope you should probably declare it in the outside scope in the first place. In the scenario with var/let I need to grok the code in order to tell which variables are visible in my current scope.

I tend to mainly use const, let only when necessary. I never use var and set linter to scream about it at me. IE11 supports it, so unless you develop application for IE compatibility mode (my condolences) I don't see a reason to use var. On the other hand var mainly bites you when declaring closures inside loops, also hoisting is just plain weird.

    if(something) var foo = 1;