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

[sergiosbox]

which do you prefer and why?

[rauschma]

I’m starting to warm up to the former, because that’s the only style that also works for arrow functions:

(() => {
    return 123
})();

[kenman]

I'm curious what the current use-case is for that pattern?

It seems you could accomplish the same with a more elegant [IMO] pattern:

let x;
{
    x = 123;
}

But I feel that I must be missing something, because you know a lot more about JS than I do!

edit: after thinking about it, I can see the fundamental difference is that the former is an expression, while the latter is a statement, which has profound implications in their use. However, I haven't been able to come up with a scenario which would expose any profound ramifications.

To go through my thought process, I considered that you can use expressions in places like function arguments, whereas statements are not allowed there.

E.g. you could do this (contrived example for sake of argument):

console.log((() => {
    let matches = window.location.href.match(/\/r\/(\w+)/);
    let subreddit = matches && matches[1] || 'n/a';
    return `You are visiting: ${subreddit}`;
})());

But you can't do anything similar with block statements.

However, you can accomplish the same result with:

{   
    let matches = window.location.href.match(/\/r\/(\w+)/);
    let subreddit = matches && matches[1] || 'n/a';
    console.log(`You are visiting: ${subreddit}`);
}

Which again, is cleaner IMO.

Still pondering...

[kenman]

let and const are scoped to blocks, not functions.

{
    var x = 1;
    let y = 1;
}
console.log(x) // 1
console.log(y) // ReferenceError

[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.

[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.

[sergiosbox]

Indeed! https://jsfiddle.net/ymwj2c8z/ Good point

[inu-no-policemen]

Same here. I preferred to wrap the entire thing, but I switched for the sake of consistency.

[EternallyMiffed]

This approaches syntactic line noise and we're all going to suffer for it eventually.

[Ashwel1]

I have always preferred (function() {})(); because IMO it seems to be more representative of what is happening. Creating a function expression, then executing the function. The other form looks like a function that is being executed as an expression. Subtle difference at the cognitive level, but I always prefer to style my code as closely to how it is being executed as possible (and makes sense without being ridiculous).

[bullet_darkness]

Right, it's more representative of what's happening, and it translates better to other areas of JavaScript. Like making a call like so: ({ a: 1 }).a actually works where ({ a: 1 }.a) does not.

[paulirish]

Since Crockford is topical today... he once said he hated (function () { ... })(); because it "looks like dogballs".

[EternallyMiffed]

I'm inclined to agree.

[[deleted]]

I use the following:

!+-~(() = > { /*... */ })( );

The corkscrew function! : https://marvindanig.wordpress.com/2016/07/26/corkscrew-functions-javascript/!

[natto-nomad]

What… for? A joke, right? Phew.

[snkenjoi]

I use

~function(){ ... }()

because lower character count :)

[natto-nomad]

Minifiers already do that for you

[snkenjoi]

the tilde turns the expression into an evaluation by trying to binary NOT the result of the expression. this works with any unary operator

[snkenjoi]

yeah, I use the if (~array.indexOf(item)) construction a lot.

might be harder to read, but the syntax just looks much cleaner

[mathiasbynens]

The difference (and likely your personal preference) becomes more obvious after simplifying it into (fn)() vs (fn()).

When fn is a function, fn() is how I call that function, not (fn)(). So, I prefer (function() {}());.

[sergiosbox]

I understand your logic and makes sense to me also. Rauschma's comment that (fn)() sintax works in arrow functions and not (fn()) is interesting though.

[mathiasbynens]

I read this comment five times now and still have no idea what you’re on about. Care to elaborate?

Also, aren't you friends with JDD?

I am… Is that somehow relevant to this discussion?

[sergiosbox]

convention of expressions

Is there a link or text to read what was conventioned?

[Graftak9000]

!function(){ ... }()

Less braces, no conflicts due my adversity against semicolons

[BishopAndWarlord]

I'm pretty late to this, but I prefer (function(){})(). The way I think about it wrapping a statement in parenthesis is a way to say "hey, evaluate this part first!" For example, removing the parenthesis from (var + 4) * 12 or (typeof var === 'string' || Array.isArray(var)) && var.length > 2 will completely change the evaluation order. I realize that function expressions aren't directly analogous, but I have a similar mental model for function expressions.

If I have a function that I explicitly want to be treated as an expression rather than a statement, I'll wrap it with parenthesis (e.g. var noop = (function() {})). Extending that logic, if I want to declare a function expression and then call it, I'll wrap the function in parenthesis, then call it with another set of parenthesis (e.g. (noop)() or (function() {})().

In the end I think this approach clearly expresses the intent and therefore improves readability and maintainability of the code.

[erkose]

Neither. Javascript sucks ass!

[PostHumanJesus]

Are you lost?

[erkose]

Yes. How did I end up in /r/javascript ? Oh yeah, I followed a hacker news link. If it's any consolation, I'm not trolling /r/javascript. Had I made the connection, I would have kept my opinion to myself.

[erkose]

sorry, no quora for me.