You mentioning Java actually reminds me, what I find bizarre about the recent trend in javascript is that they're creating the boiler plate on purpose. In Java the boilerplate was a creation of the language, but in javascript it's a creation of the community! It's like some sort of sick joke.
The stuff I hate most is the boilerplate that means you find crappy little singletons everywhere when all that was needed was a function. And for the love of god, a function that's named and not pointlessly assigned by a var because you're mono-linguistic and haven't realised yet what the actual point of functions are yet.
Huge chunks of the javascript in the web site I've taken over were done by someone who loved these patterns, this is an example of his favourite one, pointless and led to colossal code bloat as he used it over and over for basic handlers.
function instantSearch() {
var instantSearchObject = {
config: {
animSpeed: 250
},
init: function () {
this.findComponents();
this.bindEvents();
},
findComponents: function () {
this.searchBlockCollection = $('.search, .entry-search');
this.searchInputCollection = this.searchBlockCollection.find('input:text');
},
bindEvents: function () {
var self = this;
this.searchInputCollection.on({
'focus': function () {
var currentInput = $(this),
currentSearchSuggestionsBlock = currentInput.parent().siblings('.search-suggestions');
currentSearchSuggestionsBlock.slideDown(self.config.animSpeed);
},
'blur': function () {
var currentInput = $(this),
currentSearchSuggestionsBlock = currentInput.parent().siblings('.search-suggestions');
currentSearchSuggestionsBlock.slideUp(self.config.animSpeed);
}
});
}
}.init();
}
Nigh on 30 lines of code, so few lines that actually do something. I tend to refactor them when I can so I can see what they're actually doing, the following code should do exactly the same thing (without me testing it):
function bindSearchBox() {
$(".search input, .entry-search input")
.on("focus", function () {
$(this).siblings('.search-suggestions').slideUp(250);
})
.on("blur", function () {
$(this).siblings('.search-suggestions').slideDown(250);
});
}
Hmmm, even just refactoring that tiny bit of code shows that there might even be a bug there, or at least pointless code, I'm not sure why he's sliding the search results up on focus, they don't stay open.
There are a lot of JavaScript frameworks around build by Java developers that couldn't be bothered to check what the language they are working with is about and how it works.
Thus they went and tried to "fix" JavaScript by trying to make it more Java like and thus unleashed abominations such as Dojo or Prototype.js upon the world.
What I personally really do enjoy is "var self = this;". Now you just overwrote the system variable pointing to the global object. What was this good for? Oh, the other language doesn't use "self" as a system variable, so it must be worthless in JS? Hmm.
Now we just have to define "var global = (function() {return this;}).apply(null);" and we have a reference pointing to the global object! Pure magic! Really? Are you serious? Sorry to hear so. (No, I was not suggesting to use some kind of more elaborate pattern for this. See, there is "self" ...)
(When ever you see "var self = this;", take your things and run.)
Err, that's totally ok. That's useful for keeping a reference to the object scope in a closure. You can't really write advanced javascript without it.
AFAIK in all the c-style languages `this` is the usual self reference. Python & Ruby are self. VB.Net is Me.
But javascript screwed `this` up and this is especially apparent when you use events where `this` ends up being the caller instead of the callee. Having a self reference in the closure allows you to fix the problem.
I think people ended up using self for a reason, it's strange enough in a C-style language that you're not expecting it to be anything, but familiar enough to be obvious. The other common ones over the years have been `_this` & `that`.
There are patterns in javascript and patterns. We need Crockford to write, "Javascript Patterns: The Good Ones".
BTW: your case on "this" is not JS, it's the the DOM interface (not part of the language). From the point of view of the DOM it's probably right: The element applies itself to a callback function (the event-handler), which is triggered by the DOM interaction. The right question is: Who is the callee?
The JS built-in solution to this problem is "Object.handleEvent". (Since anything is an object, this is a general approach.) Anyway, there is no need to overwrite one of the few predefined variables to store a reference to anything, may it be to "this" or any other.
Hmm. JS was before Ruby and Python, so it couldn't have screwed up something to be found there. (BTW: HyperTalk was also "me".)
The very nature of "this" in JS is because of late binding, probably the most important feature of JS. Since references are evaluated late, the need arises to store the reference in a variable for use in a later call. Since these are first-class objects, no problem. The standard name for this used to be "that".
My point was on the total ignorance regarding the language. Why would you want to call the variable "self", overriding built-in semantics? Why not use "window" or "document" for a change? Obviously you would not want to do this, even, if their values could be restored by the use of another closure.
The praxis of naming this "self" is just an import from other languages, proving that the author in question didn't care for the semantics of the language she/he uses. Would you do the same by a compiler directive in C, overwriting built-in semantics? Could this become a pattern? Probably not. Would you redefine "/dev" in a Unix shell for other than a hoax? Probably not.
(BTW: I do not see a need to down vote a comment that points out a feature in language semantics. With server-side scripts and web-workers the global object isn't always the browser window. There is more and more need for this reference, while it becomes obfuscated by a pattern rather questionable. And I'm rather shocked to see this pattern having become quite popular. There isn't even a handful of global system variables in JS, "Math", "Date", "this", and "self" are the only ones common to all platforms. How hard is it to respect these? There are even use cases for overwriting these, e.g. test, but then you've just rendered them useless, if you chose to overwrite them in your code.)
Edit: And in case you wouldn't see a point a made here, think of code maintainability. Let's suppose you're reading some random lines of code. "Math.sqrt", you would assume to know what this is. Provided, you're in a browser, the same would apply to "self.location". But, hey, you can't be sure nowadays.
The stuff I hate most is the boilerplate that means you find crappy little singletons everywhere when all that was needed was a function. And for the love of god, a function that's named and not pointlessly assigned by a var because you're mono-linguistic and haven't realised yet what the actual point of functions are yet.
Huge chunks of the javascript in the web site I've taken over were done by someone who loved these patterns, this is an example of his favourite one, pointless and led to colossal code bloat as he used it over and over for basic handlers.
Nigh on 30 lines of code, so few lines that actually do something. I tend to refactor them when I can so I can see what they're actually doing, the following code should do exactly the same thing (without me testing it): Hmmm, even just refactoring that tiny bit of code shows that there might even be a bug there, or at least pointless code, I'm not sure why he's sliding the search results up on focus, they don't stay open.