Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Overview of JavaScript ES6 features

adrianmejia.com

Post reply on HN
Print view View original

151–160 of 250 posts

Re: Overview of JavaScript ES6 features

#151

Post by Meegul »

z3t4 wrote: post #143
Meegul wrote: post #130

Earlier quoted context omitted.

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…

> With the asynchronous nature of Javascript, it's theoretically possible for you to declare a variable with `var`, assign it a value, then immediately use that value and find that it's different than what you expected Can you give an example ? My understanding is that the closure freeze the variable in the time the function was called. It can happen if you do not use a closure (function) though.

Here's a post on Stackoverflow that can explain it better than I can: http://stackoverflow.com/questions/21363295/understanding-ja...

Re: Overview of JavaScript ES6 features

#152

Post by nitroll »

nothrabannosir wrote: post #142
abritinthebay wrote: post #91

Earlier quoted context omitted.

> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? - Tabs vs spaces. - Vi vs Emacs - Weak vs strong typing - where to place {} in block statements - where to put commas No, programming in general is susceptible to these trivial holy wars.

Weak vs strong typing is hardly "trivial"... it's the very foundation of a language. Not trying to derail the convo or take sides, but one of these is not like the others ;)

Hardly anyone argues weak vs. strong types, the battle is primarily between dynamic vs static typing.

Re: Overview of JavaScript ES6 features

#153

Post by skrebbel »

Hurtak wrote: post #150
ggregoire wrote: post #39

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…

I heard interesting argument against const, it went like this: Const very rarely saves you from bugs and the bugs that saves you from are very easy to find and fix. On the other hand the time wasted by thinking where whether to write const or let and the time wasted by switching consts for lets (and other way around) outweighs the time saved by potentially preventing these easy to find bugs. To sum it up, if consts d…

That makes a lot of sense for c++ constness, which has virtually nothing to do with JavaScript's const. C++ constness is significantly more far-reaching and therefore more work to get right. I agree with his position.

JavaScript const is just a matter of typing 2 more characters and in exchange you make your code more readable (because you communicate "this stuff will never change from here on", which makes understanding the stuff that does mutate easier). There are no far-reaching consequences. Just type "const" everywhere.

Re: Overview of JavaScript ES6 features

#154

Post by rkwz »

dsp1234 wrote: post #57
JoeAltmaier wrote: post #49

Earlier quoted context omitted.

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.

I use https://www.npmjs.com/package/eslint-plugin-const-immutable for linting const usage. It even detects object props mutation!

Re: Overview of JavaScript ES6 features

#155

Post by [deleted] »

fenomas wrote: post #70
treehau5 wrote: post #46

Earlier quoted context omitted.

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

> My assertion is the advantage of having function scoping is apparent to those who understand function scoping. I assert that if you can't say what the advantage is then you don't understand it yourself. "You'd see the advantages if you understood this, and since you don't you must not understand it" is not a reasonable thing to say to people.

[deleted]

Re: Overview of JavaScript ES6 features

#156

Post by z3t4 »

minitech wrote: post #89
z3t4 wrote: 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…

> Um, what?

Sorry for the confusion, the ES5 example looked like a "factory" function, so I assumed that was what he meant. You do not have to wrap the constructor function in another function! ...

  function Animal(name) {
    // This code is run when the object is created. No need to wrap another function around Foo
    var animal = this;
    animal.name = name;
  }
  Animal.prototype.speak = function speak() {
    var animal = this;
    console.log(animal.name + ' makes a noise.');
  }
Here is a "factory" function:

  function AnimalFactory(name) {
    var animalName = name;
	
    function speak() {
      console.log(animalName + ' makes a noise.');
    }
	
    return {speak: speak}
  }

  var animal = AnimalFactory('Animal'); // You can omit new
  animal.speak(); // animal makes a noise
  setTimeout(animal.speak, 1000); // you can also do this

Re: Overview of JavaScript ES6 features

#158

Post by rkwz »

pauljaworski wrote: post #62
JoeAltmaier wrote: post #49

Earlier quoted context omitted.

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.

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 ¯\_(ツ)_/¯

Re: Overview of JavaScript ES6 features

#159

Post by rkwz »

skrebbel wrote: post #153
Hurtak wrote: post #150

Earlier quoted context omitted.

I heard interesting argument against const, it went like this: Const very rarely saves you from bugs and the bugs that saves you from are very easy to find and fix. On the other hand the time wasted by thinking where whether to write const or let and the time wasted by switching consts for lets (and other way around) outweighs the time saved by potentially preventing these easy to find bugs. To sum it up, if consts d…

That makes a lot of sense for c++ constness, which has virtually nothing to do with JavaScript's const. C++ constness is significantly more far-reaching and therefore more work to get right. I agree with his position. JavaScript const is just a matter of typing 2 more characters and in exchange you make your code more readable (because you communicate "this stuff will never change from here on", which makes understan…

> C++ constness is significantly more far-reaching and therefore more work to get right.

I'm not familiar with C++, can you explain more?

Re: Overview of JavaScript ES6 features

#160

Post by millstone »

ggregoire wrote: post #39

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…

How do you feel about `const` for variables that are not reassigned but are still mutated?

    const array = [1, 2, 3];
    array.push(100); // unexpected?
I prefer to use let for bindings to objects that get mutated, even if the variable is not re-bound.
Post reply on HN