Live data from Hacker News

Overview of JavaScript ES6 features

adrianmejia.com

201–210 of 250 posts

Re: Overview of JavaScript ES6 features

#201
post #130

Earlier quoted context omitted.

Honest question here --- What is the difference between let and global variables? There are hundreds of articles written about the doom associated with PHP globals, but let appears to be universally lauded. I must be missing something, but I can't tell where.

It's spelled out pretty well in the article. But if you want another example, consider these two code blocks: var foo; var bar; { let foo = "hello"; var bar = "world"; } console.log(foo); console.log(bar); This produces: undefined world The reason being that the `let` statement restricted that variable to the block it was in (defined by the { and }). `var` declares the variable globally, allowing it to be accessed ou…

> `var` declares the variable globally"

Not quite. var's are hoisted to the top of their most local function.

  (function(){
    (function(){
      var x = 123;
    })();
    {
      var y = 123;
    }
    // Here, x is not defined, but y is
  })();
  // Here, neither x nor y are defined
The above code essentially gets translated to the following:

  (function(){
    var y;
    (function(){
      var x;
      x = 123;
    })();
    {
      y = 123;
    }
    // Here, x is not defined, but y is
  })();
  // Here, neither x nor y are defined

Re: Overview of JavaScript ES6 features

#202
post #112

Earlier quoted context omitted.

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 sh…

even if block scope was better, its not worth having three ways to declare a variable. Most JS programmers do not know about scope and they do not declare variables, but if they do, they more likely mean it to belong to the function, like in VBscript or PHP, rather then to the if statement. Explaining why you should declare variables is hard. Now I also have to explain block scope, and angel brackets now makes a huge…

I really don't think that most JS programmers write code without declaring variables. Anyone using strict mode, ES6, or ESLint/JSLint/JSHint is already forced to declare variables appropriately.

Personally, I think the benefits of let are worth killing off var. I have honestly never seen an example where hoisting has been more clear than the alternative (declaring variables before they're used).

Re: Overview of JavaScript ES6 features

#203
"you can start using it right now" if you don't care about IE8, IE9, IE10, and many mobile browsers and are willing to ignore 20% of your customers.

e.g: http://caniuse.com/#search=let

const does not have block scope in those browsers either, but will work, adding to your debugging confusion.

template literals and multiline string has no IE support at all (you need edge: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) so you can forget most most enterprise clients

Similar things are missing for most features from the article.

I wonder how many JS dev have to answer to actual customers because none of my clients in the last decade who would have accepted to have a possible failure on 1/5 of their visitors. Are they all bloggers or working in hype start ups ?

Re: Overview of JavaScript ES6 features

#204
For those using Babel already or want to use ES6+ on a set of supported browsers: we have started work on https://github.com/babel/babel-preset-env. Would appreciate more testing!

It allows passing in a set of supported browsers and transpiling what is required using the lowest common denominator env (uses https://github.com/kangax/compat-table for data).

  // .babelrc with preset options
  {
    "presets": [
      ["env", {
        "targets": {
          "chrome": 52,
          "ie": 11,
          "browsers": ["last 2 versions", "safari 7"]
        }
      }]
    ]
  }
If you have questions, ask below (or make an issue)

Re: Overview of JavaScript ES6 features

#205

"you can start using it right now" if you don't care about IE8, IE9, IE10, and many mobile browsers and are willing to ignore 20% of your customers. e.g: http://caniuse.com/#search=let const does not have block scope in those browsers either, but will work, adding to your debugging confusion. template literals and multiline string has no IE support at all (you need edge: https://developer.mozilla.org/en-US/docs/Web/J…

We use Babel to compile ES6/ES7/ES8 to ES5.

https://babeljs.io

Re: Overview of JavaScript ES6 features

#206
post #158

Earlier quoted context omitted.

This is what makes Eslint so great. If you extend Airbnb's (or write your own very strict) config, it will really enforce best practices for things like this. I think running eslint --fix will even change your "let"s to "const"s where appropriate, but don't quote me on that.

>I think running eslint --fix will even change your "let"s to "const"s where appropriate, but don't quote me on that. Yep, this is the relevant rule - http://eslint.org/docs/rules/no-var Though it just replaces all var with let. I expected it to intelligently use either const or let depending on how the variable is used ¯\_(ツ)_/¯

You're looking for: http://eslint.org/docs/rules/prefer-const

It does exactly what you describe :)

Re: Overview of JavaScript ES6 features

#207
post #184

Earlier quoted context omitted.

Exactly, and this is a big problem where I work. I believe code should be readable, even by those with only cursory knowledge of the language. Object shortcuts is also a problem I think. For example, I had a method like this: const getObj = (id, store) => { return { id: id name: store.something.name }; }; The linter gave an error on it because I used {id: id}. It was like the linter was trying to make my code harder…

You know instead of: const getObj = (id, store) => { return { id } } You could write: const getObj = (id, store) => ({ id })

I'm pretty sure that's a good illustration of my point.

Re: Overview of JavaScript ES6 features

#208
post #128

Earlier quoted context omitted.

Any popular "deep freeze" utilities around?

function deepFreeze(obj) { const out = Object.freeze(obj); Object.keys(out).forEach(key => { if (typeof out[key] === 'object') { out[key] = Object.freeze(out[key]); } }); return out; }

I think you meant "out[ key ] = deepFreeze( out[ key ] )" in the innermost step :-)

(recursive)

Re: Overview of JavaScript ES6 features

#209
post #93

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.

Let is a game changer imo. In the world of tens of dependencies, knowing that your variables are scope restricted reduces your cognitive load. It's one less thing that can go wrong. I agree with you on classes, but that's probably more because I've never been a big fan of OO in practice. It doesn't really seem to have seen much use in the greater js ecosystem though, unlike let/const.

The block which is long enough to need block scope is long enough to be a function.

Special bonus to couple decomposing assignment with IIFE so that any variables/symbols which "escape" from the nested function are explicit (and the locals simply disappear with the nested function).

Const would be nice, if it went further - treating the const declared identifier as if it were deeply frozen, at least within the scope of the const identifier. Alas, that touches on what is wrong with most programming languages in common use today: mutable by default, but we should be requiring "groveling" to make something mutable.

Re: Overview of JavaScript ES6 features

#210

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, sin…

The fact that a const can't be changed is great but in my mind the bigger thing is what the code communicates. Using const vs let tells future devs who work on the code that the value was meant to remain unchanged. If they need to change it, that's a signal that maybe there's more to it than they currently understand.

I agree that pull requests that mass change from let to const are largely a waste of time, but usage of const vs let is a legitimate discussion within your team.

Post reply on HN