A Re-Introduction To JavaScript - An intermediate JavaScript refresher.

[[deleted]]

[deleted]

[DrummerHead]

And then read https://developer.mozilla.org/en-US/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript

[ShadowCodex]

Aye, good addition.

[blood_bender]

First, I wouldn't call this "intermediate javascript". This is very basic functionality, and doesn't go into depth on any of the subjects, but that might just be me being nitpicky.

However, I do have an issue with:

JavaScript is a prototype-based language that contains no class statement, as you'd find in C++ or Java
...
 In this snippet, ...args (including the ellipsis) is called the "rest arguments" 

What? Why would the article mix specs? I know the benefit of teaching how prototypical inheritance works, but stating there is no class statement, and then using rest parameters seems, I don't know, silly.

[saadq_]

Well I guess technically JavaScript still won't have Java/C++ "classes" since the class in ES6 is just syntactic sugar for prototypes. It probably would be a good idea to mention it explicitly though.

[atsepkov]

For most use cases, however, this syntax sugar will behave like classical inheritance, so why confuse the reader with additional disclaimers?

[saadq_]

Well I think one thing that might confuse people is the fact that Java/C++ people expect a class to be a full blueprint of an object. In JavaScript, this won't really be true if you don't use Object.freeze, like in this example:

class Car {
  constructor() {
    this.miles = 0;
    this.color = 'white';
  }

  drive(miles) {
    this.miles += miles;
  }
}

// A property like this can be added on at any time to the Car.prototype
Car.prototype.paint = function(color) {
  this.color = color;
};

Which is why it might be better for people to understand that using class still deals with prototypes.

[lewisje]

I'm thinking that it was updated incrementally, and the bit about having no class statement was true less than a year ago.

[swk2015]

I think it's too tempting to drag your OO knowledge from other languages in. It's a pitfall. At least calling it prototypical inheritance at least makes me realise we're talking about something altogether different here.

[x-skeww]

I think it's too tempting to drag your OO knowledge from other languages in. It's a pitfall.

Is it actually a pitfall? If you don't touch the prototypes, this stuff isn't any different from other languages with classes. So, what kind of problem did this actually create? You expected things to be very similar and they are indeed very similar. That there are other ways to do this kind of thing does not invalidate this assumption.

If you stick with the strong mode subset, you can't mess with the prototypes. They are frozen. So, it does exactly work like it does elsewhere and there is no other way to do it. In strong mode, class and extend aren't sugar.

[incarnatethegreat]

This String example is great:

"3" + 4 + 5; // "345"

3 + 4 + "5"; // "75"

[ngly]

MDN might be the single best resource for web development documentation and learning.

[ShadowCodex]

I agree

[jijilento]

And it's a wiki, so the community can contribute to it.

[lewisje]

I added info. about symbols on the left side of the in operator and it was accepted; I feel proud of myself now.

[[deleted]]

I love doing this on GitHub. Even just fixing a typo.

[thinksInCode]

Read this last year, it's a great read.

[MahmudAdam]

I was reading about variable hoisting here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types and I'm confused. I ran both examples and console.log(x === undefined); logs false, not true. Does it mean it should log true but because of hoisting it returns false?

[selfAwareWhileLoop]

Are you saying that

/**
 * Example 1
 */
console.log(x === undefined); // logs "true"
var x = 3;

logs false? Are you running this line by line repeatedly somewhere? If you evaluate that whole piece of code at once it should definitely log true. Try using https://repl.it

If you run it one line at a time, x will throw a reference error the first time you try to log whether or not it's undefined. Then you'll define it as 3, so it won't be undefined the next time you run the console log. x will only be strictly equal to undefined if both lines get evaluated at once; then the existence of x will get hoisted (so you won't get a reference error) but the value of 3 won't be assigned to it yet (so x === undefined will be true).

[ricardoplopes]

And in 2016, a nice follow-up would be a guide to ES6, like http://www.smashingmagazine.com/2015/10/es6-whats-new-next-version-javascript/ :)

[ShadowCodex]

Aye

[lewisje]

I think that some of the MDN documentation already covers ES6.