Live data from Hacker News

Overview of JavaScript ES6 features

adrianmejia.com

51–60 of 250 posts

Re: Overview of JavaScript ES6 features

#51

Earlier quoted context omitted.

I don't think anything in the rest of their comment has anything to do with block scoping vs function scoping. I do understand the technical difference very well - I have a PhD in implementing programming languages with function scoping like JavaScript. If you agree with the person I was replying to maybe could you humour me and explain why you think function-scoping var is a useful feature?

> I do understand the technical difference very well - I have a PhD in implementing programming languages like JavaScript. I am happy for your PhD and that it is for implementing programming languages like JavaScript. My assertion is the advantage of having function scoping is apparent to those who understand function scoping. Block scoping-style programming in JavaScript was always, in my experienced, shoe-horned in…

But I do understand function scoping. I understand what it is, what its semantics are, and how to implement and use it. And the advantage over block scoping isn't apparent to me.

But even if it should be apparent to me, why can't you explain the reason to me? What is this - some kind of argument that is impossible to comprehend unless you already agree with it?

I can understand your argument that block scoping was shoe-horned into JavaScript, post hoc, but that isn't a technical argument for the benefit of function scoping, is it?

Re: Overview of JavaScript ES6 features

#52
post #22
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)

Also - for anyone writing code where performance matters, the question isn't when browsers support the syntax, it's when each JS engine's optimizations support it. E.g.: until some months ago just putting "let foo" into a function would cause V8 to bailout (meaning the whole function gets executed slowly, even if the actual let statement gets removed as dead code). Unfortunately I've never found any good references o…

This is an important distinction, and as far as I know, none of the new features are very optimized. If you really want to write performant JS without a build step, you basically have to write it ES3-5 style, use for loops over maps and foreaches, etc

Re: Overview of JavaScript ES6 features

#54

Earlier quoted context omitted.

How is having var be function scoped instead of block scoped a useful feature?

Parent literally said why in the rest of their comment. And if you still don't understand why, this probably goes back to understanding JavaScript fundamentals. Not understanding function scope vs block scope is the number one smell for me that someone did not learn JavaScript correctly.

I understand it well and think relying on hoisting is a bad idea, as do most people. Declaring a var in a block and using it outside of that block (which is what hoisting enables) is the opposite of "Placing the var declarations where they are used".

Please provide an example of what you believe to be a good usage of hoisting.

Re: Overview of JavaScript ES6 features

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

Re: Overview of JavaScript ES6 features

#57
post #45

Earlier quoted context omitted.

I resisted const for like 10 minutes. You get used to it really quickly and then when you see a 'let' in your code you just know something is happening with that variable afterwards. When I have to go back to programming in a language without const declarations it feels bad.

I know I should use const. I lazily leave it until the end then try to shoe-horn it in. Then it ripples through the code until I give up. Then I hate myself.

I've started to use const for every variable, then if I get an linting error about modifying a const, I switch it to let.

It took about two weeks to train my hands/brain to type const before let/var.

Re: Overview of JavaScript ES6 features

#58

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 is more flexible. While forEach is a method on Array.prototype, for...of is a consistent syntax that can be used in more places. For instance, iterables:

  function *myIterable (v) {
    while(--v) yield v
  }
  let launchCountdown = myIterable(60)
  for (let i of launchCountdown)
    console.log(`t minus ${i} seconds`)
So in effect arrays can be thought of as iterables in ES6. So IMHO it allows for more consistent behavior with the way iterators in other languages like Java and C++

Re: Overview of JavaScript ES6 features

#59

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 JITing compiler, the performance difference between for...of and forEach might be negligible (or non existent), you can't always be sure what the JIT is going to do. For hotspots, I would probably prefer for..of

Re: Overview of JavaScript ES6 features

#60

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 works with any iterable.

break/return/throw work as expected.

I imagine (eventually if not already) for-of will be slightly more performant, but that's just a hunch.

Personally I find the for-of syntax more readable.

Post reply on HN