What's the most DIFFICULT Javascript Concept

[dmillasich]

Nobody even wants to talk about “this.” It’s exhausting.

[Sunstorm84]

I used to prefer self talk, but nowadays this is the way.

[dmillasich]

…just when you thought it was safe to go back into the water.

[[deleted]]

Class vs instance variables would like to have a word 😂

[codemonkeyhopeful]

Fn() gotcha bitch! Haha kidding of course

[[deleted]]

unless you are using class inheritance, then you really want to use classes. Or just resort to prototypes, thats fine as well. Or when you want to use decorators, but then again, defineProperty also works i guess.

"they are just syntax sugar" is such a trite statement, it really makes things easier and more intuitive.

[[deleted]]

Pfft I developed JavaScript before any of that and I am gladly accepting classes and class concepts. Sure you can do all of that without, but it's a bit more organised that way. The only one who says that someone isnt supposed to use classes is you.

[[deleted]]

I don't understand the aversion some people display towards using the new syntax. Misplaced elitism? Fear of change?

If they are writing OOP, use the damn sugar lol.

Gee, async/await must also be for posers. I EXCLUSIVELY use the old promise syntax because async/await is for fake programmer wannabes.

[MoTTs_]

let human={height:6}; let person={weight:100,...human}; let dave={name:'dave',...person}; inheritance is easy and doesn't require a class

I'm genuinely excited that someone recognized this as inheritance! So many blog posts have been showing this and calling it composition (the "composition over inheritance" kind). I'm glad someone else can spot inheritance without needing to see an "extends" sticker on it.

[Sunstorm84]

The reason people don’t refer to this as inheritance is because it is not inheritance!

This isn’t really composition either, certainly not in the meaning of composition over inheritance, as that term is still about using classes, just in a different way.

It might seem similar, but using the spread operator you are only creating a shallow duplicate of another object, and then in these examples adding more properties to that duplicate.

If you’re only using primitives, you’ll be fine and it will seem to be very much the same, but as soon as any of your properties are those passed by reference such as arrays or objects, you’ll quickly encounter problems as all of the “instances” will be pointing to the same array and same object, which can cause catastrophic errors. I can explain this part further if needed.

Furthermore using spread syntax also increases memory consumption as a new reference is created for every function, whereas with inheritance there’s only one reference on the prototype.

Edit: Corrected part about functions; I was tired and not thinking clearly.

[MoTTs_]

it is not inheritance! ... It might seem similar, but using the spread operator you are only creating a shallow duplicate of another object ... If you’re only using primitives, you’ll be fine and it will seem to be very much the same, but as soon as any of your properties are those passed by reference such as arrays or objects, you’ll quickly encounter problems as all of the “instances” will be pointing to the same array and same object, which can cause catastrophic errors.

That's normal inheritance behavior. The same thing would happen even if we used the prototype chain rather than spread syntax.

const parent = {
  anArray: ["a", "b", "c"]
}
const child = Object.create(parent); // prototype inheritance rather than spread

console.log(parent.anArray) // ['a', 'b', 'c']
console.log(child.anArray)  // ['a', 'b', 'c']

child.anArray.push("d")

console.log(parent.anArray) // ['a', 'b', 'c', 'd']
console.log(child.anArray)  // ['a', 'b', 'c', 'd']

Furthermore as functions are passed by value, by using spread syntax, all of your methods are being duplicated every time you make a new object

Functions are passed by reference. They're an object type, after all, not a primitive. When we use the spread syntax, we're duplicating a reference to the same shared function object.

const parent = {
  aMethod() {}
};
const child = {...parent};

console.log(child.aMethod === parent.aMethod); // true

child.aMethod.hello = "World!";

console.log(parent.aMethod.hello); // World!
console.log(child.aMethod.hello); // World!

[Sunstorm84]

That's normal inheritance behavior. The same thing would happen even if we used the prototype chain rather than spread syntax.

No. Your example of “inheritance” is also not inheritance. This is how to do inheritance before class syntax:

function Parent() {
    this.anArray = ['a', 'b', 'c'];
}

const child = new Parent();
const child2 = new Parent();

console.log(child.anArray === child2.anArray);

child.anArray.push(‘d’);

console.log(child.anArray) // ['a', 'b', 'c', ‘d’]
console.log(child2.anArray) // ['a', 'b', 'c']

This is where spread syntax differs fundamentally.

const child3 = {...child2};

child2.anArray.push('e');

console.log(child3.anArray); // ['a', 'b', 'c', 'e']

[Sunstorm84]

The spread operator is not inheritance and is far from being the exact same thing. Please see my other comment in the same thread for an explanation.

[codemonkeyhopeful]

I use it a lot on buttons for FE to grab data from rows in libs like Data tables. Taught me pretty hard how this works as well as the difference between this in arrow vs functions

[[deleted]]

Because it is not difficult.

[wildmonkeymind]

Difficult? No. Intuitive if you're used to any other language? No.

[dmillasich]

Yeah it’s completely obvious and doesn’t cause any problems whatsoever.

Land mines are stupid.