Live data from Hacker News

What's New in JavaScript for 2019

developer.okta.com

41–50 of 85 posts

Re: What's New in JavaScript for 2019

#41

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…

I certainly get framework fatigue with JavaScript but I think most of that has little to do with the core standard. The things that the core language has added I have found, for the most part, to have been well-considered and beneficial.

Async/await and promises do seem to be a thorough solution, with my main criticism being that they are difficult to conceptualize what is going on when a lot of promises are being composed together.

Re: What's New in JavaScript for 2019

#42
post #34

At this point why not just have browsers run TypeScript natively? Remember the , maybe just put and be done with it.

In my uneducated opinion, I think this is the direction things will go. Typescript will steadily supplant JavaScript and browsers will eventually roll out native support for it, and JS will be relegated to a legacy language.

Re: What's New in JavaScript for 2019

#43

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…

I hadnt used es6 syntax in 5 months and just got the ‘luxury’ of discovering that babel 7 came out sometime and that all of the babel dependencies are namespaced and renamed, but are the new best practices “or else”

Basically everything on stackoverflow/github issues/random JS blog is outdated regarding the inevitable error messages youll google

Re: What's New in JavaScript for 2019

#44

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…

> I might get heat for this but...

Some variant of this is the top-voted comment of every HN thread on modern JavaScript.

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

Async/Await are essentially sugar on top of Promises -- use them if you want, you don't have to. Require has been deprecated in favor of import/export to be more semantically meaningfull (e.g. with TypeScript). Webpack is the next iteration of the Browserify approach, and Bower is just flat out dead.

All of this happened 3-4 years ago, if it's your job it's not hard to keep up. If it isn't your job there's plenty of guides out there to get you up to speed. I wouldn't expect to be able to jump back into Android dev after 5+ years away from it without doing some reading, I don't know why people expect web development to be so static.

Re: What's New in JavaScript for 2019

#45
post #34

At this point why not just have browsers run TypeScript natively? Remember the , maybe just put and be done with it.

What's the point? If you're going to use typescript, you will want to do typechecking. And if you do typechecking, you might as well compile your project properly.

I'd honestly rather have browser support less than more and I'm happy with type annotations remaining a language superset. The current typescript situation is actually fantastic and as a python dev, I envy it a lot.

Re: What's New in JavaScript for 2019

#46
post #11

Earlier quoted context omitted.

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

You can have a public field named the same as a private field and all fields in JS are accessed by "this.fieldname" so you need a way to access the private field differently.

Re: What's New in JavaScript for 2019

#48

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…

> For example, the promises API, now we also have async/await.

These go together, right? An async function returns a Promise, await operates on a Promise.

Re: What's New in JavaScript for 2019

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

Ok reading that I'm going to amend my suggestion above.

    class fish {
     color = "blue";     // color is now a name in scope for this class definition
     #agenda = "Total World Domination"  // agenda is now a name in scope for this class definition

    ...
     reveal () {
       console.log("I am a " 
               + color + " Fish "  // interpreted as this.color
               +"seeking " + agenda // interpreted as this.#agenda;
     }
    }

You can still have this.agenda for public addon fields. But for the private one you can refer to it within the class definition without either this. or #

Re: What's New in JavaScript for 2019

#50
post #44

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…

> I might get heat for this but... Some variant of this is the top-voted comment of every HN thread on modern JavaScript. > 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. Async/Await are essentially sugar on top of Promises…

> All of this happened 3-4 years ago, if it's your job it's not hard to keep up. If it isn't your job there's plenty of guides out there to get you up to speed. I wouldn't expect to be able to jump back into Android dev after 5+ years away from it without doing some reading, I don't know why people expect web development to be so static.

The thing is that the JavaScript language is so aggressively changed, unlike Ruby for example, that for years, working with it professionally, the only change I can remember that was significant in my work was the safe navigation operator `&.`. The build tool (Bundler) is still the same, along with other tools. Not sure why JavaScript can't do the same? More innovation I guess?

Post reply on HN