Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s New in ES2019

blog.tildeloop.com

Post reply on HN
Print view View original

101–110 of 411 posts

Re: What’s New in ES2019

#101

Post by mmartinson »

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

Re: What’s New in ES2019

#102

Post by dspillett »

john-foley wrote: post #23

Hard to believe that const arr4 = [1, 2, , 4, 5]; is valid.

Seems perfectly logical to me: an array of length 5 with four populated elements and one empty one (3). Though I did double-check my understanding that the length property would report 5 rather than 4 (it does).

What looks out of place to you in that example?

Would it make more sense to you with a very slightly less arbitrary example, perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4']; instead of simple mapping ints to ints?

Because array contents are mutable [even if the array variable itself is declared const] that third index may be populated at a later point in the code.

Re: What’s New in ES2019

#103

Post by mrighele »

afandian wrote: post #25
felixfbecker wrote: post #16

Earlier quoted context omitted.

JS already has immutable objects with `Object.freeze()`. Personally I just use TypeScript which can enforce not mutating at compile time (for the most part).

Thanks. But can I then add and remove items from an immutable object to create new objects? Part of the immutable value proposition is being able to work with the objects. Based on [0] Freezing feels more like constant than immutable. And the 'frozenness' isn't communicated through the language - I could be passed a frozen or unfrozen object and I wouldn't know without inspecting it. And freeze isn't recursive agains…

> But can I then add and remove items from an immutable object to create new objects?

Yes, although the new object is not frozen by default. Adding is quite straight forward, expecially with the spread syntax

    let x = { a: 1, b: 2 };
    Object.freeze(x)
    let y = {...x, b: 3}
    // y == { a: 1, b: 3 }
Removing is less intuitive

    let x = { a: 1, b: 2 };
    Object.freeze(x)
    let { b, ...y} = x;
    // y == { a: 1 }
> And the 'frozenness' isn't communicated through the language

Yes, but given that JS is a dynamic language I wouldn't expect anything different (everything must inspected at runtime).

> And freeze isn't recursive against the entire object graph

You're right, although one could quickly implement a recursive version.

In any case I find Object.freeze not much useful since trying to mutate a frozen object will simply ignore the operation; I think that most of the time trying to do that should be considered an error and I would prefer to have and exception raised.

Re: What’s New in ES2019

#104

Post by MH15 »

dsego wrote: post #99
zitto wrote: post #91

It's very exciting to see how JavaScript is evolving!

Honest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.

It's exciting to see the language that we use for the web gain these features (albeit late)! These changes will allow us to follow better programming practices with less overhead.

Re: What’s New in ES2019

#105

Post by jacobwilliamroy »

wongarsu wrote: post #61
jacobwilliamroy wrote: post #22

Earlier quoted context omitted.

> for(let e of arr) e = b Is that just arr.map( e => b ) ?

It doesn't do anything and was my attempt to give a simple example that is somewhat obvious while glossing over the complexity let arr = [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}]; let b = "!" for(let e of arr) e = b; console.log(arr) [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}] (unmodified) for(let e of arr) e.a = 2; console.log(arr) [{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (modified) for(let e of arr) {let…

Thanks for sharing more context. I see what you were trying to illustrate with your earlier examples now.

Why not make a little library so you can do these kinds of things safely without reimplementing them every project? Maybe call it safeCopy or something.

Re: What’s New in ES2019

#106

Post by specialist »

jwilliams wrote: post #39
kuon wrote: post #6

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. I really love languages that force you to handle errors up to the top level.

I see what you're saying - for me, my experience with Java checked exceptions put me off the idea. In Java it led to lots of exception wrapping and leaky abstractions. Not sure what the answer is - although my golang experience was better.

My current best guess is Java's checked exception silliness comes from the enterprise framework culture. Too much abstraction, architecture, cleverness, turgidity. I joke that Spring is an Exception obfuscation framework.

I've always really liked checked exceptions in my own designs. Though I'm not crazy about the syntax.

Re: What’s New in ES2019

#108

Post by icholy »

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…

I like TypeScript's (stage-3) approach to feature adoption.

Re: What’s New in ES2019

#109

Post by pas »

phpnode wrote: post #68
halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution. I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when…

It seems that only `when` and `->`is the new syntax, no? The arrow seems something that could be replaced with `=>`, but anyway, neither seems to be very restrictive with regards to future syntax. (After all they are only defined in a `case` context, so the can be reused for whatever future purpose outside.)

Plus it's a stage1 proposal, meaning it's far from serious.

Could you link the type annotation proposal, I can't find it.

Re: What’s New in ES2019

#110

Post by Kiro »

halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

What's the point of pattern matching? Why not just a switch statement?
Post reply on HN