Is `this` in Javascript bad?

Recently I have an argument with a friend who absolutely hate the this keyword in Javascript. He claims that since the language has an ambiguous binding of this in different situations, e.g. const f = obj.g will lose the binding to obj, obj.g.call(obj2) will call g in the context of obj2..., the this keyword in Javascript is simply one of the worst thing in Javascript.

He also claims that Javascript would be a lot easier to code/maintain by avoiding the use of this keyword. He advocates the following pattern for object creation:

function Car() {
  const car = {};

  car.position = 0;

  car.move = () => car.position++;

  return car;
}

new Car();
// or
Car();

I am, on the other hand, very comfortable with the this keyword. I use it a lot and appreciate how bind, call and apply works. However, I can't really find a legit argument against his pattern, because it really seem to be clearer for those who don't know much about Javascript?

What do you think? Give me some insights!

Comments

[Ben Halpern]

Ben Halpern

@bendhalpern

Sometimes when I'm writing Javascript I want to throw up my hands and say "this is bullshit!" but I can never remember what "this" refers to

14:27 PM - 20 Mar 2015

1182511620

¯_(ツ)_/¯

[Jonas Røssum]

here, I think you dropped this: \ (pun intended)

[Steven Liao]

One thing about the pattern that your friend advocates is that it would be harder to use instanceof.

function Car() {
  const car = {};

  car.position = 0;

  car.move = () => car.position++;

  return car;
}

const car = new Car();

console.log(car instanceof Car); // false

You would have to do:

Object.setPrototypeOf(car, Car.prototype);

console.log(car instanceof Car); // true

[Dian Fay]

It's sneaky. I've wasted a decent amount of time and effort due to forgetting that this isn't bound in fat-arrow functions, or having a different binding than I expect at whatever point in the code. I still like using this, but I'm not sure I could mount a bulletproof defense of it.

[Patrick Minton]

I mostly agree with your friend, and I think ES6 has made it worse, because of how anonymous functions "break" the rules, which just confuses the hell out of junior devs:

foo: () => {
  // `this` isn't in `foo`'s context, it's in `foo`'s parent context.
}

I also kind of hate how everyone invents their own convention for re-assigning this to avoid context problems like so:

const that = this; // But some folks use `self`, or `_this`, or `this2`, etc.

const foo = function() {
  // do something with `that` here, since `this` is local to `foo`.
}

Having said that, it's use is extremely prevalent, so I wouldn't make a crusade of this. It's a lot being that guy who's always complaining that everyone uses the phrase "begging the question" wrong.

[Meghan (she/her)]

Arrow functions were made specifically so that the second example wouldn't have to happen anymore. Consider the following.

class Person {
    constructor(id) {
        console.log(this) // person
        const that = this;
        fetch(`https://api.acme.corp/people/${id}`)
        .then(x => x.json())
        .then(x => {
            console.log(this) // person
            Object.assign(this, x);
        })
        .then(function(x) {
            console.log(this) // window
            // `that` is the only reference to person in this scope
        });
    }
}
const person = new Person('12');

Ignoring how terrible that code is, arrow functions allow you to have functions in functions while still maintaining the scope of your parent, yes but this behavior was very much requested and intended

[Patrick Minton]

I agree that this is a good thing....if you are senior enough at javascript to understand the nuances of the scope of this and you understand how arrow functions interact with this differently than "traditional" ones -- to many junior devs, () => is just shorthand for function(). The fact that it isn't is mostly the fault of this -- and is that extra "thing you need to know" really worth keeping this around?

I've always had a love/hate relationship with magic variables (back when I first encounterd $_ in perl my mind was a little blown).

I can completely understand how avoiding them makes for more readable code.

[Meghan (she/her)]

Using this in any language is a hallmark of doing anything in OOP. Yes, JS has some things to watch out for, but the idea anyone would consider trying to drop using this altogether instead of learning the time/place and make making great things so much easier escapes me.

[Damien Cosset]

I think I agree with your friend. I don't hate the this keyword, I use it quite a lot myself. But I feel like the keyword this is prone to more errors than code trying to avoid it. Obviously, it all depends on the programmers writing the code.

To me, it seems safer to try to avoid using too much this. It also reads better I believe. When I'm reading code, I wouldn't want to ask myself every 2 lines: What is this this referring to?

[YCM Jason]

This I think really depend on the design of your system.

In angular/vue/react, the framework seem to have developed around the keyword this without an issue. I wonder why they have made this choice if this could be troublesome.

[Damien Cosset]

I use React quite often. So, I use this a lot. I use arrow functions all the time, so every single this I use refers to the outer most instance, the component, every single time. Definitely a personal preference anyway :)

[YCM Jason]

the only advantage that I could think of using this is the ability of reusing functions. Using the method suggested by my friend will create a new function instance for every object created. But if we use class, essentially we are using prototype, so all the methods will only be defined once. It makes a difference when we are creating the same instance many many times.

