Live data from Hacker News

What's New in JavaScript for 2019

developer.okta.com

31–40 of 85 posts

Re: What's New in JavaScript for 2019

#31
post #22

I tend to agree with the article author about the use of a # (or indeed any punctuation mark) for private fields. I think it is just a personal preference thing though. Is there any publicly available discussion that shows what lead to this decision? If fields in class definitions are incorporated I would like it to simultaneously make the field names in scope for any methods within the class definition. class Fish e…

Here's the FAQ on the private syntax: https://github.com/tc39/proposal-class-fields/blob/master/PR...

Re: What's New in JavaScript for 2019

#32

I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…

It's becoming the new PHP, where "classes" are an after-thought and there's a beginning of a "frankenstein's monster" of features pulled from other languages.

Having said that, looking at the code sample it's looking quite nice (ignoring the #'s).

Re: What's New in JavaScript for 2019

#33
post #29

I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…

Ryan Dahl seemed to imply that promises were a necessary pre-requisite for async/await. https://medium.com/@imior/10-things-i-regret-about-node-js-r... I don't have the actual transcript so summarizing based off of someone else's comments: * I added promises to Node in June 2009 but foolishly removed them in February 2010. * Promises are the necessary abstraction for async/await. * It's possible unified usage of prom…

Async/await is just syntactic sugar in languages. It's always implemented by some kind of promise/futures/task based API, itself usually built on some kind of state-machine/iterator/generator model.

Re: What's New in JavaScript for 2019

#35
post #29

I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…

Ryan Dahl seemed to imply that promises were a necessary pre-requisite for async/await. https://medium.com/@imior/10-things-i-regret-about-node-js-r... I don't have the actual transcript so summarizing based off of someone else's comments: * I added promises to Node in June 2009 but foolishly removed them in February 2010. * Promises are the necessary abstraction for async/await. * It's possible unified usage of prom…

Promises could be shimmed in browser JS (Jquery was my first experience with it) where async/await needed something like a babel/webpack transpiler for the syntax to really be feasible in a browser.

Re: What's New in JavaScript for 2019

#36
post #24

so static is `static` but private is `#` ? I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.w3schools.com/js/js_reserved.asp

I feel like i'm spamming this link every time the private fields stuff comes up, but take a look at the FAQ, it explains the reasoning behind it and why they didn't go with alternate options (like underscore, private, or others).

I was against it at first, but after reading through that document, i'm on their side now. It'll be a small but useful addition in some situations, and it's scope is extremely limited.

https://github.com/tc39/proposal-class-fields/blob/master/PR...

Re: What's New in JavaScript for 2019

#37
post #7

The only thing that still blows my mind are the private fields and methods. I understand there has been plenty of debate about it, but have not followed the conversation. I really hope that syntax does not get finalized.

Yes. I've read some of the reasoning behind choosing the syntax. Regardless of the issues, I think going with the current proposed syntax is a terrible mistake.

Me too, in fact it is the only thing I dislike about the upcoming language features.

Re: What's New in JavaScript for 2019

#38
post #22

I tend to agree with the article author about the use of a # (or indeed any punctuation mark) for private fields. I think it is just a personal preference thing though. Is there any publicly available discussion that shows what lead to this decision? If fields in class definitions are incorporated I would like it to simultaneously make the field names in scope for any methods within the class definition. class Fish e…

[deleted]

Re: What's New in JavaScript for 2019

#39
post #24

so static is `static` but private is `#` ? I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.w3schools.com/js/js_reserved.asp

There have been intense debates already for this decision. The fundamental reason is because Javascript has a messy "this.fieldname" requirement to access public fields so the only way to use a private field requires a symbol to denote that its private and not overlapping.

I would've preferred the "this.private.fieldname" instead but # is what ended up winning.

Re: What's New in JavaScript for 2019

#40
post #24

so static is `static` but private is `#` ? I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.w3schools.com/js/js_reserved.asp

I feel like i'm spamming this link every time the private fields stuff comes up, but take a look at the FAQ, it explains the reasoning behind it and why they didn't go with alternate options (like underscore, private, or others). I was against it at first, but after reading through that document, i'm on their side now. It'll be a small but useful addition in some situations, and it's scope is extremely limited. https…

Thank you for that link, will read it carefully. From the first glance it feels like an attempt to cover mess with a bigger mess:

> this is already a source of enough confusion in JS; we'd prefer not to make it worse

> Property access semantics are already complicated, and we don't want to slow down every property access just to add this feature.

> [private x] in JavaScript this would silently create or access a public field

Pardon me, but # as a declaration method of privates is an abomination.

Post reply on HN