
Two Features of JavaScript that you might not know - illuminated
https://www.monkwhocode.com/2020/06/javascriptnodejs-2-features-that-you.html
======
Legogris
I find the linked post about two new features in Node.js 14[0] much more
interesting:

> Optional Chaining operator (?.)

> Nullish Coalescing operator (??)

Esp chaining can have a huge impact on readability.

[0]: [https://www.monkwhocode.com/2020/05/nodejs-v14-2-things-
to-k...](https://www.monkwhocode.com/2020/05/nodejs-v14-2-things-to-know.html)

~~~
wdb
I keep thinking that the optional chaining operator would also work for
functions e.g. this.myOptionalfunction?('hello') were I would expect it would
only get called when it's defined. But that's not possible, I think they
missed a nice addition.

Oh looks like the operator is actually '?.' instead of just '?' so guess
this.myOptionalFunction?.() could work but that looks really confusing in my
eyes.

~~~
Legogris
I am trying to think of a scenario where this makes sense, but I'm struggling.
When do you want to call a function that _might_ exist, and if so, not care
about if it exists or not? (Since null or undefined returned from the function
call can't be distinguished from the non-presence of the function)

~~~
wolco
Getting data from third party parsing as json. If method exists log and add
person/item to data object

------
neurotrace
Why in the world would you put a near full-page sized ad at the top of the
article? I seriously thought that the site had been hijacked at first

~~~
infinityplus1
Don't you use an adblocker?

~~~
hnrodey
I've used this successfully for years.

[https://github.com/StevenBlack/hosts](https://github.com/StevenBlack/hosts)

While not your _traditional_ ad blocker done via browser extension, it does
the job quite well and blocks the requests at the OS level.

I'm not the author or maintainer, just a very happy user.

~~~
MacSystem
I use brave browser

------
adamkl
A few more items added to the kitchen sink that is JavaScript.

JavaScript's multi-paradigm approach is one of its strengths, but, in my
opinion, a weakness at the same time.

It allows people to write JavaScript following whatever approach suits them,
which is fine for individual developers and small teams, but expand beyond
that and it becomes a big ask for every developer to be up to speed with every
feature JavaScript supports.

I use and teach JavaScript/TypeScript every day, and its possible to be very
productive with it, but I prefer the approaches of Go and Clojure better.
Limited languages that support a single paradigm, and support it well.

~~~
brlewis
> It allows people to write JavaScript following whatever approach suits them

This comment really looks like it's a reply to some article other than this
one.

Realistically, do you think JS programmers are going to form two camps?

    
    
      x ** y 
      Math.pow(x, y)
    

I don't think so. I think people will just stop using Math.pow.

Nor do I foresee a big problem with some numeric constants being written with
separators and others not.

In the unlikely event there's a problem with either addition, prettier can be
enhanced to make it so developers don't need to be up to speed on them.

~~~
adamkl
That's fair. My comment is probably off-base when it comes to the particular
contents of this article.

I guess I was speaking more to a general fatigue with every new feature that
is added to JavaScript/TypeScript.

What was so wrong with Math.pow(x, y) that we needed a new operator for it? I
think this is a question that could be asked of many additions to
JavaScript/TypeScript over the years, and I think every (well-intentioned)
addition has contributed to the language's current kitchen sink.

New additions don't mean the old capabilities will go away (without breaking
backwards compatibility). So yes, some developers will use the new power
operator in net-new code, but all existing usages of Math.pow() will remain,
and every new developer that learns JavaScript will now need to know both.

~~~
Silhouette
_New additions don 't mean the old capabilities will go away (without breaking
backwards compatibility)._

This is something any popular programming language has to wrestle with. There
is a lot of merit in Python's philosophy of having one, and preferably only
one, obvious way to do something. Otherwise, even if each different way is
perfectly good in its own right, you still have more for anyone learning the
language to know, and you get different representations of the same idea
appearing in the same code base for no particular reason.

I do think JavaScript has more of a problem with this than most languages
because of its rapid changes and ambiguous standardisation (the _de jure_ of
annual ES standards vs. the realities of what is supported in real time in
each browser, or Node version, or Babel preset).

Does anyone really have time to check whether some new function on Array's
prototype or some new syntax like the examples in this article is available in
every target they need to support yet? I'm guessing most of us still use Babel
in our build process for front-end code, even if the relatively new parts of
JS we're using are supported natively everywhere we need them by now.

But then you get things like modules and imports, and you still find Node's
story with these is a muddle. Things we've taken for granted for years now on
the front end don't always work out of the box as you might expect on the back
end, and there are at least two competing styles. And this is arguably the
most important and fundamental tool a programming language needs for building
larger applications!

~~~
brlewis
Why would one check if the new syntax is available rather than just use
browserslist? [https://github.com/browserslist/browserslist-
example#babel](https://github.com/browserslist/browserslist-example#babel)

~~~
Silhouette
For one thing, Node exists. If you are writing server-side or automation code,
you probably aren't using tools like Babel and Browserslist.

------
buraksarica
This link contains the biggest header ad I've ever seen. Is it on purpose? Or
is it just on my machine?

~~~
SaltyBackendGuy
Same on my machine. I ended up not reading the article due to the the ads.
Generally I'll deal with them to support the content creator, but these were
too much for me to deal with.

------
klodolph
As a minor note—the exponentiation operator was added in ES2016 / ES7, not
ES2015 / ES6. It wouldn’t matter, except you need to tell all your tools
(Terser, etc.) that you are using ES2016 or they will throw syntax errors when
processing your code.

------
sago
tldr: If you don't want to scroll down the massive header and repeated
statement of the title:

1\. Double asterisk is the exponentiation operator.

2\. _ can be used in numbers, e.g. 1_000_000

Also (and not in the article) both are also true in Python.

~~~
Shorn
Ta

------
zachrose
I was expecting this to be about object literal setters (and getters):

    
    
      const language = {
        set current(name) {
          this.log.push(name);
        },
        log: []
      };
    

Supported by browsers for fifteen years now.

------
seanalltogether
Is there a good reason that ^ is not used as an exponent operator in most
(all?) languages. Its used in every calculator Ive seen.

2^5 = 32

~~~
williamstein
I speculate that ^ is used for xor in many languages for psychological
compatibility with C, which is a very old language.

In SageMath, which uses a lightweight preparser on top of Python, I made it
automatically convert ^ to __, since otherwise mathematicians, who are used to
LaTeX, would be very confused (I remember realizing this during a tutorial at
Pycon in 2005).

------
tobr
Could someone edit the title? As it stands it could be about literally _any_
two features of JavaScript.

