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

[Rocky Bronzino]

I agree... Overcomplicating something just because you're not a fan of something is worse than learning to use it correctly. You can't assign a cat.speak function to a variable and expect it to be callable like a normal function. Methods implicitly get passed the object when called, so cat.speak() implicitly passes cat to speak. When you assign the speak function to a variable and call it directly it can't pass the cat anymore and will fail. The correct way to call from the assigned variable is speak.apply(cat) which will do same thing as cat.speak(). This is basic common sense when you understand how the language works.

[JavaScript Joel]

For sure, experienced JavaScript programmers are aware of this. But a lot of JavaScript programmers out there are not. And A LOT of people are still get tripped up on this today.

for instance this code:

const logSpeak = animal => console.log(animal.speak())
const logSpeak = ({ speak }) => console.log(speak())

Would any reasonable person understand that if you use argument restructuring, the context to speak will be reassigned?

The best solution is to program without this. And when you program with a functional reactive style, you never have to use this, so you never have this problem.

Though you are not in control of 3rd party libraries and there are many 3rd party libraries which will force you to use this and the problems associated with it.

[Nate]

IMHO adding more libraries is worse for new developers. They won't know the difference between vanilla js functions and those of a library or framework.

Interesting concept but I'd prefer devs to learn the nuances of js.

Full disclosure: I'm a fan of vanilla js whenever possible.

[Rocky Bronzino]

To me this is as obvious as x=y not being same thing as x="y" but I do understand the confusion to novice programmers, even "y" is confusing to some. I'm just suggesting that the language should not go out of it's way to cater to novice programmers.

[Nate]

Agreed, JavaScript is weird. But I love it! I also love C#. They're different languages with different works and benefits.

[JavaScript Joel]

The best solution is to program without this at all. The next best solution is to fully understand this. When those fail, this just an alternative.

I agree that more people should favor vanilla JavaScript when possible.

[JavaScript Joel]

To say nothis is for notice programmers, is to not understand all of the benefits that it can provide.

nothis will let you use argument destructuring. nothis will let you use arrow functions. nothis will name your context so you never have to write var self = this. nothis will let you write pure functions that output is computed solely on the input of other functions. nothis will let you use function composition.

[JavaScript Joel]

This is why I love JavaScript. JavaScript can be what you imagine it to be. If you imagine a JavaScript without this you can have a JavaScript without this.

[zeddotes]

I'm happy you love JS, seriously. I think you have good intentions so as to provide the community with helpful utilities. I just wish that you would be more comfortable with this so you could see its use and benefits, especially leveraged with the fat arrow in particular.

If I could suggest something, take a look at apply and call Function methods; that should provide some clarity. Going beyond that, I'm curious to see what would happen if I did something like this:

noThisAll.call(this, this)

[JavaScript Joel]

I think people have been trying to force OOP into JavaScript for a long time. I actually think classes were a mistake in JavaScript. But now that classes exist, people feel more and more comfortable with OO techniques.

JavaScript has Prototypal inheritance which is different than Class inheritance. But people coming from other languages start using JavaScript as if it were Class inheritance and that is where a lot of issues come from.

I feel like JavaScript is better suited for a functional reactive paradigm. Which doesn't require this at all.

The best solution is to code without this. Though sometimes you are stuck with this because of a 3rd library you are using.

If you look at the source code of nothis you will actually find that is exactly what it is doing behind the scenes. apply instead of call. github.com/joelnet/nothis/blob/mas...

So what you have suggested, is actually exactly how it works;)

[zeddotes]

There's no one best solution to every problem; what you're mentioning is subjective from case-to-case, dev-to-dev. You mention the use of functional reactive paradigm over OO, but then you're accessing this.event in your example; EventEmitter doesn't currently endorse that.

OO and Functional have their pros/cons and it's up to the infrastructure, architects, and developers to implement what works best as the solution to the problem, which is question to endless iterations of improvement over time.

We can sit here all day arguing about this, but I think it's clear where we both stand.

Ciao