81–90 of 144 posts
I'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?
Earlier quoted context omitted.
I 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.
`class` trades the flexibility of prototypes for the familiarity of other languages. :(
Earlier quoted context omitted.
Because the initial one is where you'd interface (potentially) with non-promise code. E.g. in order to wrap a node-style function, you can't throw or return. But in general you shouldn't need to use `new Promise()`, that should in most cases be reserved to more general, low-level code (e.g. a promisify implementation).
I'm writing code against indexedDB (which doesn't use promises), but I want to expose promises to my callers. So I'm wrapping my indexedDB usage in Promises. Also some of indexedDB doesn't seem like it would fit with promises, since some operations have 3 or more callbacks (onsuccess, onerror, onupgradeneeded).
I 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; } print…
Why is this a big deal? Seems pretty trivial.
Wow. I can't believe 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.
Hm, 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-st…
I've recently started a new project in React/Flux, and I've cut away 3 or 4 dependencies compared to previous projects by fully embracing ES2015/2016, as Babel automatically provides the necessary polyfills and compilation.
As for template strings, I think they make sense. Most programming languages have them in someway or another, like Ruby "hello #{world}" or Python 'Hello {world}'.format(world='World').
[1] https://www.reindex.io/blog/you-might-not-need-underscore/
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.
Promises I find rather ugly to read. So far Im liking arrow functions and template strings. Async/await I'm looking forward to in ES7.
I 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…
I'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.
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?
I 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.