Tips to Become a Better JavaScript Developer
21–30 of 46 posts
Re: Tips to Become a Better JavaScript Developer
#22 1) "this" is whatever you set it to with call/apply/bind, or, if you didn't,
2) if you're using "use strict"
2.a) "this" is whatever is to the left of the dot when you call the function.
2.b) otherwise, "this" is wherever you got the function from.
Think of 2.a in the literal sense, if you called the function from a bare variable reference with no dot operator on an object, then the statement "whatever is to the left of the dot" is "undefined". Basically, this means that you generally shouldn't end up with "window" as "this".So, if you got a function from the global scope, it's "this" is in the global scope. If you got it from an object, it's "this" is that object.
function AClass(){ this.id = "bar"; }
AClass.prototype.func = function(){ console.log(this.id); };
var id = "foo";
var obj1 = new AClass();
var obj2 = {id: "baz"};
var func = obj1.func;
obj2.func = obj1.func; // or even just "func"
console.log(func === obj1.func, func === obj2.func, obj1.func === obj2.func);
func(); // prints "foo"
obj1.func(); // prints "bar"
obj2.func(); // prints "baz"
with(obj1){ func(); } // prints "bar"
with(obj2){ func(); } // prints "baz"
Same exact function in all cases. The reason func's "this" in the first of the last three calls is "window" is not because that's what "this" defaults to, it's because that's where we found "func".Think of the global scope in a browser as looking something like this:
function window(){
with(this){
// your code
}
}
window.call(window);
So that is why, when an event handler is executed, it's "this" is the DOM element to which the event handler was added. myButton.onclick = function(){
// do something
}
You just stored the function on the myButton object, so when it gets read back again to be executed, it's coming from myObject.Using addEventListener does the same thing. And if the browser vendors don't actually store the event callbacks in the object, then I guess they must be using "call" to maintain backwards compatibility with the old event wiring syntax.
Re: Tips to Become a Better JavaScript Developer
#23I dislike when people say that good developers don't use libraries like jQuery. The main reason I use them is because I'm lazy. I'd much rather write $("#id") than document.getElementById("id"). I rarely write any javascript code that is so resource constrained that the extra time added by jQuery is not acceptable.
The actual quote was: >>What I’m saying is don’t rely heavily on jQuery, or any other library, without having some sort of understanding of how that library is accomplishing it’s tasks. Which I think is fair. (However, I don't agree with his assertion that using vanilla JS will be more efficient - in most cases, it won't.)
These days it is negligible though. The argument for using jQuery for DOM manipulation is oftentimes just one of readability.
Re: Tips to Become a Better JavaScript Developer
#24"You can write your own basic jQuery by doing this: var $ = document.querySelectorAll; Obviously this won’t cover everything, [...]" wat
Re: Tips to Become a Better JavaScript Developer
#25 var $ = document.querySelectorAll;
That doesn't work, it throws `TypeError: 'querySelectorAll' called on an object that does not implement interface Document.` The correct line is: var $ = document.querySelectorAll.bind(document);
I know this well because I use it in all my JS projects and plays nicely with Python style for loops (e.g. in CoffeeScript).While I avoid jQuery I awknowledge the value of it, esp with old and mobile browsers. I avoid it precisely because my apps need modern HTML5/WebGL capable browsers anyway.
Re: Tips to Become a Better JavaScript Developer
#26Re: Tips to Become a Better JavaScript Developer
#27Tip #4 Ditch the jQuery Crutch: "If you can accomplish the same thing by using vanilla JavaScript, 90% of the time, it’s more efficient to do so." No. Just no. It is not more efficient to do so 90% of the time. jQuery is mature and battle proven. It is already doing what it can do with an efficient way, which comes with years of experience. Saying, write your vanilla javascript and ditch jQuery, your implementation w…
You can replace most uses of jQuery by aliasing querySelector to $ and querySelectorAll to $$. You lose some of the automatic array iteration stuff, but really, if you were writing good code you would know how many elements you are about to select.
jQuery is a gigantic dependency and it's kind of sad if you need that crutch to write js. Beyond the selector stuff, its promises and xhr stuff is dubious as hell and can be done much better by several node.js libs like superagent and async.js or bluebird.js.
jQuery goes in direct opposition to a composable module-based approach, because it is a massive dependency.
Re: Tips to Become a Better JavaScript Developer
#28Tip #4 Ditch the jQuery Crutch: "If you can accomplish the same thing by using vanilla JavaScript, 90% of the time, it’s more efficient to do so." No. Just no. It is not more efficient to do so 90% of the time. jQuery is mature and battle proven. It is already doing what it can do with an efficient way, which comes with years of experience. Saying, write your vanilla javascript and ditch jQuery, your implementation w…
(Sounds a little like the NoSQL crowd telling me how much easier their databases are to develop in, without any thought for why the relational model became so popular).
Re: Tips to Become a Better JavaScript Developer
#29Re: Tips to Become a Better JavaScript Developer
#30Didn't know that `var $ = document.querySelectorAll;` will give you a chainable and highly fluent API, if I only knew earlier....
Yeah, it will also give you an array as the result. #not