C#'s lambda expression also has closures but is rarely discussed by the C# communities or books. I see far more JavaScript people and books talk about its closures than they do in the C# world. Why is that?
JavaScript Closures – Importance and Benefits
cclosuresjavascript
Related Solutions
jQuery's primary role is to normalize the DOM API which is the one thing browsers haven't agreed on for over a decade (until IE9 came out). It's better thought of as a tool than a library. It's basically just a factory function that returns an adapter merged with a bit of decorator that wraps and normalizes the DOM object API with lots of cruft reduction and some additional goodies like the animate function and an event system that lets you fire and listen for new events on the fly on any object without even defining them somewhere first.
What it doesn't do is help you with writing more complex, maintainable app-oriented code (well, the event thing is neat-o but easy enough to DIY), use objects well, or use any of the core ECMA spec obects that really form the basis for the core language of JavaScript.
Among proper JavaScript devs, it takes very little time to filter out the devs who are going to be useful on a project from web designers or CMS-only devs gunning for a salary increase by doing awful things with a tool they'd rather not understand under the hood if they can avoid it.
Also, the DOM API is pretty verbose with method names that practically write their own documentation (by approaching paragraph length basically), which is a good thing, IMO. We want the core native stuff to be obvious and spelled out. But the tedious nature of writing with it encourages us to use JavaScript to do something it's very good at. Eliminate cruft, normalize, and bend the API to a paradigm that works better for us. I personally think jQuery did a bang-up job of this compared to most of its contemporaries and that you can learn a lot about JavaScript (like how to keep your objects really lightweight as far as memory is concerned) by studying jQuery under the hood.
But I wouldn't use it as a pre-fab UI library namespace. And I wouldn't discard loops in favor of using .each on everything. And I often downshift to DOM API methods when JQuery is adding work without really eliminating cruft which brings up one of the most important features of jQuery to those of us who actually know what we're doing. It doesn't get in your way when you don't want it there.
But make no mistake. If you don't know how to do it without jQuery you're at best an entry-level JavaScript/client-side dev. On the flip-side if you only know JavaScript and only have minimal understanding of CSS, you better be focused on something other than UI problems.
Edit: I realize I focused on JQ a bit too much for a question that was asked more generally.
Most other popular JS tools/libraries/frameworks are either UI libraries, none of which I'm a big fan of (too inflexible typically), and rapid-application building frameworks that apply concepts from MVC or similar patterns. I'd rather DIY architecture personally (and I'm a little wary of this model-binding in templates trend) but these new frameworks aren't the sorts of things implemented by JS devs who can't handle code problems that require JS-literacy themselves I would wager.
tl;dr: while it's mostly syntactic sugar, that nicer syntax makes lots of things practical that used to end in endless, unreadable lines of braces and parentheses.
Well, it's actually the other way around as lambdas are much older than Java. Anonymous inner classes with a single method are (were) the closest Java came to lambdas. It's an approximation that was "good enough" for some time, but has a very nasty syntax.
On the surface, Java 8 lambdas seem to be not much more than syntactic sugar, but when you look below the surface, you see tons of interesting abstractions. For example the JVM spec treats a lambda quite differently from a "true" object, and while you can handle them as if they where objects, the JVM is not required to implement them as such.
But while all that technical trickery is interesting and relevant (since it allows future optimizations in the JVM!), the real benefit is "just" the syntactic sugar part.
What's easier to read:
myCollection.map(new Mapper<String,String>() {
public String map(String input) {
return new StringBuilder(input).reverse().toString();
}
});
or:
myCollection.map(element -> new StringBuilder(element).reverse().toString());
or (using a method handle instead of a lambda):
myCollection.map(String::toUpperCase);
The fact that you can finally express in a concise way which would previously be 5 lines of code (of which 3 are utterly boring) brings a real change of what is practical (but not of what is possible, granted).
Best Answer
Because javascript doesn't have feature like namespaces, and you can mess up pretty easily with all sort of global objects.
So it is important to be able to isolate some code in its own execution environment. Closure are perfect for that.
This usage of closure doesn't make sense in a language like C# where you have namespaces, classes and so on to isolates code and not putting everything in the global scope.
A very common practice for javascript code is writting it like this :
As you can see, this is an anonymous function declaration, followed immediately by its execution. Thus, everything defined within the function is impossible to access from outside, and you will not mess up the global scope. The execution context of this function will remain alive as long as some code uses it, like nested functions defined within this context, that you can pass as callback or whatever.
Javascript is a very different language than C#. It's not object oriented, it is prototype oriented. This leads to very different practices at the end.
Anyway, closures are good, so use them, even in C#!
EDIT: After some discuss on stackoverflow's chat, I think this anwer has to be precised.
The function in the sample code isn't a closure. However, this fucntion can define local variable and nested functions. All nested functions that use these local variables are closures.
This is usefull to share some data across a set of functions without messing up the global scope. This is the most common use of closure in javascript.
Closure are way more powerfull than just sharing some data like this, but let's be realistic, most programmers don't know a thing about functionnal programming. In C# you would have used class or a namespace for these kind of use, but JS does not provide this functionnality.
You can do way more with closure than just protect the global scope, but this is what you'll see in JS source code.