
What's New in JavaScript for 2019 - reverentgeek
https://developer.okta.com/blog/2019/01/22/whats-new-in-es2019
======
westoque
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 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.

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

~~~
westoque
> 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?

~~~
numbnuts
After the big dump of new features in ES2015, I don't find the pace of planned
updates to the language aggressive at all. JavaScript is still playing catch
up.

People will complain if they don't add features. When they do add new
features, people complain that they're "bloating" the language or moving too
fast. Damned if you do, damned if you don't.

The JS ecosystem is a different matter.

------
Lerc
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 extends Vertebrate {
        color = "blue";
        constructor (speed) {
          super();
          this.speed = speed;  
          if (speed > 5) color = "red" // does not need this.color because color is a class field.
        }
      }
    
      Fish.prototype.setColor = function (newValue) {
         this.color = newValue;  // this. is required because this function is outside the class definition.
      }
    

Adding this feature would allow for much tidier method bodies since there is
now enough information to imply this.fieldName from fieldName alone.

~~~
reverentgeek
Here's the FAQ on the private syntax: [https://github.com/tc39/proposal-class-
fields/blob/master/PR...](https://github.com/tc39/proposal-class-
fields/blob/master/PRIVATE_SYNTAX_FAQ.md)

~~~
Lerc
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 #

~~~
singularity2001
Yes please make the syntax simple like this! Even cleaner:

    
    
      class fish {
         color = "blue";    
         private agenda = "World Peace"  
         constructor(){
               color="red"
               agenda="Secret World Domination"
         }
         reveal () {
           console.log(`I am a ${color} Fish seeking ${agenda}`)
         }
        }

------
dsego
At this point why not just have browsers run TypeScript natively? Remember the
<script type="text/javascript"></script>, maybe just put <script
type="text/typescript"></script> and be done with it.

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

~~~
krapp
>Typescript will steadily supplant JavaScript and browsers will eventually
roll out native support for it, and JS will be relegated to a legacy language.

Typescript can't supplant javascript or relegate it to a legacy language...
because typescript doesn't compile to bytecode or machine language, but to
javascript. Browsers that support typescript natively must by definition also
support javascript natively, and the more of the former you have, the more of
the latter you have.

~~~
dsego
And C++ used to compile to C at first, I don't see your point.

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

~~~
notus
It is interesting there is so much push towards classes now when a big part of
the ecosystem (react) is moving away from them with react hooks.

------
ape4

        #this_is_not_a_comment = 6;

~~~
kbd
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](https://www.typescriptlang.org/docs/handbook/classes.html)

~~~
maxfurman
I've read the TC39 proposal and I still don't understand what's wrong with
"private".

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

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

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

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

~~~
mirekrusin
Yes, absolutely alien/awful syntax. `private` is already reserved word, why
not use it? It has been reserved word for this specific moment when it's
needed for exactly this, am I wrong? What's the point in having reserved words
in spec if the spec is afraid of using them? I don't get it, can someone
explain why this ungodly # made it so far already?

------
crdrost
`flat` and `flatMap` are highly welcome additions for me; concatenating a
bunch of lists together has historically been a very common operation for me,
that right now is done best as

    
    
        [].concat(...arrayOfArrays)
    

It is also the basis more generally for the list monad, where `.flat()` is the
`join` operation and `.flatMap()` is the equivalent `bind` operation.

So, like, the simplest example is if you're just getting a bunch of results
from a paginated source -- you want to flatten them, and it is really nice to
just have a method for that.

The list monad case is more interesting because it gives a syntax for list
comprehensions:

    
    
        [ x + y for x in list1 for y in list2 if x % 2 == 0 and y % 2 == 1 ]
    

becomes

    
    
        list1.flatMap(x =>
          x % 2 !== 0 ? [] : list2.flatMap(y => (y % 2 == 0 ? [] : x + y))
        );
    

And more theoretically this list monad is all about composing nondeterminism,
where one input could produce any of N outputs: if you store all of the
current possibilities as an array then flatMap is the core composition
primitive.

------
ryanolsonx
I'm _super_ excited for flat and flatMap. In working with multidimensional
arrays, I'm always needing to use my own `flatten` function before returning
my value. I love that this is getting native support.

------
ralmidani
JS the language is great, and it becomes even better with TypeScript. But the
ecosystem leaves a lot to be desired.

Having become proficient with Node/Express/Sequelize at Fullstack Academy and
then used them for several months, I really miss Django and Django REST
Framework. The ORM, serializers, effortless filtering and permissions, etc.
are--with all due respect--simply unmatched in JS-Land.

As for the front-end, I learned and used Ember for over a year before picking
up React (it was "cooler" and there were more jobs). So many decisions I've
agonized over with React/Redux were solved years ago with Ember. But the
problem with Ember is its proprietary object system and its lack of momentum.

If I have a choice, I will be starting new projects with Django on the server-
side, and Ember only when an SPA is necessary. In the past, I hesitated to use
Django for templates, but the lack of a robust client-side ORM has made that
option more attractive.

------
wtetzner
> Why not use private.x to refer to a private field of this, and
> private(that).x to refer to a private field of another object?

I don't find the answer to this [1] to be particularly compelling. This
actually seems like the right solution to me.

[1] [https://github.com/tc39/proposal-class-
fields/blob/master/PR...](https://github.com/tc39/proposal-class-
fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-not-use-privatex-to-refer-to-a-
private-field-of-this-and-privatethatx-to-refer-to-a-private-field-of-another-
object)

------
je42
Followed the links of the article a bit. The document explaining the process
of finding a good name ("globalThis") for global is pretty cool:
[https://github.com/tc39/proposal-
global/blob/master/NAMING.m...](https://github.com/tc39/proposal-
global/blob/master/NAMING.md)

------
elwell
Yet another signal that ClojureScript was ahead of its time when it was
created.

------
stevecalifornia
If you want to make programming inaccessible to newcomers, start making
special characters that inexplicably mean special things... like # means
'private' when placed in front of a function.

~~~
reverentgeek
That is a legitimate concern. Even if the person isn't new to programming and
is coming from other C-like languages such as Java or C#, there's a good deal
of precedence. Just like the "Don't Make Me Think" usability argument, we
ought to stick with the conventions that people already know and are familiar
with.

------
notus
The proposed globalThis seems like a hacky solution to a bad problem

~~~
reverentgeek
I agree. It's ugly. I understand it's named globalThis to avoid collision with
other libraries and breaking things, but my goodness.

------
rinchik
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](https://www.w3schools.com/js/js_reserved.asp)

~~~
Klathmon
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...](https://github.com/tc39/proposal-class-
fields/blob/master/PRIVATE_SYNTAX_FAQ.md)

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

~~~
notus
Yeah I have to agree with this. I'm getting this vibe from a lot of changes to
JS lately. A mess designed to cover another mess and people almost blindly
supporting the new mess just because there is some logical rationale for it.

------
z3t4
Noob question: What does static mean in other languages? Is it basically
Foo.prototype.bar !?

~~~
drostie
A static property is generally a global variable namespaced to the class, so
Foo.bar.

------
ivoras
Huh... why would there need to be something new for JavaScript in 2019?

At this point, it looks like they might as well import the Java syntax and
call it "JavaScript fusion" and be done with it.

------
altmind
I'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.

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

~~~
altmind
The problem here you can only rely on stdlib when most of your users have
runtimes with it. For the browser features, you may never live up to this.

Its worse to forever live with two implementations(native and polyfill) and as
large bundles, double the troubleshooting effort and extra support.

