I keep reaching the conclusion that frameworks are evil and libraries are awesome. Frameworks promise to organize your code and keep things structured, but the inherent verbose nature of JS frameworks ends up harming more than the structure helps.
Ultimately, if naked JS is too difficult to manage due to the lack of types and interfaces, I much prefer to use another language that translates to JS, rather than attempting to force it onto the JS language, because it always becomes messy and half-baked.
Although it's ranting about Java frameworks rather than JavaScript a lot of the complaints look rather familiar. Having said that, I don't think anything in the JS world has reached the baroque complexity once regarded as normal in the enterprise Java world.
[NB Note my comments on that discussion - I had not long finished rescuing a monster of a Java enterprise application where the simplest thing needed to go through about 30 layers of abstraction (I did actually count them) from a page being submitted to the underlying message being sent over MQ - it seemed to be a point of honor to combine every feature of J2EE with every design pattern to do the simplest things. Having multiple huge jar files in the classpath each 97% identical to the other just added to the sense of adventure when you clicked on something.]
I know it's a bit unfair to pick on that particular document - but I'm worried as a long recovered abstraction addict to what degree I actually thought things like that were ever a good idea.
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.
I'm not familiar with your other examples but I object to ncurses being called a framework. In my understanding of the word a framework defines to some extent how your code needs to be organized and architectured, I don't think ncurses fits this description. It's more like a terminal-based drawing library.
Thats what people typically market it as, but when you use it, it has mor in common with various GUI toolkits. Lots of windowing, and the like, but not much drawing.
To me, there's really only two choices. You can use someone else's framework, or you can create your own. For applications above a certain level of complexity you are forced to choose one of those paths. There simply is no way to avoid it. Both are valid choices of course, each with their own pros and cons. But don't fool yourself into thinking frameworks are somehow evil. What I think you mean when you say that is "other people's frameworks are evil" and your frameworks (that you build with libraries) are awesome. That may be true, but keep in mind, when you build your own framework, you now have become the maintainer and de-facto teacher for both your application and your home-rolled framework you created to build it. As long as you're cool with globbing on those responsibilities and you feel confident you can help other developers get up to speed on your custom framework's architecture, then it's a fine choice.
"AngularJS fits the definition of a framework the best, even though it's much more lightweight than a typical framework and that's why many confuse it with a library."
They can call it a framework all they like, and obviously that word means different things to different people, but I've found AngularJS is more useful when described and treated as a library - a library for building a front-end framework.
AngularJS might exhibit some of the trappings of a framework (e.g. inversion of control), and it has some of the components a front-end framework would need: routing, templating, networking... but these components aren't tied together in a way that impresses an overall architecture. Calling Angular a framework leads developers to assume architectural decisions have been made when they haven't.
Also above the fold: "AngularJS is a toolset for building the framework most suited to your application development"...
Even internally they're insecure about it. I think library is a more useful definition because it encourages developers to think about architecture before they start building application specific stuff.
You have to be very careful if you don't let it manage all your DOM changes, and in general everything is done via it, so it is basically a framework.
AngularJS is much better than what we had before, but it is still not great, and a bit clunky .. hopefully the lessons will be learned and in the next cycle we'll get some nicer slimline things instead (though this cycle could take a few more years to run through).
So long as you never run into an edge case the framework was not designed to deal with. But oh, the framework itself makes it very hard for you to have a workaround. But that only happens... very often.
The difference between a framework and a library, IMO, is control.
You forfeit control to the framework in exchange for less code. But then you depend on it for your every feature.
Also, when the next big framework comes along that promises you even less code writing. It usually is non-trivial to make them work together, if at all. you just might end up with a legacy framework on your hands or face a complete rewrite.
Disclaimer, I work with legacy code written on top of JSF 1.2 and Richfaces 3. It probably seemed more organized and modular at the time. It's not.
Ultimately, if naked JS is too difficult to manage due to the lack of types and interfaces, I much prefer to use another language that translates to JS, rather than attempting to force it onto the JS language, because it always becomes messy and half-baked.