The jQuery annoyance you describe is a trait of JavaScript and the idea of bound function contexts. I think most of the "annoyances" that people encounter with jQuery is that "it doesn't do this really cool thing my other language/framework did/does".
back
1 comments
I disagree that it's inherent to JavaScript.
I think two features that have almost ruined the language is the Function.apply and the new keyword.
Function.apply is to JS as Metaprogramming and indirection is to Ruby. Features don't have a priority of use, and programmers reach for the most interesting one (and go to town misusing them).
If there was no new and no Function.apply, JS would be more coherent and remain exactly as useful. It means that when an event is triggered or whatnot, rather than changing the meaning of 'this', it passes the target in as a named variable to the anon-function. Which is way better!
If you constantly have to look up 'what is this set to in this callback' you're so completely doing it wrong!
It's not something that can be resolved by simply removing `Function.apply` or the `new` operator. The way that the `this` keyword works is an integral of how JS works. There's nothing stopping you from using `Function.prototype.bind` or defining an event mechanism that retains its assigner's `this` value. That's what's so great about JS -- you have this level of control.
As far as events go, having `this` set to the element receiving the event is, IMO, entirely logical, and has been a common pattern way before jQuery came into existence. You can always access the target as `event.target` if you'd prefer.
If you have to look up "what is this set to in this callback" constantly, then you just need to learn the API/language.
> The way that the `this` keyword works is an integral of how JS works.
Says who? Antiquated API design by the W3C (which by the way had no reference implementation) shouldn't be the defining factor in how a language works. 'this' and 'new' were brought over to JS so people who were familiar with Java would 'get it'. JS was designed around different ideas before it was mutilated for the sake of superficial familiarity.
> If you have to look up "what is this set to in this callback" constantly, then you just need to learn the API/language.
I assert that good API design requires you to not have to look up things like this. Things that could be unambiguous. Usage of 'this' introduces ambiguity. Not to mention that in an asynchronous programming environment, if you're doing anything non-trivial and you're not copy-pasting $.ajax() code snippets, you want to have named references to things so that closures written inside the scope have access to whatever interesting thing you're working with.
var that = this is a huge indicator that API design is wrong, that this is an abomination and that people generally aren't thinking critically about the code they're writing.
Downvotes? What on earth for? Oh man you front-end guys really don't get it. If you disagree with my sentiments, that's fine. If you don't understand what I'm talking about, you're not a real programmer.
Check your facts.
The standards body for JavaScript is Ecma International -- hence JavaScript being officially known and standardized as "ECMAScript".
Additionally, JavaScript began at Netscape in 1995 two years before it was a published standard.
See Wikipedia:
The W3C had nothing to do with the design of JavaScript or even DOM 0.
No actually the down-votes are because you don't know what you're talking about --and are arrogant about it on top.
I disagree that is not inherent to Javascript. The way "this" is promiscuous among functions allows methods to be "just" function properties and is integral to prototypical inheritance.
The alternative closure-based OO style also works fine most of the time but it has some limitations, such as not being able to define protected properties that can be accessed in a subclass.
Of course, "this" breaking inside inner helper functions and event handlers (and having to use "var that" or Function.prototype.bind) is annoying as hell but is more of a syntax issue (fixed by things like CoffeeScript and the proposed #() lambda syntax for ES6)
Minor troll point, you should probably include Function.prototype.call as well. :)