31–40 of 117 posts
Whoop-dee-freakin’-doo??? Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op. Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the a…
Earlier quoted context omitted.
What you have to keep in mind is that JavaScript is not "a properly scoped language". Pretending that it is will cause you to miss key aspects of how the tool works. This helps no one, including you. Please, for as crappy as the language might feel, approach the language on its own terms.
Function scopes and variable hoisting was not the best parts of JS anyway. let brings lexical scope into the game, which I think is a great progress. And you cannot expect a variable to be defined outside of its lexical scope. That's not any different that trying to access a variable outside of a function that is defined in. If people were abusing variable hoisting in some way, they can continue to do so, by not usin…
// x has not been defined or initialized anywhere
console.log(typeof x)
// x has not been defined or initialized here
console.log(typeof x)
let x = "foo";
> This means that typeof can now throw >>> def f(): ... type(x) ... x = 10 ... >>> f() Traceback (most recent call last): File " ", line 1, in File " ", line 2, in f UnboundLocalError: local variable 'x' referenced before assignment irb(main):010:0> def f() irb(main):011:1> x.class irb(main):012:1> x = 10 irb(main):013:1> end => nil irb(main):014:0> f() NameError: undefined local variable or method `x' for main:Objec…
`typeof a` right now returns the string value "undefined" (assuming `a` was not defined anywhere) If it can either return "undefined" or throw an exception, can you see why that would be a problem?
Whoop-dee-freakin’-doo??? Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op. Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the a…
I think he means OO adds unnecessary complexity, hence the "bad bet".
Earlier quoted context omitted.
Fat arrow notation massively increases readibility by reducing the boilerplate verbosity of function definitions. Lexical "this" binding means that the "this" of the enclosing scope is reused; Arrow-defined functions do not get their own "this" when they are called.
Thanks but massively? function() {} vs () => {}?
e.g.
ES5
users.map(function(user) {
return user.name
}).filter(function(name) {
return name.length ES6
users
.map(user => user.name)
.filter(name => name.length a.length - b.length)
Earlier quoted context omitted.
Fat arrow notation massively increases readibility by reducing the boilerplate verbosity of function definitions. Lexical "this" binding means that the "this" of the enclosing scope is reused; Arrow-defined functions do not get their own "this" when they are called.
Thanks but massively? function() {} vs () => {}?
var _this = this;
call(function (){
return _this.value;
});
call(() => this.value);
Whats his problem with classes? I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).
Interesting point, but I disagree. I think that the lack of hoisting is one of the benefits of `let`. It works in a different way, which is more in line with other languages. Sometimes, you don't want a bunch of variables at the top of your function. Many functions do not need to be executed in the way that hoisting makes easier.
By the way, quoting Betteridge’s law of headlines at the beginning of your article whose headline is a question does not mean you get a free pass of using such a headline ;)
> This means that typeof can now throw >>> def f(): ... type(x) ... x = 10 ... >>> f() Traceback (most recent call last): File " ", line 1, in File " ", line 2, in f UnboundLocalError: local variable 'x' referenced before assignment irb(main):010:0> def f() irb(main):011:1> x.class irb(main):012:1> x = 10 irb(main):013:1> end => nil irb(main):014:0> f() NameError: undefined local variable or method `x' for main:Objec…
Except, now you have one that you expect and the other you don't. This doesn't make the language anything but more inconsistent. I prefer consistency inside a language far more than familiarity between languages.
Earlier quoted context omitted.
Fat arrow notation massively increases readibility by reducing the boilerplate verbosity of function definitions. Lexical "this" binding means that the "this" of the enclosing scope is reused; Arrow-defined functions do not get their own "this" when they are called.
Thanks but massively? function() {} vs () => {}?
function(){}.bind(this)
vs
() => {}
Automatically bound `this` is super important. It's very easy to forget one `.bind(this)` (or `that` alias) somewhere, especially when you have several levels of callback nesting.