13 ms·
ES6: The features I'm most excited about
- nodesocket 11y agoI was just talking to my friend who works at NetFlix on the frontend team about ES6, he is most excited about destructuring `let { name, age, gender } = user;`. I however advocate that the new class syntax is the best part of ES6. Take the following trivial OOP example, which I think reads so much easier a lot like PHP. "use strict"; class Vehicle { constructor(name) { this.kind = 'Vehicle'; this.name = name; } printName() { console.log(this.name); } } class Car extends Vehicle { constructor(name) { super(name); //call the parent method with super this.kind = 'Car'; } } let myCar = new Vehicle('Mercedes'); console.log(myCar);
- mkozlows 11y agoI think it's fair to say that people who want to write object-oriented Javascript are very excited by class. Those of us who have found that the non-OO nature of Javascript is part of what makes it so productive are... much less excited.
- TazeTSchnitzel 11y ago`class` trades the flexibility of prototypes for the familiarity of other languages. :(
- domenicd 11y agoThis is just false. `class` is sugar over prototypes. Nothing is lost.
- TazeTSchnitzel 11y agoYes, it is just "sugar", but it cements one way of doing things.
- jonpress 11y agoJavaScript is object oriented just like any other language. The difference is that it is prototype-based OO instead of class-based OO. I would say that JavaScript's OO is actually more powerful/flexible than other languages but it is less readable and more error prone if you're not careful - For example, the fact that objects can 'borrow' a method from other object an apply it to themselves is a common source of issues for beginners.
- smt88 11y agoIt's possible to get power without flexibility. Flexibility is bad -- it creates code that is idiomatic to the person who wrote it. Rust and Go are so exciting because they've intentionally rejected flexibility without compromising power.
- tragic 11y agoFlexibility is not 'bad' - it's a tradeoff. More flexible languages are better for writing DSLs, etc; but using them means a lot of self discipline regarding code style. One thing I wish JS had is a PEP8-style canonical style document. I would find that more useful than classes. On classes, I am among the less excited about them; however, we are in a ridiculous situation where there are about 500 different library implementations of class inheritance. Backbone has one. Ember has one. Node has util.inherits. Various transpile-to-JS languages (CS, TS) all have their own slightly-different implementations of the resulting prototype code. There is plainly a need for classes in JS, felt by some of the leading projects in JS land. ES6 classes at least gives all these disparate implementations a refactoring target. How many of them will get there is another matter.
- smt88 11y ago> using them means a lot of self discipline regarding code style. That's bad. Few developers have self-discipline. The ones who do still have different rules than you do. That makes reading, understanding, and modifying their code harder. Sounds bad, doesn't it? There's a reason the most experienced devs rage against extremely flexible languages like PHP and JavaScript and are excited about new, ultra-rigid languages.
- deleted 11y ago[deleted]
- akilism 11y agoyep. personally I've taken a much more functional approach to my javascript development that barely relies on oop.
- phoenixmatrix 11y agoYup. The class keyword is a huge step backward, and it was only put it because of a very different world several years ago when all this was put into motion. It is just a wrapper around prototypal inheritance, but hides a lot of the features in favor of making things look like other OOP languages, even though it isn't. It is also very debatable if classic OOP is even good at all. JS was heading in the right direction, with more functional approaches, factory based object creation, etc... and now it's all back to square one. Fortunately I work on a product where most devs have functional programming backgrounds, so the argument isn't too hard to make. But I fear for the community in general.
- thwarted 11y agoWhy can all this new syntax be added, but the "use strict" pragma is still specified by a string? It made sense to send messages to the interpreter in a backwards compatible way, but now it just seems odd.
- nodesocket 11y agoNot entirely sure if browsers require "use strict;", but io.js (node) does.
- silverwind 11y agoIn iojs/node, you can force v8 strict mode through the --use_strict flag, saving you from writing in every file.
- v413 11y agoAll code in modules is in the context of "use strict" by default so it won't be necessary to use this pragma explicitly.
- Kiro 11y ago> he is most excited about destructuring `let { name, age, gender } = user;`. Why is this a big deal? Seems pretty trivial.
- robinson7d 11y agoOne of the reasons that it's a big deal is because of what it means for functions. It helps make named-parameters more attractive, which can help a lot with code maintainability. Example code: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Function_argument_defaults https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Additionally, it's nice sugar for module loading, for modules that export multiple values.
- akilism 11y agoI'm with him, I'm pretty excited about destructing coming to JS. If it's half as powerful as it is in clojure it'll be great.
- akst 11y agoMy favourite feature is promises, while it doesn't add a new syntax and you can probably add a library for it, the fact it's standardised makes a world of difference. Now that it's standardised 1. It will become the common interface for deferred operations and library authors can make assumptions that it's there. 2. ES7 Async/Await will be able to leverage this common interface.
- mkozlows 11y agoMy problem with promises is that delivering it without async/await is just awkward. Because, yes, in the ES7 async/await world, you're going to want to use promises heavily because they'll work so great with that. But in the ES6 world, making your API promise-based makes it heavier-feeling and more awkward than simple, clean callbacks. (Which get an unnecessarily bad rap from people who don't work primarily in JS; there are cases when callbacks get awkward, but just looking at code that's four levels of indent deep and declaring it "callback hell" -- as you so frequently see -- is a super-shallow analysis. That code is clean and easy to understand, as often as not.)
- tracker1 11y agoFor the near term, you have to use something like babel anyway. Beyond that, generators and promises need to be implemented ahead of async/await as they are prerequisites for it.
- dpweb 11y agoPromises I find rather ugly to read. So far Im liking arrow functions and template strings. Async/await I'm looking forward to in ES7.
- savanaly 11y agoWhat exactly did you have in mind other than "new Promise()" to create a promise?
- iamstef 11y agoits not creating a promise that is the problem, its consuming. Async/await really is a nice sugar, check it out when you have a chance.
- striking 11y agonew Promise(function(resolve, reject){ /* code */ }) it's a little much
- tlarkworthy 11y agoIdeally, if you're writing business logic, you shouldn't be creating promises but consuming/combining/chaining them from libraries.
- taternuts 11y agoWhat would make you say that? Why wouldn't you use promises in your business logic?
- DCoder 11y agoThe idea isn't "don't use promises", it's more "use/chain the promises you already got from libraries (e.g. AJAX calls), don't construct new promises yourself". See the StackOverflow question inglor linked to: https://stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it https://stackoverflow.com/questions/23803743/what-is-the-exp...
- pipeep 11y agoEven better: The arrow function example used the statement form of an arrow function, instead of the expression form, which allows you to omit the return: // using arrow var adder = { num: 2, nums: [1,2,3,4,5], addIt() { return this.nums.map(n => this.num + n) } }; console.log(adder.addIt()); // [3, 4, 5, 6, 7] I'll concede that the arrow function is a bit overly complicated, with this, sometimes-optional argument list parenthesis, and object literal/function body syntax ambiguity.
- ecaron 11y agoWow. I can't believe template strings (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) aren't in this list. I'm incredibly excited to start having those at my disposal.
- zhodge 11y agoHm, at first glance I am as well, especially with tagged template strings. Those look particularly simple but powerful. Generally though, is it reasonable for features such as these to be included at the language level? I primarily use ES5 JavaScript so I'm used to pulling in a decent amount of modules (in this case handlebars, underscore, etc.) for things like templating. But I will be relieved to have a language-standard solution to what feels like such a common problem for the environments in which JS is used primarily, despite the tradeoff that's made in accessibility due to feature bloat.
- madeofpalk 11y ago> for things like templating. I'm excited for not having external libraries to handle string interpolation.
- abecedarius 11y agoYes, for at least two reasons: Unsafe string-munging is too easy and seductive. Doing things the safe/secure way needs to be at least as easy. And it makes for a growable language, the way Lisp macros do. E.g. https://github.com/erights/quasiParserGenerator https://github.com/erights/quasiParserGenerator This can reduce the demand for feature bloat in future language standards.
- mattmanser 11y agoMost modern languages already have this feature, JavaScript's the strange one to not have a quick way of putting variables into a string and the first to have to name it though because it was missing it for so long. And by your comment have evidentally chosen a confusing name. This isn't to replace templating engines. Admittedly you could trivially extend the string prototype to have something more akin to string.format or printf, which was something you couldn't do in other languages for a long time, making it less of a problem.
- andyl 11y agoI've used ES6 and prefer coffeescript - IMHO more concise, easier to read, and has been place for years.
- jessaustin 11y agoYup. It's as if coffeescript was created by one person (and a bunch of great PRs!), while ES6 came out of a committee.
- skuunk1 11y agoThat's exactly what I like about ES6 (the fact that it has come out of a committee and is now a standard).
- honest_joe 11y agoWhat the hell ?
- woah 11y agoDo you not like standardized technology?
- honest_joe 11y agoI do but not at the cost of productivity.
- jessaustin 11y agoLeaving aside the committee preference, what value do you perceive in the fact that it's a standard? It can't be that browsers support it, because they don't. Sure Mozilla will probably get there within the next several years, and Chrome won't be too far behind, but forget about Safari and IE. So you'll still have to use Babel or something like it. Please note, there's nothing wrong with requiring a tool chain, which we already need anyway for minimization, compression, cdns, etc. But once we realize that, we realize that coffeescript is just the same as ES6 in that respect.
- pubby 11y agoI'm new to Javascript, and am wondering if I be writing ES6 instead of ES5. Is that a good idea, or should I wait a few months/years?
- niix 11y agoThere is no harm in either. Overall, just have fun and learn JavaScript :) ES5 is the current standard in all major browsers, so using its functionality could be considered "safe". Thankfully we have transpilers (will convert your ES6 code to ES5), so you can use ES6 features in production today - just remember they are converted to an ES5 implementation of said functionality.
- iMark 11y agoWhether you're writing 5 or 6, it's still worth looking at and getting familiar with the various Javascript build tools (Grunt, Gulp etc). They're an increasingly important part of a Javascript developer's toolset, and using them to transpile 6 to 5 will get you off to a good start.
- haberman 11y agoI've just been playing with Promises and like them a lot. But one thing I find strange is that ".then()" creates a new promise, but with no way to reject it. ie. I can't write: return new Promise((resolve, reject) => { // Do some stuff, call resolve()/reject() on success/failure. }).then((step1Val, resolve, reject) => { // Do some stuff, call resolve()/reject() on success/failure. // But this doesn't actually work, because the "then" callback // doesn't get resolve/reject as args. }); Instead I'm having to write this as the following, which is more verbose: return new Promise((resolve, reject) => { // Do some stuff, call resolve()/reject() on success/failure. }).then(new Promise((resolve, reject) = { // Do some stuff, call resolve()/reject() on success/failure. // But this way I don't get access to step1Val. })); Another bummer of this style is that that the second step doesn't get access to the first step's value.
- 15155 11y agoasync/await solves error handling and hanging onto values quite nicely. IMO you should use Babel and take advantage.
- haberman 11y agoI am using Babel already. Not sure I'm ready to dip into ES7 features though. ES6 feels bleeding-edge enough for me.
- grandalf 11y agolink to example please
- 15155 11y agoasync function foo() { try { const valueOne = await promiseReturningFunction(); const valueTwo = await anotherAsyncFunction(valueOne); return valueTwo; } catch (err) { alert(err); } } foo(); //Returns a Promise. ---- In this example, I've sequenced the resolution of two promises (async functions return Promises when invoked) If either of these Promises reject or throw an error, or if any of the code within the try {} block throws an error, the error will be caught inline in the catch block (one area only). You can also see that both Promise's return values are in-scope and continually usable (vs. losing scope with 'then' chains).
- qudat 11y agoCoroutines are the game changer imo. I wrote a little presentation to illustrate code flow: http://afc.neurosnap.net http://afc.neurosnap.net
- tlrobinson 11y agoI agree with this list completely, but it doesn't mention one of the best reasons generators and promises are awesome: async/await-style asynchronous programming eliminates callback hell by letting you write asynchronous code as if it were synchronous, including using control structures like conditionals, loops, and try/catch. And you can do it in (most) browsers today using a transpiler like Babel and a library like Blurebird, Q, co, or task.js. The rest of the things are nice, but promises/generators (and eventually async/await) are game-changers.
- ehaliewicz2 11y agoOf course, with proper tail calls, you can get generators and any kind of control structure almost for free :)
- amelius 11y agoThe problem with Javascript generators, however, is that you're not allowed to call other functions from them, which yield. This very much limits the kind of async stuff you can do with them.
- tlrobinson 11y agoNot really (at least not the kind of stuff I mentioned), those functions can just return promises which the caller yields: http://codepen.io/anon/pen/WvzGLa http://codepen.io/anon/pen/WvzGLa Granted async/await syntax will make this a bit nicer: async function funcA() { await sleep(1000); // ...
- amelius 11y agoBut then the called functions have to be written async style.
- deleted 11y ago[deleted]
- AgentME 11y agoThe first module example is incorrect: // myModule.js export function myModule(someArg) { return someArg; } // main.js import myModule from 'myModule'; The import is importing a non-existent default export. Either the export needs to be changed to a default export: export default function myModule(someArg) { -or- the import needs to be changed to importing a member: import {myModule} from 'myModule';
- niix 11y agoThanks, fixed.
- chengas123 11y agoWhen will browsers start to implement these features? I'm looking forward to being able to use modules in Chrome.
- etblg 11y agoThe other features? Already being done: https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/ Modules? That may be a while, and isn't a big concern since until HTTP2 is in wide effect (which may be really soon anyways) it makes more sense to just package the files in to one file (which you can do right now) using Browersify, JSPM, Webpack, or what have you than having the client request a whole bunch of javascript files at once.
- chjj 11y agoES6 is a mixed bag for me. I'm against block scope in a way. It's semi-useful, but it's just sugar. So many features of ES6 seem to be designed for people who don't want to bother learning javascript: classes, block scope, arrow syntax, etc. It's just trying to shoehorn javascript into the template every other language follows when javascript is not every other language. That being said, I like iterators, weak maps, typed arrays, TCO, and so on.
- Kudos 11y agoFat arrows are increasingly becoming one of my favourite additions. No more `function() {}.bind(this);` since `() => {};` is equivalent. It makes it clearer for the reader that the code block inherits scope.
- joeax 11y agoAlthough arrow functions are nice, they've been around in the form of lambda expressions in C# and other languages for some time, so the initial reaction was more of a "about time" rather than a "wow!" for me. Same goes for generators/yield keyword. Thanks for pointing out the key difference between arrow functions and inline functions being the context of 'this'. 'this' is going to be a source of confusion for a lot of people.
- todd3834 11y agoYes, a lot of the new features are very "about time" but that doesn't remove the excitement to now have them as a part of JavaScript. 'this' without arrow functions is currently a huge source of confusion. I feel like the arrow functions will help to alleviate a lot of that confusion.
- joeax 11y agoMy biggest excitement is that in the past few years JavaScript is now regarded as a first class language, and we're seeing these new versions i.e ES 5,6,7 in a rapid development cycle. I remember being told in the 2000-2002 era that JS was a kiddle language and it was worthless on a resume.
- kriro 11y agoI think .bind(this) could be added as a (more common?) alternative example to var self = this; Personally I'm most excited about the module system. It's by far the most confusing thing for our students (and hard to google since you end up going down the rabbit hole of build systems etc.)
- v413 11y agoWith the introduction of arrow function you won't need to use .bind(this) as arrow functions capture in their lexical scope the variables/keywords: this, arguments, super. e.g. setTimeout(function(){alert(this.a)}.bind(this)); becomes simply setTimeout(() => alert(this.a));
- kriro 11y agoYes, maybe my comment wasn't clear. I meant to say add ".bind(this)" as a case that is replaced by => just like "var self = this;" or (...)(); for that matter.
- pluma 11y agoThere is a proposal for a :: bind operator. 1. a unary :: operator for binding methods to their objects: `foo.then(::console.log)` 2. a binary :: operator for chaining: `x(a)::y(b)` (equivalent to `y.call(x(a), b)`)
- pjmlp 11y agoNow just throw away the DOM, replace it with something more suitable for applications instead of documents, and we can have something akin to Smalltalk back.
- spion 11y agoI don't understand why everyone considers classes controversial. If you look at code in the wild, it already does what classes desugar to: everyone already writes constructor function and attaches properties to their prototypes. At least now with classes, users coming from other languages wont be as tempted to make their own completely incompatible object systems.
- dmak 11y agoWhile my example isn't an issue in ES6, most of the controversial came from CoffeeScript. Using classes comes with classical inheritance expectations. In CoffeeScript, changing class variables would carry through all instances, and that is unexpected from a classical inheritance point of view. However, it made complete sense in the compiled JS.
- jestar_jokin 11y agoMaybe I'm misunderstanding, but isn't that the same as static properties on classes in Java?
- hokkos 11y agoIt is more the "extends" than "class" that is controversial because it eschews other pattern like mixins.
- neoeldex 11y agoIn es6 it's finally possible to properly subclass internal types, it properly separates Class properties and prototypes, and it allows users to extend arbitrary classes.
- _pmf_ 11y agoCatching up a bit with C#, I see.
- m1sta_ 11y agoI hope our IDEs get smart enough so that destructuring features result in pseudo named function parameters.
- z3t4 11y agoI'm working on a JavaScript editor. But doesn't understand. Can you be more elaborate!?
- charriu 11y agoI'm a bit worried about ES6 making the language harder to understand. For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?! On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.
- alkonaut 11y agoCan someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version? For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign would look like I consider a flaw). Why not just make a simple and consistent syntax?
- dmak 11y agoWhat about it is not simple and consistent? Two different syntaxes, and two different expectations and rules. Var is function scope, and let is block scope.
- alkonaut 11y agoI feel like in a new design you would pick one or the other, as a second scoping rule would not carry its own weight in terms of what problems it solves vs the complexity of implementing runtimes or learning the language. In that case I'm almost certain you would go for block only as it is the default in nearly all curly braced languages.
- techiferous 11y agoYes, as a matter of style you could just use let everywhere, and know that var is there for legacy compatibility reasons.
- 11y ago
- koolba 11y agoWhat's the point of promises being part of ES6? I understand them and use them quite a bit. I just don't understand why they're in the language spec. They don't add anything new to the language (vs say generators or symbols). Is it purely for performance?
- AshleysBrain 11y agoIt allows web APIs built-in to the browser to return a promise, e.g. audioContext.decodeAudioData(data).then(...). If you just used a library, the browser wouldn't know how to wrap the returned value in a promise. It also guarantees interoperability between all APIs using promises, avoiding any incompatibility between different libraries.
- pluma 11y agoPaving the cowpaths. Promises were already standardized before ES2015 arrived, but now you can just write libraries using promises without having to rely on the developer providing their promise implementation of choice. This also prevents scenarios where you might end up with N different promise implementations because you're using N libraries, each depending on a different promise module (e.g. bluebird, Q, jQuery.Deferred, AngularJS $q, etc) all of which are slightly different. This also means more feature-rich implementations can just extend the native promises instead of implementing everything from scratch, though for me this pretty much spells the end of third-party promise implementations. In other words, they've been added for the same reason as the various new helper methods: not because they add new functionality, but because they provide a reliable well-defined and consistent solution to a very common problem.
- zoz 11y agoI was a little confused by the constructor for Player in the class example. Wouldn't the following be more appropriate: constructor(x = 0, y = 0) { this.x = x; this.y = y; } (i.e. this way if "new Archer('Legolas', 5, 6);" the x and y values will not be ignored.)
- niix 11y agoSure that works too, plus its a great way to point out initializing default arguments.
- scriptle 11y agoThe example quoted under "Arrow functions" is NOT "arrow function". It's an enhanced object literal.
- echeese 11y agoThere is one in the addIt function.
- github-cat 11y agoSo will someday there be interface in JavaScript?