
Top ES6 features by example - foob
https://blog.pragmatists.com/top-10-es6-features-by-example-80ac878794bb
======
tejohnso
"Who doesn’t like explicit inheritance, like in Java language, instead of
writing magic code for prototypal inheritance?"

There's nothing magical about prototypal inheritance code, and I'd suggest the
class keyword is more magical since it's "primarily syntactical sugar over
JavaScript's existing prototype-based inheritance" [1]. Furthermore,
encouraging classical inheritance constructs without mentioning the classic
pitfalls is somewhat harmful [2].

[1] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Classes)

[2] [https://medium.com/javascript-scene/javascript-factory-
funct...](https://medium.com/javascript-scene/javascript-factory-functions-vs-
constructor-functions-vs-classes-2f22ceddf33e)

~~~
Raphmedia
I never understood the whole confusion about prototypal inheritance. It's not
harder to grok than classical inheritance.

"Which Java developer doesn’t miss classes when switching to a JS project?"
... That's the biggest problem here. Java != JavaScript. You shouldn't blindly
carry concepts from one language to the other.

Adding syntactic sugar with the only goal of pleasing developers coming from
other language goes against my view of what features should be added to a
language. That's code bloat.

~~~
masklinn
> I never understood the whole confusion about prototypal inheritance. It's
> not harder to grok than classical inheritance.

In theory no, but Javascript has such bad support for it that it's
syntactically inconvenient and you have to understanding significantly more
details of the implementation to manage it than just "you add the other class
after the extends".

------
haffla
What? The mentioned Array methods (map, reduce, filter, etc..) are not new ES6
features

~~~
ricemast
Nowhere does it say "new" features.

~~~
haffla
"New cool helper functions appeared..."

------
masklinn
The article is not very good, with both factual mistakes and missing important
sub-properties

> 2\. Array helper functions

`map`, `filter`, `reduce`, `some` and `every` were actually added in ES5.1.
Only `find` and the unlisted `findIndex` come from ES6.

Meanwhile Array.from which _was_ added in ES6 goes unlisted.

> 3\. Arrow functions

While the reduction in definition boilerplate is great, missing is the very
important (and convenient!) fact that arrow functions resolve `this` lexically
(as a normal variable rather than a special case).

> 4\. Classes

Would have benefited from mentioning the most convenient feature of classes by
far: the `super` proxy to calling a method of the superclass on `this` (most
useful with constructors): the ES5

    
    
        <Superclass>.prototype.aMethod.call(this)
    

becomes:

    
    
        super.aMethod()
    

which also helps a lot when moving methods around.

> 6\. Template strings

Missing: you can "tag" template strings to invoke user-defined functions on
the contents and do intermediate processing and interpolation yourself e.g.

    
    
        sql`foo ${bar}`
    

will invoke `sql(['foo ', ''], <value of bar>)`.

> 7\. Default function arguments

Missing note: unlike e.g. Python, default arguments are dynamic and sequential
(similar to let<star>[0]) so you can define a `function foo(a, b=a)`.

> 8\. Rest and spread operators

Actually the opposite for once, mentions that rest and spread operators can be
used with object content, sadly that's currently a stage3 proposal, definitely
not part of ES6.

> 9\. Destructing

Missing notes:

