Immediately invoked function expression - aka an anonymous function that executes as it is interpreted.

    (function() { console.log('test'); })();

In old versions of JavaScript, variables had to be scoped to the nearest function (rather than the nearest block) so IIFE where often used for namespacing:

    var $ = (function() { this.version = '1.2.3'; })();
    $.version; // 1.2.3

This worked because the function would be immediately invoked upon interpretation, scoping it's contents to itself (aliased by the variable name).

Hate to be a wet blanket, but that second code sample won't work. The function doesn't return anything so $ === undefined. Even if it did, this in that context is bound to the global object, so is the same as setting a variable without var or let.

A proper example of IIFE for lexical scoping would be something like this:

     var numbers = "";
     (function(){
         for (var i=0; i<5; i++) {
             numbers += i + " ";
         }
     })();
     console.log(i) //undefined

Nowadays of course you could just use let instead of var

Your code snippet would kind of work as expected if used as a constructor. As in:

    var $ = function() { this.version = '1.2.3'; };
    var obj = new $;
    console.log(obj.version); //1.2.3

Of course that is not a IIFE.

Ah...brings me back to my SO days...

Hate to dry off the blanket but they just forgot the `new` keyword for `this` ;)

    var $ =  new (function() { this.version = '1.2.3'; })();
    console.log($.version); // '1.2.3'

EDIT: Or if you really want to abuse the spec

    var $ = (function() { if (!(this instanceof arguments.callee)) return new arguments.callee(); this.version = '1.2.3' })();
    console.log($.version); // '1.2.3'

lol. But yes, I do really want to abuse the spec. You could also do this:

    var $ = (function(){ this.version = '1.2.3'; return this; }).call({})
    console.log($.version); //1.2.3

But that's not quite as ugly so I guess I lose some points.

Immediately Invoked Function Expression;

(function() { alert('swiggity swooty'); })();

Also, I believe TypeScript uses these to transpile classes with public and private properties/methods (can't verify that's still case atm).

It's a really neat pattern imo, I remember it fondly from my JS heavy days :)

No, while this is sometimes used for private properties/methods, TypeScript never used it. TypeScript's private properties/methods are just compile-time errors, they're still public in the generated code.

You're right[0], which is weird because they got most of the way there. I guess I just assumed since they were leveraging IIFEs this would be a natural use case. I'd be interested in knowing why they didn't actually.

According to this[1] exchange on Stack Overflow, the IIFE is used by TypeScript because of other scoping issues (specifically protecting class properties before instantiation and defining interfaces).

[0] https://yakovfain.com/2015/06/30/the-private-in-typescript-i...

[1] https://stackoverflow.com/questions/56086411/why-does-typesc...

It's a useful pattern that I used a lot, though I don't know if I would agree that it's neat. I definitely prefer the explicit annotations or even the python underscore convention.

Immediately Invoked Function Expression: (function () { statements })();

An easily Googleable acronym.

he should have said IIAFE actually (immediately-invoked-async-function-expression)

  (async () => { console.log(await 'hello world') })()

All async functions are functions, so not really.