No offense meant to anyone, but I really do not like this constant stream of new features in JavaScript. There are some core issues with the language which, of course, cannot be just fixed, and no new features will make them go away. But there is also a beautiful simplicity and power in the way this (used to be) funny little language does classes, objects, scoping... I feel like these new features are bloating it, and for what? So that you can write an assignment in 1 instead of 3 lines? Wow. It's as if, whatever programming language is trendy, JavaScript must absorb as much of its features as it can...
Don't get me wrong, destructuring is a nifty feature, but it's not really necessary. Plus, things like that usually get thought through along with everything else, when the language is designed. Not only is this increasing the conceptual weight of the language (OK, maybe I exaggerate in this example ;) but there are many more features added all the time), but now you also have a new set of potential pitfalls when doing potentially type-inappropriate destructuring. (I see from the text that you sometimes get undefined, and sometimes a TypeError?) Does JS need more of that?
Why not keep it simple? It may have its flaws, but the JavaScript mental model, once you figure out some corner cases, is really simple and powerful. I find it sometimes very elegant. This feature bloat reduces that, IMO, and could hurt understandability of JS code.
I really do not like this constant stream of new features in JavaScript
ES6/Ecmascript Harmony was announced seven years back, and has been actively discussed for the last four years. So the constant stream of new features you see are JS engines implementing parts of the standard, which is now in its final shape. ES-Discuss mailing lists* are open for community participation (like someone mentioned below) and is led by people with a lot of experience in their respective focus areas. Every new feature has had to pass through many levels of debates, and have (mostly) been borrowed after being found successful either in other languages or libraries.
I feel like these new features are bloating it, and for what?
De-structuring is fairly easy to grasp, and is not even one of the main draws in ES6. Since the last changes to JS, the environment and therefore expectations have changed a lot: (a) JavaScript is now a server-side technology in a big way, (b) async has become increasingly important, (c) people are writing very complex apps in JS. Without the changes in ES6 (and ES7/8 going forward), developers would have hated working with JS and JavaScript could have slowly died.
If you have been following, you'd notice that JS has a very vibrant community around it. One big reason for that is that they see the language evolving with the technology that surrounds it. Finally, note that all the new enhancements have come without breaking backward compatibility.
* I lurk there, not a contributor. Have learnt a ton from just subscribing to it.
I do think you might be breaking the guidelines of the site - downvote should not be used just for disagreement, or? - but who cares, you're certainly not the only one ;) In any case, thank you for the explanation! I appreciate it.
As for the rest, I partly agree. I am too late to voice any constructive feedback. It was just a general comment on the direction things seem to be going. And I'd rather not participate in the es-discuss, because JavaScript is not my professional focus any more, so I do not have the time or the required expertise. I understand that my comment seems kind of like taking a passing shit on someone's hard work, I'm sorry about that. I hope everyone takes it as nothing more than what it is - just an opinion ;)
All in all, I feel the language is getting overstretched and overcomplicated. And when I see destructuring, I wonder if it's really worth it. Too much complexity can be a problem.
I did not down-vote you for disagreement, I'm firmly against that. I down-voted because it is misleading (probably unintentionally) to say JS is adding a "constant stream of new features"; rather it is all committee and consensus driven work spanning many years with many, many people participating.
I should exercise more restraint next time. Thanks for your reply.
I do think you might be breaking the guidelines of the site - downvote should not be used just for disagreement, or?
Well, it's not mentioned in the guidelines, and there's a bunch of people who do use downvote to disagree. There's a few posts from PG; one where he says that people upvote to agree so it's understandable that they downvote to disagree, and others where he sees it as a problem to be addressed.
It's probably a good idea for people to upvote any posts they think have been unfairly downvoted. This sometimes happens, but probably not often enough.
1. a downvote button, which is available to everyone, but affects only the ranking on the comment list (no graying out due to too many downvotes)
2. a "flag" button, which is available to people with higher karma and serves for moderating.
...because, it seems perfectly human to want to express disagreement with a downvote. I can totally get it, and would/will probably have a hard time restraining myself ^^
ES6 may make the language itself more complex, but I would argue that it does make your code simpler and more concise. Destructuring and arrow functions may seem gimmicks, but they do reduce the visual complexity of the source code and allow you to concentrate on more important things.
And stuff like the module system, class system, promises etc. really needed to be standardized because there were too many different solutions floating around and the fragmentation was hurting the ecosystem.
Personally, I think that ES6 is much more usable than any previous version of JavaScript.
So don't use the new features. Nobody is forcing you. Over time, perhaps you will come to appreciate some and bring them into your code. Or perhaps not, both are fine.
Of course, the corollary is to point out that nor should you force your approach on others. Your usage of the language is not the same as everybody else's. They might be working in different contexts to you, solving different kinds of problems to you, with different constraints.
I'd also recommend subscribing to es-discuss. All the features are discussed heavily and repeatedly by experienced, clever people in an open forum, before being standardised and implemented. Only battle-hardened ideas, usually proven in other languages or in JS libraries, make it through the process. There's solid reasoning behind all of them.
I'd like to just clarify one thing - of course everyone can ignore the new features when writing their code, but no one can ignore them when reading other people's code. Undoubtedly, a JS programmer must get a handle on them all, sooner or later.
Thanks for the es-discuss suggestion, it's cool that the process is open like that.
Understanding other people's code is never easy and I get that new language features make it seem even more daunting.
But it is always a useful process to go through, more so when it exposes you to new ideas, patterns and idioms. These features seem intimidating because they are unfamiliar to you, but they won't be unfamiliar forever. I guarantee it.
Wow, that was pretty patronizing! But I think I made a certain argument. You don't have to agree, but it would be nice if you don't just blame it all on my supposed unwillingness to learn new stuff ;)
No, but as someone who doesn't write JavaScript at all, I would like the JS engine that comes with a graphical web browser to be simpler than the expanding spec makes possible. I mostly browse with Lynx anyways, but there's a legitimate concern about how much browser developers are being expected to support here, and what the implications of that are.
Considering the additional syntax is sugar over stuff that is already possible, I'm not sure how much I agree... Anything newer than IE8 can run the transpiled ES5 code that BabelJS/Traceur and others pump out.
I agree with that. All these features are amazing, but the fact that these modification must be only additive make their implementation feel clunky.
Javascript was born with enormous defects that it's too late to remove, and adding new features, regardless of their undoubtable usefulness, make the whole language more difficult to handle. The number of concepts required to read ES6 is far more than the one required for ES5, and this number is just destined to get higher and higher, with no possibility to decrease.
I hear this type of argument a lot... regarding "Javascript was born with enormous defects..." would you mind citing some defects that aren't possible to simply ignore in practice?
I know that Automatic Semicolon Insertion, Hoisting, Scopes and mostly automatic type casting are brought up a lot...
Regarding ASE (use a linter, and always require them)
For Hoisting it's a matter of learning the language and isn't any different than many other languages in that regard.
As to functional closures/scoping... the new "let" allows you to move away from that in practice
For automatic type inferrence/casting... I think this is absolutely one of the more powerful features of JS, and allows for validating end-user input to be far more easy/flexible than most other systems that would presume to convert user input to a date, or a number, etc. This is my own opinion, but I've seen few better systems and JS doesn't require you to load up a bunch of try/catch blocks to do it.
I bring these up, because I don't think they are defects in the language, except maybe the only closures being at the function level, and related to this being able to use undeclared variables, both of which are addressed in practice by newer features.
Old features can be abandoned and forgotten. For instance, I don't even know what "with" does anymore. We don't want a python 3 situation on our hands.
First, what "constant stream of new features"? Over the past 20 years it's been a fairly stagnant language.
Second, stagnation is not a good thing. I make my living writing Javascript, and being able to write ES6 instead of ES5 makes me happier and more productive. That's not a minor benefit; that's literally the most important thing you can say about a language update. And thanks to babel, it doesn't even break backwards compatability. What possible drawback is there?
Yes, this is ruining the "funny little language" you liked, but if you want a funny toy language, go use Elm or Elixir or something. Javascript is too important to be a hipster playground.
A little meta - where can I find some written guidelines for HN commenting? It was my understanding that downvotes serve for moderating (their cumulative effect is to gray out a comment...). The comment above has been downvoted somewhat, and if that continues it could get grayed out, as if it were spam or trolling. Is it really?
I guess it's like C++. You can use the new features if you want, you don't really have to. Some teams will decide on a subset of "safe" features of the language to use. I'm waiting for something like JavaScript the Good Parts II to come out and give an indication of what I should probably avoid.
Comments
No offense meant to anyone, but I really do not like this constant stream of new features in JavaScript. There are some core issues with the language which, of course, cannot be just fixed, and no new features will make them go away. But there is also a beautiful simplicity and power in the way this (used to be) funny little language does classes, objects, scoping... I feel like these new features are bloating it, and for what? So that you can write an assignment in 1 instead of 3 lines? Wow. It's as if, whatever programming language is trendy, JavaScript must absorb as much of its features as it can...
Don't get me wrong, destructuring is a nifty feature, but it's not really necessary. Plus, things like that usually get thought through along with everything else, when the language is designed. Not only is this increasing the conceptual weight of the language (OK, maybe I exaggerate in this example ;) but there are many more features added all the time), but now you also have a new set of potential pitfalls when doing potentially type-inappropriate destructuring. (I see from the text that you sometimes get undefined, and sometimes a TypeError?) Does JS need more of that?
Why not keep it simple? It may have its flaws, but the JavaScript mental model, once you figure out some corner cases, is really simple and powerful. I find it sometimes very elegant. This feature bloat reduces that, IMO, and could hurt understandability of JS code.
I down voted you, I owe you an explanation.
ES6/Ecmascript Harmony was announced seven years back, and has been actively discussed for the last four years. So the constant stream of new features you see are JS engines implementing parts of the standard, which is now in its final shape. ES-Discuss mailing lists* are open for community participation (like someone mentioned below) and is led by people with a lot of experience in their respective focus areas. Every new feature has had to pass through many levels of debates, and have (mostly) been borrowed after being found successful either in other languages or libraries.
De-structuring is fairly easy to grasp, and is not even one of the main draws in ES6. Since the last changes to JS, the environment and therefore expectations have changed a lot: (a) JavaScript is now a server-side technology in a big way, (b) async has become increasingly important, (c) people are writing very complex apps in JS. Without the changes in ES6 (and ES7/8 going forward), developers would have hated working with JS and JavaScript could have slowly died.
If you have been following, you'd notice that JS has a very vibrant community around it. One big reason for that is that they see the language evolving with the technology that surrounds it. Finally, note that all the new enhancements have come without breaking backward compatibility.
* I lurk there, not a contributor. Have learnt a ton from just subscribing to it.
I do think you might be breaking the guidelines of the site - downvote should not be used just for disagreement, or? - but who cares, you're certainly not the only one ;) In any case, thank you for the explanation! I appreciate it.
As for the rest, I partly agree. I am too late to voice any constructive feedback. It was just a general comment on the direction things seem to be going. And I'd rather not participate in the es-discuss, because JavaScript is not my professional focus any more, so I do not have the time or the required expertise. I understand that my comment seems kind of like taking a passing shit on someone's hard work, I'm sorry about that. I hope everyone takes it as nothing more than what it is - just an opinion ;)
All in all, I feel the language is getting overstretched and overcomplicated. And when I see destructuring, I wonder if it's really worth it. Too much complexity can be a problem.
I did not down-vote you for disagreement, I'm firmly against that. I down-voted because it is misleading (probably unintentionally) to say JS is adding a "constant stream of new features"; rather it is all committee and consensus driven work spanning many years with many, many people participating.
I should exercise more restraint next time. Thanks for your reply.
Well, it's not mentioned in the guidelines, and there's a bunch of people who do use downvote to disagree. There's a few posts from PG; one where he says that people upvote to agree so it's understandable that they downvote to disagree, and others where he sees it as a problem to be addressed.
It's probably a good idea for people to upvote any posts they think have been unfairly downvoted. This sometimes happens, but probably not often enough.
Maybe downvotes could be split in two.
1. a downvote button, which is available to everyone, but affects only the ranking on the comment list (no graying out due to too many downvotes)
2. a "flag" button, which is available to people with higher karma and serves for moderating.
...because, it seems perfectly human to want to express disagreement with a downvote. I can totally get it, and would/will probably have a hard time restraining myself ^^
Doesn't string interpolation break from ES5?
"${foo}" means something different in 6 vs 5, right?
Template strings (https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...) use backticks, instead of double/single quotes.
I stand corrected. Thanks.
ES6 may make the language itself more complex, but I would argue that it does make your code simpler and more concise. Destructuring and arrow functions may seem gimmicks, but they do reduce the visual complexity of the source code and allow you to concentrate on more important things.
And stuff like the module system, class system, promises etc. really needed to be standardized because there were too many different solutions floating around and the fragmentation was hurting the ecosystem.
Personally, I think that ES6 is much more usable than any previous version of JavaScript.
So don't use the new features. Nobody is forcing you. Over time, perhaps you will come to appreciate some and bring them into your code. Or perhaps not, both are fine.
Of course, the corollary is to point out that nor should you force your approach on others. Your usage of the language is not the same as everybody else's. They might be working in different contexts to you, solving different kinds of problems to you, with different constraints.
I'd also recommend subscribing to es-discuss. All the features are discussed heavily and repeatedly by experienced, clever people in an open forum, before being standardised and implemented. Only battle-hardened ideas, usually proven in other languages or in JS libraries, make it through the process. There's solid reasoning behind all of them.
I'd like to just clarify one thing - of course everyone can ignore the new features when writing their code, but no one can ignore them when reading other people's code. Undoubtedly, a JS programmer must get a handle on them all, sooner or later.
Thanks for the es-discuss suggestion, it's cool that the process is open like that.
Understanding other people's code is never easy and I get that new language features make it seem even more daunting.
But it is always a useful process to go through, more so when it exposes you to new ideas, patterns and idioms. These features seem intimidating because they are unfamiliar to you, but they won't be unfamiliar forever. I guarantee it.
Wow, that was pretty patronizing! But I think I made a certain argument. You don't have to agree, but it would be nice if you don't just blame it all on my supposed unwillingness to learn new stuff ;)
No, but as someone who doesn't write JavaScript at all, I would like the JS engine that comes with a graphical web browser to be simpler than the expanding spec makes possible. I mostly browse with Lynx anyways, but there's a legitimate concern about how much browser developers are being expected to support here, and what the implications of that are.
Considering the additional syntax is sugar over stuff that is already possible, I'm not sure how much I agree... Anything newer than IE8 can run the transpiled ES5 code that BabelJS/Traceur and others pump out.
I agree with that. All these features are amazing, but the fact that these modification must be only additive make their implementation feel clunky.
Javascript was born with enormous defects that it's too late to remove, and adding new features, regardless of their undoubtable usefulness, make the whole language more difficult to handle. The number of concepts required to read ES6 is far more than the one required for ES5, and this number is just destined to get higher and higher, with no possibility to decrease.
I hear this type of argument a lot... regarding "Javascript was born with enormous defects..." would you mind citing some defects that aren't possible to simply ignore in practice?
I know that Automatic Semicolon Insertion, Hoisting, Scopes and mostly automatic type casting are brought up a lot...
Regarding ASE (use a linter, and always require them)
For Hoisting it's a matter of learning the language and isn't any different than many other languages in that regard.
As to functional closures/scoping... the new "let" allows you to move away from that in practice
For automatic type inferrence/casting... I think this is absolutely one of the more powerful features of JS, and allows for validating end-user input to be far more easy/flexible than most other systems that would presume to convert user input to a date, or a number, etc. This is my own opinion, but I've seen few better systems and JS doesn't require you to load up a bunch of try/catch blocks to do it.
I bring these up, because I don't think they are defects in the language, except maybe the only closures being at the function level, and related to this being able to use undeclared variables, both of which are addressed in practice by newer features.
Old features can be abandoned and forgotten. For instance, I don't even know what "with" does anymore. We don't want a python 3 situation on our hands.
First, what "constant stream of new features"? Over the past 20 years it's been a fairly stagnant language.
Second, stagnation is not a good thing. I make my living writing Javascript, and being able to write ES6 instead of ES5 makes me happier and more productive. That's not a minor benefit; that's literally the most important thing you can say about a language update. And thanks to babel, it doesn't even break backwards compatability. What possible drawback is there?
Yes, this is ruining the "funny little language" you liked, but if you want a funny toy language, go use Elm or Elixir or something. Javascript is too important to be a hipster playground.
A little meta - where can I find some written guidelines for HN commenting? It was my understanding that downvotes serve for moderating (their cumulative effect is to gray out a comment...). The comment above has been downvoted somewhat, and if that continues it could get grayed out, as if it were spam or trolling. Is it really?
I guess it's like C++. You can use the new features if you want, you don't really have to. Some teams will decide on a subset of "safe" features of the language to use. I'm waiting for something like JavaScript the Good Parts II to come out and give an indication of what I should probably avoid.
I really, really, really hope that JavaScript doesn't become like C++...
That's really funny :) I was looking at the rest of these in depth articles and this one jumped to mind as a C++'y feel to how it was implemented: https://hacks.mozilla.org/2015/04/es6-in-depth-iterators-and...
Strict backwards compatibility forcing new syntax and ugly conventions.