* the destructuring is recursive (you're not limited to a single level)

* you don't _have_ to "[assign values] to variables _of the same name_ as properties" when destructuring objects:
    
    
        let {name: a} = a_call();
    
      will bind the value of the property "name" to the "a" local variable.
    

* you can provide default values to the destructuring pattern e.g.
    
    
        let [a, b=3] = [1]
    
      this can be combined with renaming for object destructuring
    

[0] [http://docs.racket-
lang.org/reference/let.html#%28form._%28%...](http://docs.racket-
lang.org/reference/let.html#%28form._%28%28lib._racket%2Fprivate%2Fletstx-
scheme..rkt%29._let%2A%29%29) can't use an actual star there because HN
comment formatting remains a complete trash fire and thus decides to emphasize
half my comment and swallow the mark of the first list item. And still does
not print let∗.

~~~
cbaleanu
Bad article, the author should have indeed put some more time into
understanding what he is writing about.

    
    
      var firstTeenager = people.find(teenager)
    

Stuff like this, when you write about ES6 features but use var makes my eyes
hurt :(

~~~
baron816
I agree that the article needs some work, but there really is nothing wrong
with still using var. I'm in the Kyle Simpson camp and just use var for
everything except if I'm actually creating a constant or block scoping comes
into play or I need to prevent the hoisting of a variable. That way, it's
clear what I'm doing and what my intentions are.

~~~
masklinn
> That way, it's clear what I'm doing and what my intentions are.

It's the exact opposite since you're defaulting to the most permissive binding
style.

Defaulting to `const` would actually make it clear what your intent is: you
use `let` if you need mutable bindings and you use `var` if you need hoisting.

If you default to `var` your intent is apparently to make use of mutable
bindings and hoisting everywhere, at which point I can only expect that you
put your variable declarations at the bottom of your function blocks after the
`return` statement.

~~~
baron816
Defaulting to const does nothing. If you or someone else decides later that it
should be reassignable, then they'll change it and not think about it. If
const is rare in your code, people will be aware of what const means in that
context.

If you're putting your variable declarations after your return statement, then
you probably have other problems. I also don't know why you would ever expect
someone to do that.

~~~
masklinn
> Defaulting to const does nothing. If you or someone else decides later that
> it should be reassignable, then they'll change it and not think about it.

Which they'll do regardless. `const` is an indication that the binding is not
updated in the rest of the scope and thus that said scope can be perused
without needing to consider an update to the binding itself. It is a guarantee
of SSA, nothing more and nothing less.

> If const is rare in your code, people will be aware of what const means in
> that context.

The same as above which you apparently assert is "nothing"?

> If you're putting your variable declarations after your return statement

Why would _I_ do that? I'm not adamantly using `var` when I have no reason to.

~~~
baron816
If everything is a constant then nothing is a constant.

Code bases change and some things that a coder did not foresee needing to be
reassignable may later need to be reassignable. There aren't frequent cases
that switching them becomes a problem, and as a result, people switch them.
Since they do get switched so often, people stop thinking about when it really
matters or if there was some intent to it originally being written that way.
If everything is a constant, then the cases where it matters and the cases
where it doesn't get blended together and it's impossible to differentiate the
two.

When real, true constants are the only things declared with const, then it's
abundantly clear what the intention of the coder was and that the value should
never be changed nor should it ever be switched over to let/var.

Likewise with let, in the few cases where it's used it draws others' attention
to the use of block scoping or the avoidance of hoisting. It's rare that those
things really come into play, so the few cases where it's present really stand
out.

tl;dr Block scoping and constants are the exception, not the DEFAULT, so you
should write code accordingly.

> If you're putting your variable declarations after your return statement

What I meant here is that people shouldn't keep using var just so they can
continue writing bad code.

~~~
masklinn
> There aren't frequent cases […] Since they do get switched so often

They don't. In fact they almost never do.

> tl;dr Block scoping and constants are the exception

That's literally the opposite of reality. Constant bindings (single-
assignment) and block-scoped bindings are by far the most common state of
affairs even if not formally stated.

> What I meant here is that people shouldn't keep using var just so they can
> continue writing bad code.

Maybe you should tell the you of two comments ago who's apparently arguing for
exactly that?

~~~
baron816
What's with the hostility? I'm just trying to express my opinion. You can
disagree and state your point without being insulting.

Sure, when I say frequent, I don't mean its happening all the time all over
the place, I just means it can and does happen without consequence. Block
scoping and constants, in the sense that it's important that they're block
scoped and constant, are the exception. Most variables are single-assignment
not out of necessity. And I bet most people think in function scope,
regardless of how the compiler works.

It all still comes down to intent. If you're always defaulting to using const,
your intention is not really showing through.

~~~
abritinthebay
As an outside observer I have to say that _they_ are not the one who came off
as hostile.

------
fortythirteen
With such lagging browser support forcing you to compile ES6, it generally
makes more sense to jump to TypeScript. You get all the E56 plus things like
interfaces and enums and, of course, strict typing.

~~~
cloakandswagger
Strict typing isn't always desirable, depending on the application of the
language. With it you give up a certain level of developer productivity;
appropriate if you're using Javascript for backend logic with Node, not so
much if you're building simple views with React.

~~~
slackingoff2018
I don't think so, or at least it doesn't feel like it. Typescript's type
inference is so good that you only need types maybe 15% of the time. It also
has shortcuts like constructor property initializers and support for async
even when targeting ES5.

I would bet money that you actually write less code with Typescript than
regular javascript because of all the streamlining and shortcuts. And with the
type inference you almost get static typing for free.

I hear this argument come up frequently against TS and all I can say is I'm
fairly sure it's from people that haven't used it.

~~~
fearface
Sometimes it's also from people who use JavaScript in a more functional
context, e.g. with currying. Suddenly it requires a lot of effort to still
have TypeScripts benefits.
[https://gist.github.com/donnut/fd56232da58d25ceecf1](https://gist.github.com/donnut/fd56232da58d25ceecf1)

~~~
tomelders
I've been working with Typescript for the past six months. Javascript is
starting to shine as a functional programming language, and the communities
who develop the useful tools that we actually need are moving in that
direction too.

Typescript feels like a step in a completely different direction. The problems
that TS tries to solve have other solutions. Solutions more idiomatic to
javascript development. Redux style architectures, grouping code by feature,
libraries over frameworks, GraphQL and so on. And these solutions are solid
and dependable. Unlike the made up brittle and often incorrectly defined types
that Typescript and Flow demand. If you want to use Typescript, then I hope
you really really REALLY like Generics, because they're absolutely everywhere
in Typescript. They're the solution to the fundamental flaw with TypeScirpt,
it wasn't designed with the actual job that Javascript does in mind.

It's Javascript for people who don't like Javascript and don't care to learn
it. Well that's fine, each to their own. But people sing it's virtues without
pointing out any of the flaws in both the approach or the implementation
(maybe because they simply don't see anything wrong), and that really rustles
my jimmies.

~~~
abritinthebay
It absolutely is a step in a different direction.

Not a bad one, but very _intentionally_ different.

I personally prefer a style/practice that doesn’t work well with TS, but I
appreciate it exists and typedef files for libraries are very nice for
developing in things like VSCode.

------
lozzo
Many comments are saying that the article is not good as it is not accurate.
(e.g. @masklinn) I agree. The author could have spent a bit of time
reasarching this since bullet-point-articles are probably the easiest to write
down.

However, it's interesting (yet sad) how its catchy title "Top ES6 features by
example" is making darn popular.

~~~
sotojuan
The current "GitHub/your blog is your resume!!" movement has led to people who
have little business writing didactic resources (not because of programming
skill, but lack of research, teaching experience, and writing abilities) to do
so in hordes.

It's hard to complain without sounding like a jerk because these are free to
read, but they can waste people's time or confuse them.

------
3minus1
Quite a bit of negativity in the comments here. I liked the article. Typically
I rely on code samples in articles like this, but I found the paragraph
descriptions very readable.

------
bernadus_edwin
This is very helpfull. I never know that js has linq. Very similliar. Also
using lambda. Just rename select keyword to map keyword

------
VMG
Is there a good description somewhere of how to use new methods like
Object.freeze, Object.defineProperty etc?

~~~
Axnyff
These are not new ES6 features. I think you can get a really good explanation
from the you don't know js serie.

[https://github.com/getify/You-Dont-Know-
JS/blob/master/this%...](https://github.com/getify/You-Dont-Know-
JS/blob/master/this%20%26%20object%20prototypes/ch3.md)

The whole serie of book is worth it and free to read on github

~~~
VeejayRampay
Object.defineProperty is actually quite ancient yeah.

------
pascalxus
Excellent post. Just the right amount of information to get the point across.

------
gruez
This website is shit on mobile with its fixed top bar taking up 20% of the
screen space.

~~~
tazard
Ironically, without JavaScript, it works fine for me on mobile.

