I'm guessing you don't write Javascript full time? After using ES6 in depth for a few months now, I can vouch that all of these syntax details are well thought out, practical, and improve the readability and writability of the language. I've used most of the ES6 features, if not all, repeatedly in production code. None of them seen "unnecessary" and teams I've worked on echo this experience.

Who cares though, Hacker News embraces trolls who engage in syntax wars.

Hating on Javascript is one of the trendiest things to do in online tech-centric communities.

The future of Javascript is bright, and the new features added are vast improvements onto a language that stagnated far too long. Many of the criticisms towards the new features are not well thought out. Luckily the TC39 committee is full of extremely intelligent developers who have a good understanding of the nuances in adding new features.

On the other hand, there are at least some that have been coding in JS for a long time and loved the simplicity and yet versatility of the language. And there's a feeling of some of this being lost in the latest iterations of the standard. To be fair, I would rather observe this criticism in a RISC vs CISC context. (With ES6, JS is definitely taking a rather CISC-like direction.)

It's a fair point. In fact, I wrote a javascript library, http://intercoolerjs.org, to avoid writing a lot of javascript, so I have a somewhat ironic relationship with the language.

On the other hand, I also work on Gosu (http://gosu-lang.github.io/) which is has its own kitchen sink issues, so I believe I'm not being a troll, or at least not simply being a troll, when talking about language design.

Overall Javascript even with ES6 still seems like a fairly immature language. It is a definite step in the right direction though. Specifically:

I think the lambda syntax is nice and concise, although the disconnect between an implicit return with a bare statement versus required explicit return with braces is kind of silly. They should have made it just implicitly return the evaluated value of the last statement in the lambda all the time.

The de-structuring syntax is less clear and consistent than, for example, Python's. The fact that both array-like things and object-like things are de-structured using '...' means that you have to consider the context when you see it, and you could probably construct cases where it isn't clear exactly what is going on.

Template literals are obnoxious because they bind when declared. This means you can't pass a template literal around to be evaluated later. You could wrap it in quotes and use eval, but then you lose multi-line support. Pretty fail.

The fact that module support is finally part of the language is a good thing. Not having a built-in module system is probably the biggest embarrassment in the language. Now we just need a dependency manager built into the browser so people can require jQuery >= 2.0 for instance, and we won't have to worry about CDNs and what not.

Netscape 4 had dynamic HTML entities bound to JS ("&{...};"), which were resolved by the rendering engine. I think, it would have been interesting to revive this approach.

Other, one thing I often observe in ES6 examples is replacing quite complex constructs that could have been expressed much simpler using older JS standards. E.g., "Array.prototype.push.apply(arr1, arr2)", where "arr1.concat(arr2)" would have done fine. Not too sure, what this means for real-life applications, but there's definitely a trend in expressing things in artfully complex ways.

The template literal "fail" (which is really just static scoping) is necessary to make JS JITting anywhere near reasonable. You may not care about JS runtime performance, but lots of people do.

Or they could have just made template literals be multi-line strings, and added an eval method, taking an optional context object which could override local names. That would have been a lot more useful...

while i agree that everything mentioned in the article is useful, i think ES6's import is horrible. why do i have to look at (potentially outdated, esp. in js world) documentation or look at the code to know whether or not to do

  import Foo from 'bar';

or

  import { Foo } from 'bar';

I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar.

Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.

I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.

and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries

i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use

For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports.

In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.

I don't get this. I am using almost all new ES6 features and absolutely love the productivity I am getting thanks to it. To be honest JS became my favorite language. I can write mobile apps with it(react native), have unmatched user experience on web (isomorphic react), write backend server in like a minute (koa), write multiplatform games that would run even on your fridge(phaser.io), write some sci-fi like data visualizations (D3), desktop apps(electron) and the thing I like absolutely the most is ease of debugging. Whenever I tell somebody about all the things I do with js at my work place I am mocked 'coz js is shit and slow xD" usually by an experienced architect who writes enterprise level webforms-jquery applications that are the biggest mess I have ever seen. From my experience the people who very vocaly hate js are the ones who never moved past jquery and now refuse to catch up so only thing they have left is often very vague criticism like its ugly,difficult to parse,have unnecessary features, it is hard to google the features(lol)

You know what other language is a kitchen sink of unrelated and often ugly, difficult to parse and unnecessary features?

English.

We're talking about languages here. The most popular languages tend to be the ones that are the most adaptable. Successful languages aren't afraid to borrow and tend to have multiple overlapping grammars. They are not designed. They evolve over time. They are far from perfect.

The things you hate about these languages are exactly why they are so successful. Instead of being endlessly upset at the dominant programming language for not being 100% perfect, just embrace and celebrate its haphazard nature.

You're exactly right. Arguably worse than ugly, unnecessary and difficult to parse are that many of these things are difficult to research with a search engine. For example, `const { user, post } = this.props;` there is nothing to plug in to a search engine (and the meaning is not obvious, even to somebody with plenty of experience in ES5). Same thing with `arr1.push(...arr2);`.

Destructuring assignments are extremely useful, especially within function signatures.

Without knowing the type of what you're destructuring though, that's quick to land you in some type of undefined hell.

Why wouldn't you know what your destructuring?

`({ id, option = true, name = 'unnamed' }) => // ...`

replaces

``` function(userObject) {

  const id = userObject.id;

  const option = userObject.option || true;

  const name = userObject.name || 'unnamed';

  // ...

} ```

I think this comparison speaks for itself. In pre-es6 code bases you TONS of code that looks like the second.

Come off it, destructuring is hardly unique to javascript.

What syntax would you recommend/prefer for unwrapping 'props'?

This is a real problem for me these days. I see a new syntax in someone else's codebase and it is very difficult to google it.

Take a look at this site http://es6-features.org/ there is even comparison ES6 vs ES5 code. You can just go over every feature really fast a then you may get rough idea where to look next time you feel lost.

Am I the only one to think throwing "difficult to parse" as criticism to a programming language like JS is disingenuous?

It could be an argument to criticize changes proposed for a nimble performance-oriented language like Lua where "parseability" means hackability as a feature for developers working on the language & core tooling itself. But it seems to me that the bulk of the users of a popular / high-level language like JS is people trying to get things done, not tools developers hacking on JS itself.

"Difficult to parse" semantic constructs may be a hurdle for the 1% doing the parsing, but they mean more syntax goodness to help the the other 99% programmers do things pleasantly and succinctly.

I've heard Python is difficult to parse, too, but behind this difficulty there's syntax sugar helping your average developer. Much like Python list comprehensions, context managers and decorators, these ES6 features make the task harder for tool builders, but they help me as a developer.

>Am I the only one to think throwing "difficult to parse" as criticism to a programming language like JS is disingenuous? (...) "Difficult to parse" semantic constructs may be a hurdle for the 1% doing the parsing, but they mean more syntax goodness to help the the other 99% programmers do things pleasantly and succinctly.

You probably got it wrong. When he says "difficult to parse", he means for the programmers using JS -- not for people working on JS parsers.

Besides compiler construction, "parse" is also commonly used to mean "read/understand" some new code.

Oh right, thanks for pointing this out :)

