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

51–60 of 411 posts

Re: What’s New in ES2019

#51

Post by heavenlyblue »

shortercode wrote: post #46
heavenlyblue wrote: post #21

Earlier quoted context omitted.

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name. I makes chaining things while debugging so much harder: let a = a.project(); let a = debug(a); let a = a.eject(); vs let a1 = a.project(); let a1d = debug(a1); let a2 = a1d.eject();

I always assumed it was to protect against: accidental naming errors, confusion of what a declaration is and copy/paste issues. When I first started writing rust and saw it was a thing I thought it was a terrible idea. I'm a more open towards it now, the strong static analysis Rust does help and it can improve code quality if used in small amounts. However, it still can be quite confusing. Given that JS doesn't restr…

>> 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 doesn't restrict the type of a declaration you can just assign a new value to it, place it in a small scope or use a chain.

Yeah, but I don't want to semantically assign a new value to the variable. I want this to be a new variable, because it is a new variable.

So the point of var is slightly over exaggerated because they could have gone the python way and simply allow declarations to be anything that is an assignment.

Re: What’s New in ES2019

#52

Post by nkozyra »

robocat wrote: post #44
alexlur wrote: post #35

That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.

It also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString() It seems like an unnecessary change - if the source needs to be accessed then get the source file.

Agreed. I guess the argument for it is it's more accurately reflected but... who cares? Maybe I'm not understanding what people do with [function].toString() in the real world.

Re: What’s New in ES2019

#53

Post by cypressious »

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

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

Re: What’s New in ES2019

#55

Post by tazard »

vmasto wrote: post #54
jeffwass wrote: post #17

Object.fromEntries will be super useful, surprised it’s taken this long to become a native feature.

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.

Re: What’s New in ES2019

#56

Post by swalsh »

Some half decent stuff in here, but I heavily disagree with changing the output of toString. That might cause problems if someone is expecting one output, but the new version creates something new. I don't see a reason why they couldn't have just added a new function functionCode() or something similar. It would give people the functionality they want, without destroying backwards compatibility.

Re: What’s New in ES2019

#57

Post by jacobwilliamroy »

NKCSS wrote: post #38

Why did they create a flatMap method? What is wrong with .map(...).flat()? Can they improve the performance by combining it that much?

It is very common for people to implement flatmap themselves or get it from a library of higher-order functions. So now people can use flatMap without doing those two things.

Re: What’s New in ES2019

#58

Post by chriswwweb »

A read a similar article few days ago (might be interesting too) (not mine): https://medium.com/@selvaganesh93/javascript-whats-new-in-ec...

And also here is a good recap of ES 6/7/8/9 (just in case you missed something) (also not mine): https://medium.com/@madasamy/javascript-brief-history-and-ec...

Re: What’s New in ES2019

#59

Post by chriswwweb »

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

Yeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020

Re: What’s New in ES2019

#60

Post by brlewis »

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.

The answer is one of two possibilities: either make the IDE a little dumber and stop highlighting uncaught exceptions, or make the IDE a lot smarter and make it highlight when you catch an exception but don't do anything useful with it.

Java programmers need to be comfortable letting exceptions have the default behavior until they're sure they have a better idea. Declaring throws is usually enough.

Post reply on HN