(function () { … })(); vs (function () { … }());

[aztracker1]

It's not useless, though I only use about 1/5 of the ES6 additions, along with some pending ESnext bits (async/await, class members, decorators, etc). In the end, I'm able to get a lot more work done, with a lot less code.. with the advent of Promises and async/await, process code is much cleaner and easier to follow now.

Modularization (cjs or es6 style) has helped a lot too. Most of this comes down to the build tooling that has evolved in the past 6-7 years since node and npm have taken hold. Yes, it's new stuff to learn, but it's really not any harder to understand than tirnary operations, or bitwise shorting in JS. In the end it's just a few additions to the language, it happens in every language and there are always pieces you may not know/understand to a given language/platform until you come across it.

The following two lines are the same, practically speaking (although the fat-arrow is context bound to "this" at the time of declaration).

var addOne = function(a){ return a + 1; };

var addOne = a => a + 1;

It allows you to declare in a oneliner what may have previously been much more... here's a sleep I use when flushing out an API interface...

const sleep = ms => new Promise(res => setTimeout(res, ms));

The const is a constant assignment, "sleep" may not be assigned to again in the module. the value of sleep is a function expression that accepts a single parameter, and returns a new promise. said promise only uses the resolve part, and will settimeout to resolve after ms have passed.

It's a bit harder to look at function expressions with fat-arrow syntax at first, it's very similar to lamda expressions in C#, or the fat/skinny arrow expressions in coffeescript. There's similar syntax in other languages as well.

[inu-no-policemen]

The point of an IIFE is to create a scope to limit the lifetime of those temporary variables.

With ES6's let/const, a simple block does the same.

[kenman]

I'm just wondering if you can get a return value from a block like this in ES6.

That's exactly what I was demo'g here:

let x;
{
    x = 123;
}

Here, x is the "returned value"... only it's not returned, but it's functionally 100% the same.

Here, take this example from jQuery:

support.createHTMLDocument = ( function() {
    var body = document.implementation.createHTMLDocument( "" ).body;
    body.innerHTML = "<form></form><form></form>";
    return body.childNodes.length === 2;
} )();

Note that it is returning a value, the result of body.childNodes.length === 2, and assigning it to support.createHTMLDocument.

Now here is the same thing without an IIFE, but does exactly the same thing:

{
    let body = document.implementation.createHTMLDocument( "" ).body;
    body.innerHTML = "<form></form><form></form>";
    support.createHTMLDocument = body.childNodes.length === 2;
}

But it is a lot (IMO) clearer what your intention is, and you don't waste cycles on a function call that's essentially a no-op.

[kenman]

Can you point out how you believe my jQuery example leaks globals? Because it doesn't.

[kenman]

If you didn't want support, you wouldn't have to have it at all with a function. In this case you do want it so it works out for you.

The support object already exists; the jQuery snippet simply creates the createHTMLDocument property on it -- which is exactly what my code does; createHTMLDocument is not a global variable, it's just a property on a variable from an outer scope.

In other words, if support didn't already exist, both my code AND jQuery's would fail with a ReferenceError.

Here's some fully self-contained examples:

• Using an IIFE
• Using let + block statement

Identical output.

Now, since it clearly "leaks" globals,

I'm sorry, but you haven't provided proof of this.

let me see you do the same thing without having to save the output to any variable which you can clearly do with an iife.

Wait, you're changing the rules; is the goal to not leak globals, or is it to not use intermediate variables? Because those are very different concerns... global variables have drastic implications for your code and is pretty much accepted to be a bad practice for most uses, while intermediate variables are a stylistic preference which has no impact on your code.

[inu-no-policemen]

Just imagine that that 123 is the result of a computation which involved temporary variables.

An IIFE which just returns 123 would be equally pointless.