In this case, I'd still contradict OP, arguing the same as stevebmark did in a sibling comment: "[...] these syntax details are well thought out, practical, and improve the readability and writability of the language [...]. None of them seen "unnecessary" and teams I've worked on echo this experience."

> Why can't we just be honest about it? "Welp, this is what we've got. We shouldn't be surprised, since this is what happens when we design by committee. Now let's make the best of it."

Lots of people are being honest, this article included. Don't disguise your different opinion as "the truth". Not everything can or should have a consensus.

Compare Reagent code with JS React code (React being about the most elegant solution possible in JS). Not only more beautiful, but much easier to understand, AND with an added performance bonus:

https://reagent-project.github.io/

Back when investigating React for a personal project, I fiddled around with Reagent as a short introduction to Clojurescript, I was not familiar with the language at all, and yet Reagent was immediately more understandable to me than React.

When an alien framework in an alien language are easier to grok than one in a familiar language, one can't call that language "beautiful" with a straight face.

ES6 is "less shitty", (maybe,) but the language itself is still a garbled mess. I can't wait for the day it goes the way of the dinosaur (or survives merely as a transpiler target).

I'm not usually one for bikeshedding. But in the case of JS, where the syntax actively hurts one's ability to understand and organize code, maybe it's warranted. Ever inherit a JS project of even moderate size? More often than not, it's a nightmare moreso than most other languages.

I think you're pretty heavily stating your own opinion as fact here. I have the opposite opinion and consider the React equivalents much easier to read than the Reagent examples you linked to, because I find the syntax more expressive.

(Also please don't tell me I don't understand the lisp-syntax due to 'familiarity', I've heard that a thousand times and it's not the case, I just don't agree with the syntax trade-off).

As much as I love ClojureScript and libraries like Om/Reagent, you're comparing apples to oranges here. React is a lower level API that other abstractions build on top of. Reagent itself is one such abstraction. Saying that Reagent is more elegant and understandable than React is akin to saying C is more elegant and understandable than assembly: An obvious truism.

A fairer comparison to Reagent would be something like Redux, which is far more elegant and understandable than low-level React code. I personally still prefer working with ClojureScript frameworks like Om/Reagent when given the choice since they have a much more robust solution for handling async tasks, but Redux doesn't fall very far behind in most other aspects.

Though I agree with most of your points, I would argue that the reason most Javascript codebases are a mess is because many people who develop in it don't have as rigorous a software engineering/computer science background. The language itself lacking built-in a module/dependency system (requiring everything to be dumped in the global namespace, maintain a tangled web of closures) is particularly egregious.

I recently witnessed the absurdity of arrow functions NOT returning implicitly if you put the function body in {}. It's a shit show.

If you want to return an object literal just do this,

`(text) => ({ label: text })`

In my opinion the arrow function has great syntax. Rest assured, no matter what the syntax was chosen to be, there would be an extremely vocal group of people who hate it (such as yourself).

That actually is one of my favorite things about arrow functions next to the no-changing-this aspect. I find CoffeeScript's optional return statement really awkward to read for anything that isn't a one-liner. I don't want to have side-effectful functions return values, and dropping bare statements in in order to accomplish that seems extra noisy.

That's part of the spec, they're really meant for doing functional style, one liner type of things, like

[1, 2, 3, 4].map(x => x + 1)

You should probably avoid using them for other applications, particularly if you're using a library that uses prototypes because it won't work.

If that's what they are for, why call them "arrow functions", and not lambdas like everybody else does?

To distinguish from javascript's other longer way of writing the same thing:

    [1, 2, 3, 4].map(function (x) { return x + 1; })

Javascript already had lambdas/anonymous functions since the beginning.