[Guillaume Martigny]

It completely shatter the prototype which is bad IMO. Your friend's method not only create a new function each time, but prevent any ineritance.
Also, it's not possible to supercharge Car's prototype.

The "this" keyword can be tricky, but avoiding it leaves you in a land without OOP.

[Eban Emmanuel]

that was. mostly for the class base component i suppose

[Leah]

Yeah, but in react click handlers and other stuff most of the time need this, which leads to you either abusing class properties for arrow functions or having bind everywhere

[Meghan (she/her)]

While there are some historical gotcha's when using this in certain contexts, if you plan to use JavaScript in an OOP sort of way, I would in no way say that you should steer away from using this. On top of that, constructors should not be defined with functions anymore. They should be in a class where using new is forced and the meaning of this is unambiguous.

Secondly I would greatly avoid using .bind or .call as much as you can. Some of the easiest ways to lose track of this is using functions in this way..

[Nicholas Galea]

"since the language has an ambiguous binding of this in different situations"

Learn the situations, and use accordingly.

Refusing to learn how the tool you're using works will impede your work, or at minimum drastically reduces the quality of it.

I understand that JavaScript is "special" when compared to other languages, but working around it's eccentricities will only stop you from leveraging all that it has to offer.

[Jesse Ditson]

In javascript, there are no absolutes. Your friend is wrong if they believe a single pattern will always be correct. That being said, some guiding principles can be helpful:

• this is valuable when you're working with a stateful object. You can ask yourself: is your object an instance of a "superclass", in that other instances of this object may exist and have different states? it's very likely that this is the right tool for the job. In fact, as of es6 the module pattern your friend uses should most likely be refactored to a class.

• this could be considered dangerous when working with raw objects. If you find yourself using .bind a lot, or if you're calling this from inside a method of a non class-like object (e.g. you would never make more than one of the object/function), consider taking a more functional approach. With new Promises and arrow functions, functional javascript has become a lot more fun and readable.

This argument IMO is generally a hold-over from when javascript didn't have classes, so you had the option of either constructing using the module pattern like your friend, or using a function constructor and appending methods to the function's prototype. Nowadays, we don't have to argue because we have the class keyword.

Is this a minefield of possible mistakes in javascript? Absolutely not. It's part of the language, and gives us important OOP abilities. You should use it when appropriate!

[Lay Flags]

Have you seen Douglas Crockford's talk during Nordic.js 2014? There he said that he stopped using Object.create, new, this, etc. completely and instead uses the factory pattern for creating objects, similar to the pattern of your friend (around 25:00). After watching the video I tried it out and from then on I never missed these keywords. I rarely use the factory pattern nowadays, just if I really need it. Instead I try to code more functional

[Jeffrey Westerkamp]

It is only when call, bind and apply are used for the wrong reasons - or excessively - that this starts to get unpredictable. In my opinion this is the exact thing that makes Javascript as powerful as it is.

this always points to the context of the call to the function within which the keyword is used.

Arrow functions do what they do because the above statement does not apply to them. Instead, they inherit their this value from their declaration context.

That's all there is to it. It is never arbitrary, nor should it be difficult to determine, where this points to. I think it's just a matter of awareness of the fact that you'll have to look for its value at the preceding call stack, instead of it's lexical scope.

[Tomer]

Because I come from the word of c++/python amd haven't done anything majorly oop in js this seems unpredictable to me. But I don't know how much you should optimize your code readability for language newcomers

[WORMSS]

Tell your friend to suck it up and get over it. You either have a flexible language, and deal with its looseness, or pick a stricter language, and deal with the lack of flexibility.

[YCM Jason]

that's not a great argument, but I like your thinking! xD

[Ross Henderson]

I have no reason for it, nor do I use JS a lot in my work. But whenever I do I avoid using this, as I just feels too ambiguous. I like being very clear and direct in my code, and if that means I need an extra two lines, that's just the way I prefer it.

Though in a lot of cases it would have made things a lot easier for me.

[Joshua Johnson]

There are no ambiguous bindings for the keyword this. They are very predictable. Some frameworks decide to change the bindings and that is the issue.

[David Zentgraf]

I consider Javascript to be an experiment in which Brendan Eich tried a few new ideas, one of which is the behaviour of this. And unfortunately, it's one of the ideas that didn't work out so well. While the simplicity and flexibility of Javascript's object system is intriguing, and maybe this is a necessary part to make it work, as a programmer on a day to day basis the behaviour of this introduces more stumbling blocks than it adds benefits through flexibility.

Put another way, I've had to add more "superfluous" bind() calls to keep the context on a callback than I used the flexible re-binding mechanism to do something useful I couldn't have otherwise.

These kinds of things are only discoverable through longterm use, which Javascript didn't have the time to go through before being released into the wild, and now can't be fixed because backwards compatibility. But that's no reason to throw out the baby with the bathwater; just be aware of it.