7 ms·

No, it isn't. It's a kitchen sink of unrelated and often ugly, difficult to parse and unnecessary features. Yes, there is some good in there, but overall it's

No, it isn't. It's a kitchen sink of unrelated and often ugly, difficult to parse and unnecessary features. Yes, there is some good in there, but overall it's a shit show. 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."

serpix 11y ago
I recently witnessed the absurdity of arrow functions NOT returning implicitly if you put the function body in {}. It's a shit show.
- rimunroe 11y ago
  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.
- btdiehr 11y ago
  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).
- rhinoceraptor 11y ago
  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.
  - douche 11y ago
    If that's what they are for, why call them "arrow functions", and not lambdas like everybody else does?
    - rhinoceraptor 11y ago
      Javascript already had lambdas/anonymous functions since the beginning.
    - TheCoelacanth 11y ago
      To distinguish from javascript's other longer way of writing the same thing: [1, 2, 3, 4].map(function (x) { return x + 1; })
jbergknoff 11y ago
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);`.
- bengale 11y ago
  Come off it, destructuring is hardly unique to javascript.
- btdiehr 11y ago
  Destructuring assignments are extremely useful, especially within function signatures.
  - th0br0 11y ago
    Without knowing the type of what you're destructuring though, that's quick to land you in some type of undefined hell.
    - btdiehr 11y ago
      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.
- nly 11y ago
  What syntax would you recommend/prefer for unwrapping 'props'?
- dandare 11y ago
  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.
stevebmark 11y ago
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.
- btdiehr 11y ago
  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.
  - masswerk 11y ago
    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.)
- CuriouslyC 11y ago
  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.
atonparker 11y ago
> 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.
ronjouch 11y ago
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.
- coldtea 11y ago
  >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.
  - ronjouch 11y ago
    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."
noam87 11y ago
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/ 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.
- CuriouslyC 11y ago
  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.
- nilliams 11y ago
  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).
- lewisl9029 11y ago
  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.
williamcotton 11y ago
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.
Keepo 11y ago
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)

serpix 11y ago

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

rimunroe 11y ago
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.
btdiehr 11y ago
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).
rhinoceraptor 11y ago
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.
- douche 11y ago
  If that's what they are for, why call them "arrow functions", and not lambdas like everybody else does?
  - rhinoceraptor 11y ago
    Javascript already had lambdas/anonymous functions since the beginning.
  - TheCoelacanth 11y ago
    To distinguish from javascript's other longer way of writing the same thing: [1, 2, 3, 4].map(function (x) { return x + 1; })

jbergknoff 11y ago

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);`.

bengale 11y ago
Come off it, destructuring is hardly unique to javascript.
btdiehr 11y ago
Destructuring assignments are extremely useful, especially within function signatures.
- th0br0 11y ago
  Without knowing the type of what you're destructuring though, that's quick to land you in some type of undefined hell.
  - btdiehr 11y ago
    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.
nly 11y ago
What syntax would you recommend/prefer for unwrapping 'props'?
dandare 11y ago
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.

stevebmark 11y ago

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.

btdiehr 11y ago
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.
- masswerk 11y ago
  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.)
CuriouslyC 11y ago
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.

atonparker 11y ago

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

ronjouch 11y ago

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.

coldtea 11y ago
>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.
- ronjouch 11y ago
  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."

noam87 11y ago

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

CuriouslyC 11y ago
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.
nilliams 11y ago
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).
lewisl9029 11y ago
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.

williamcotton 11y ago

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.

Keepo 11y ago

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)