Discussion on: Rethinking JavaScript: The complete elimination and eradication of JavaScript's this.

View post

While I admire your creative solution and how calmly you are defending this idea, there are certain problems that you or any good person must acknowledge to better fight the this battle. I know my comment might get lost in this heated debate, but the majority of the comments talking about

I am too smart! To me this is not a problem

are ignorant and pompous 🍿

I feel the best solution to the this problem, which others have pointed as well, is not using it at all. Your most common reply for that is ({ speak }) => console.log(speak()). I do agree that destructuring could be a disaster when dealing with context-sensitive this. But, I do not think that this problem is worthy enough to be dealt with an abstraction like nothisAll. You can come up with such particular examples for other javascript problems as well. But in all of these cases, a practical and a wise solution is to just to be simply careful!
You do not (generally) cover a problem by putting a blanket(abstraction) over it (which Javascript loves to do btw). You save the abstraction for complicated problems like DOM updates or routing. Abstractions never really are a pragmatic choice for bad choices Javascript creators made. The reason we have an arrow function is that there was a widespread this problem and everyone was inventing their own wheel to fix it.
Your abstraction might work well for developers like you, who are well experienced with nitty-gritty details of this. A junior developer like me would find the nothisAll too magical! Which in short would make me nervous about the code I am trying to modify. If I encounter a this problem, I have fellow developers like you in my team to help me debug it, but I do not have fellow developers who have time to learn yet another abstraction after all the recent Javascript abstraction fatigue.
Abstractions are great when used widely, for example, JSX or virtual DOM. The end of lifecycle for great abstraction generally is that they become first party API (jQuery) or the language syntax (fat arrow) offers a solution to the problem that they were trying to solve.
this is very much a part of Javascript language and yes it is flawed! but simply ignoring it means you are ignoring a significant part of collective Javascript work done by fellow developers. Also, to be very honest, sometimes the most pragmatic solution to a problem is simply using this.
Lot of us don't have the luxury to work with fancy ES2015+ syntax and the web is built on the promise of backward compatibility. I see codebases which are full of advanced usage of this, which looks like (src code)

export function osmNode() {
    if (!(this instanceof osmNode)) {
        return (new osmNode()).initialize(arguments);
    } else if (arguments.length) {
        this.initialize(arguments);
    }
}

Sure you can come up with ways to handle it in your abstraction, but no serious and widely used project would consider the novel abstraction because of the added complexity (which I like to call magic) over the already complex this.

I do not want to sound against your idea, I very much like your creative approach. But if you ask me whether I would let my kids use it? My answer would be no.

JavaScript Joel • Aug 9 '18

Very well thought out reply. And I agree with quite a lot of what you have written.

I prefer to code in a functional reactive style. This style naturally doesn't contain this. So it's rarely a problem. It's the style I preach and I find JavaScript is perfect for it. The problems above would never appear. The problems I have appear when I use 3rd party libraries that force me to use this. Now instead of writing small algebras, I have to revert to writing classic functions with return and this.

I also wanted to demonstrate many different waysnothis could be used. Though, as you have already pointed out, the best solution is to not use this at all!

For many people this isn't as easy. It takes time to wrap your head around a classless codebase. Pure functions and immutability.

This is the reason why I am asking the question Do we have to use this?

As you have correctly pointed out, nothing comes without a cost. A library has a cost (even small ones like left-pad). Any abstraction is a cost. Even design patterns have a cost. So if someone thinks anything comes without a cost, is to not full understand the thing. nothis included.

So you have to weigh the pros and cons of nothis when considering it for your project. This means that (like anything with a cost) is not for every project.

PROS:

Confusion around what is this is gone. (no more console.log(this))
Functions attached to the context are bound so code like <Button onClick={ctx.handler} /> will work.
The context argument can be destructured.
Nested this contexts no longer require var self = this.
You no longer have to learn why you need code like this.method = this.method.bind(this) in your constructor. or why this works {() => func()} but this doesn't {func}. Or why your code works here, but stops working in a setTimeout.

CONS:

nothis is an abstraction and therefore must be understood by all developers on the team.
overhead of an added library.
overhead of having to wrap functions in nothis.

For me, the pros outweigh the cons and can be used today in any project and even projects that do not have any transpiling like babel.

Your abstraction might work well for developers like you, who are well experienced with nitty-gritty details of this. A junior developer like me would find the nothisAll too magical!

I would disagree with this point though. I think teaching a new developer the ins and out and all the gotchas of this is far more complex than teaching them about nothis. It is an abstraction, but I don't see anything overly complex about receiving the sender as the first argument. It's follows a similar pattern to C# event handlers:

void button_OnClick(object sender, EventArgs e) { }

But if you ask me whether I would let my kids use it? My answer would be no.

It would be best to first teach your kids to not program with this. Because that is the true solution.