In JavaScript, why does `function () { console.log('hi'); }();` throw a SyntaxError while `(function () { console.log('hi'); })();` runs, and what other forms make an immediately invoked function expression work?

## The rule the parser is applying JavaScript's grammar is ambiguous about the `function` keyword: it can begin a *function declaration* (a statement) or a *function expression* (a value). The specification resolves the ambiguity by position. If `function` is the first token of a statement, the parser commits to a declaration before it has seen anything else on the line. A declaration has two properties that break an immediate call. It must have a binding identifier, so an anonymous `function () {}` at statement position is already invalid. And a declaration is not an expression, so it produces no value — the `()` that follows it is a separate, empty pair of parentheses, which is itself a syntax error because there is no expression inside. Even a *named* declaration fails: ```js function () {}(); // SyntaxError: function statement requires a name function go() {}(); // SyntaxError: the trailing () is not a call ``` ## Making it an expression Anything that puts the function into expression position fixes it. The conventional fix is a wrapping pair of parentheses, which come in two placements that are exactly equivalent in effect: ```js (function () { /* ... */ })(); // call the parenthesized function (function () { /* ... */ }()); // parenthesize the whole call ``` The first is the more common style; the second is Crockford's preferred form, on the argument that the parentheses then wrap the complete unit that produces the value. Neither is more correct. Operators work too, because an operand is by definition an expression: ```js !function () { console.log('runs'); }(); // evaluates to false +function () { console.log('runs'); }(); // evaluates to NaN void function () { return 1; }(); // evaluates to undefined ``` These are terser by one character and were popular in minified code. They are worth recognising when you read them, but they change the value of the whole expression (`!` gives `false`, `void` gives `undefined`), so use them only where the value is discarded. An assignment or a `return` also supplies expression position, which is why the module pattern needs no extra wrapping punctuation beyond the parentheses convention: ```js const api = function () { return { ok: true }; }(); // legal, if unidiomatic ``` ## Arrow functions Arrow functions are always expressions, never declarations, so the *statement* rule does not apply to them — but the call still needs parentheses for a different, grammatical reason. A call expression is built on a member expression, and an arrow function is not one, so you cannot append `()` directly to an arrow: ```js (() => { console.log('hi'); })(); // fine () => { console.log('hi'); }(); // SyntaxError (async () => { await setup(); })(); // the async form, same shape ``` The async arrow IIFE is the modern reason people still reach for this shape: it gives you a scope in which `await` is legal inside code that cannot use a top-level await. ## The ASI trap and the leading semicolon Automatic semicolon insertion does *not* insert a semicolon before a line that begins with `(` — an open parenthesis can continue the previous expression as a call. So a semicolon-free line followed by an IIFE silently becomes one expression: ```js const y = makeThing() (function () { console.log('iife'); })() // parsed as makeThing()(function () {...})() -> TypeError at runtime ``` This fails at runtime, not parse time, and the error message points at the IIFE rather than at the missing semicolon, which is why it is confusing to debug. The defensive idiom is a leading semicolon, `;(function () {})()`, and it is the reason you see that stray semicolon at the top of older library files that were designed to be concatenated with other files. The same hazard applies to lines starting with `[` or a template literal backtick. ## Naming the function An IIFE can carry a name even though nothing calls it by that name: ```js (function setup() { throw new Error('boom'); })(); ``` The name is bound only inside the function's own scope, and it shows up in the stack trace, which is worth the four extra characters when the IIFE does real work at startup. The name of a *function expression* does not leak into the enclosing scope, which is the whole point. ## Passing arguments Because it is a call, an IIFE takes arguments, and older code exploited that to make globals local and short: `(function (window, document, undefined) { ... })(window, document);`. The `undefined` parameter is a historical guard from an era when the global `undefined` was writable; it is pointless in modern engines, where `undefined` is a non-writable global. Passing a namespace object in is still a live technique for script-level code.