Live data from Hacker News

Overview of JavaScript ES6 features

adrianmejia.com

81–90 of 250 posts

Re: Overview of JavaScript ES6 features

#81

I have a question: What does `for element of arr` buy me over `arr.forEach(element => ...)` I don't find the for...of syntax particularly appealing or useful, but I might be missing something. Is it a matter of preference?

for...of isn't only for arrays. Anything that implements the Symbol.iterator functionality can use for..of, which is pretty nifty for some custom classes and also includes things like the new Map and Set collections, see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... However, even in just arrays there is arguably a benefit. Namely, an extra function being created and invoked with forEach. While in a…

Ah, you're actually answering my question from above. I was wondering if there was a way to emulate the behaviour I've gotten accustomed to in Ruby vis à vis `Enumerable#each` where the (key, value) are yielded to the block passed to each. It doesn't seem to be possible to do that with object literals in JS, but you mention that Map would do (and it actually does, see [1]). Nice.

[1] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

Re: Overview of JavaScript ES6 features

#82
post #7

On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)

If you're developing a desktop-only app (or you're making a native app for the mobile frontend) ES6 works pretty well.

At least I haven't received any complaint yet, and if you can optimize early on without any short-term cost then it's the best thing you can do.

Thank god Chrome and Firefox dominate the market.

Re: Overview of JavaScript ES6 features

#83
post #55

While I'm a big believer in most of the ES6 changes (arrow functions! let/const! classes! generators!), I am not a big fan of many of the new destructuring features. They can actually make your code less approachable if you don't already know what's going on.

I agree about the object destructuring. The examples set off loud alarm bells in my head. Very cute and very unreadable.

Like others are saying, though, the array destructuring seems fine.

Re: Overview of JavaScript ES6 features

#84
post #7

On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)

For anyone who wants to use ES6 in production, https://babeljs.io/ is amazing.

Have used it in production and it's amazing.

Have you tried Minify(Babili) by the way?

Re: Overview of JavaScript ES6 features

#85
post #41

I'm surprised by the state of const/let nowadays. The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Se…

It should have been "let"/"let mut", not "const"/"let" (or some other scheme that makes immutable bindings terser). I recall people warning of this outcome at the time of standardization.

I don't think it's a terminology problem. In fact, "let" and "const" are probably the right terms. Both are descriptive and exist in other programming languages.

Re: Overview of JavaScript ES6 features

#86

I'm surprised by the state of const/let nowadays. The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Se…

Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars?

While I agree that const/let is a useful convention for communicating mutability, it isn't nearly a big enough deal to warrant the attention it receives from the community.

It's not just const/let; I rarely make a front end PR that isn't bike-shedded to death over subjective styling choices, single quotes vs double quotes, etc. It often feels like conforming to flavor-of-the-week, subjective decrees from frontend trendsetters is more important than the substantive work that your code is doing.

Re: Overview of JavaScript ES6 features

#88
Ugh. All this "make Javascript like Java" stuff needs to stop.

Cool stuff: Tail call elimination. Arrow functions. Assignment spread for multiple return values and "rest" / default parameters. Proxying (combined with computed get/set on properties) for easy decoration.

Classes and let: meh.

Re: Overview of JavaScript ES6 features

#89
post #19

var's function scope is a feature! You don't have to place variable declarations in the header! (they are hoisted) Placing the var declarations where they are used makes the code easier to understand. The point of constructor functions is not having to write new . So classes does nothing besides syntactic sugars over the prototype system, witch actually makes it more complicated and the code harder to maintain. Async…

> var's function scope is a feature! You don't have to place variable declarations in the header! (they are hoisted) Placing the var declarations where they are used makes the code easier to understand.

For the vast majority of variables, you don’t need hoisting (i.e. you can declare them in the appropriate scope and only end up using them after the declaration).

> The point of constructor functions is not having to write new.

Um, what? This is completely wrong. You have to write new with constructor functions unless you specifically add code to check whether you’re in a constructor and re-call with new, which is bad practice.

> Async programming is hard, but not because of callbacks. Promises is just a wrap around callbacks, witch just adds complexity and more boilerplate. It will get better with async/await but I will still prefer simple callbacks.

No, async/await is just a wrapper around promises. Promises are pretty great overall, and if your Promise code looks like callbacks then you might be using them wrong. (I would always use bluebird[1] over native promises, though.)

I agree with you that large parts of ES6 add unnecessary complexity, but I don’t think your examples are well-chosen.

[1] http://bluebirdjs.com/

Post reply on HN