#this_is_not_a_comment = 6;
Yeah... it's ugly as heck but they're clearly trying to avoid new keywords. I hope the TypeScript folks can convince ECMA to adopt normal keywords like they use:
What's New in JavaScript for 2019
11–20 of 85 posts
Re: What's New in JavaScript for 2019
#12I 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 webpacker, browserify, bower. Oh! You might also be interested in using new JavaScript syntax so don't forget to use babel.
And the funny thing is they are teaching all these at bootcamps and the students have a hard time trying to understand the concepts with so many variations in them.
There is however light at the end of the tunnel which I think where TypeScript is.
Re: What's New in JavaScript for 2019
#13#this_is_not_a_comment = 6;
It looks odd, but the pound sign isn't a comment character in JS, so ... I guess it's like @ for Ruby.
Re: What's New in JavaScript for 2019
#14> There are a number of proposed changes to Classes, including field declarations, private methods and fields, and static methods and fields. So make it look full on like traditional OOP with classes, I guess? I suppose the prototype folks lost this debate.
Did you look at the proposal ? Declaration #name prefixed with hashtag. I really hope that won’t go thru.
Re: What's New in JavaScript for 2019
#15Why oh why do people use Babel over TypeScript. Why fly across the Atlantic when you can row your canoe!
Re: What's New in JavaScript for 2019
#16I'm alerted that javascript tends to bloat the stdlib. Most of the features mentioned can be implmented as a external library. This is benefitial for users as they can switch the implenmentation and upgrade versions without waiting for all of their users to upgrade the runtime first.
The prime example of javascript unnecessary bloat is fetch api which is mere wrapper for ajax calls, was developed a while ago but still cannot be used because of lack of support in older runtimes.
Re: What's New in JavaScript for 2019
#17> There are a number of proposed changes to Classes, including field declarations, private methods and fields, and static methods and fields. So make it look full on like traditional OOP with classes, I guess? I suppose the prototype folks lost this debate.
I don’t really like the direction at all. What’s next, templates? Don’t understand who is really pushing for this.
Re: What's New in JavaScript for 2019
#18#this_is_not_a_comment = 6;
Yeah... it's ugly as heck but they're clearly trying to avoid new keywords. I hope the TypeScript folks can convince ECMA to adopt normal keywords like they use: https://www.typescriptlang.org/docs/handbook/classes.html
I've read the TC39 proposal and I still don't understand what's wrong with "private".
Re: What's New in JavaScript for 2019
#19I'm alerted that javascript tends to bloat the stdlib. Most of the features mentioned can be implmented as a external library. This is benefitial for users as they can switch the implenmentation and upgrade versions without waiting for all of their users to upgrade the runtime first. The prime example of javascript unnecessary bloat is fetch api which is mere wrapper for ajax calls, was developed a while ago but stil…
From a performance standpoint it’s way better to have stdlib grow as opposed to JS bundles. Modules aren’t shared within a page so you’d end up with a lot of duplicated code that the user would have to continuously download and parse.
Re: What's New in JavaScript for 2019
#20The 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.