JavaScript Statements and Expressions Explained

The Distinction, Precisely

JavaScript has two kinds of syntax at the top level of a program. One describes values; the other describes actions.

// Expressions — each produces a value
2 + 3                      // 5
'hello'                    // a string
user.name                  // whatever the property holds
isReady ? 'yes' : 'no'     // one of two strings
[1, 2, 3]                  // an array
{ a: 1 }                   // an object (in expression position)
function () {}             // a function
() => 42                   // an arrow function
Math.max(1, 2)             // a function call

// Statements — each performs an action
let x = 5;                 // declares a variable
if (x > 3) { }             // branches
for (let i = 0; i < 3; i++) { }   // loops
function greet() { }       // declares a function
return;                    // returns from a function
throw new Error('oops');   // throws
try { } catch (e) { }      // handles an error

Every Kind of Expression

Expressions are the larger category in most code. Almost everything you write between operators is an expression. Here are the categories, with examples.

See them all evaluate

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Expressions</title>
    <style>
        body { font-family: system-ui, sans-serif; padding: 24px; background: #f8fafc; font-size: 14px; margin: 0; }
        .row {
            background: #fff; border: 1px solid #e2e8f0; border-radius: 10px;
            padding: 10px 14px; margin-bottom: 6px;
            display: flex; justify-content: space-between; gap: 14px;
            font-family: ui-monospace, monospace; font-size: 12.5px;
        }
        .expr { color: #64748b; }
        .val  { color: #0891b2; font-weight: 700; }
    </style>
</head>
<body>

    <div id="output"></div>

    <script>
        const user = { name: 'Ada', age: 36 };
        const isReady = true;

        // Each of these is an expression — it produces a value
        const expressions = [
            ['42',                    42],
            ['"hello"',               'hello'],
            ['true',                  true],
            ['2 + 3',                 2 + 3],
            ['10 % 3',                10 % 3],
            ['user.name',             user.name],
            ['isReady ? "yes" : "no"', isReady ? 'yes' : 'no'],
            ['[1, 2, 3]',             JSON.stringify([1, 2, 3])],
            ['{ a: 1 }',              JSON.stringify({ a: 1 })],
            ['`Hi, ${user.name}`',    `Hi, ${user.name}`],
            ['Math.max(1, 5, 3)',     Math.max(1, 5, 3)],
            ['(() => 42)()',          (() => 42)()]
        ];

        const out = document.getElementById('output');
        expressions.forEach(function (pair) {
            const div = document.createElement('div');
            div.className = 'row';
            div.innerHTML =
                '<span class="expr">' + pair[0] + '</span>' +
                '<span class="val">' + String(pair[1]) + '</span>';
            out.appendChild(div);
        });
    </script>

</body>
</html>

Each line in that list produces a value. The value might be a number, a string, an array, an object, or a function — but there is always something on the right side. That is what makes it an expression.

Every Kind of Statement

Statements describe actions. They run in order, they can contain other statements, and they change what happens next.

A function declaration is a statement

This is the one that surprises people most. function greet() {} at the top level of a script is a statement. It does not produce a value. It registers a function and moves on.

// A function declaration — a statement
function greet(name) {
    return 'Hello, ' + name;
}

// It cannot be used as a value:
// const x = function greet(name) {};   ← this is a function expression

// But it can be called, because the declaration
// registered the name `greet` in scope.
greet('Ada');

A function expression, on the other hand, is a value. It can be assigned, passed, returned, or called immediately.

// A function expression — produces a function value
const greet = function (name) {
    return 'Hello, ' + name;
};

// An arrow function expression — also a value
const greet2 = (name) => 'Hello, ' + name;

// Passed as an argument, because it is a value
[1, 2, 3].forEach(n => console.log(n));

// Returned from a function, because it is a value
function makeGreeter() {
    return (name) => 'Hi, ' + name;
}

The Bridge: Expression Statements

Almost every expression can also be written as a statement, by placing it on its own line. This is called an expression statement, and it is how most lines of JavaScript actually work.

// A function call as an expression statement
console.log('hello');

// An assignment as an expression statement
total = price * quantity;

// A method call
list.push(4);

// An increment
i++;

// Each of these produces a value —
// but the value is discarded, because
// the point was the side effect.

When you write a function call on its own line, you are technically writing an expression followed by a semicolon. The expression produces a value; the statement says “evaluate this and move on.” The value is thrown away unless you use it.

Two expressions cannot be statements

Almost every expression works as a statement, but two do not. Both are about how the parser decides what a line means before it knows what you intended.

Both are fixed by wrapping the expression in parentheses, which tells the parser to expect a value.

// A block, not an object literal
{
    a: 1;
}

// An object literal, because of the parentheses
({ a: 1 });

// A syntax error — the parser expects a name
// function () {}

// A function expression, wrapped in parentheses
(function () {});

// Called immediately — this is an IIFE
(function () {
    console.log('runs now');
})();

Where the Distinction Matters in Practice

The boundary between statements and expressions is not academic. It explains several specific behaviors that would otherwise seem arbitrary.

1. Arrow function bodies

An arrow function has two forms, and the choice changes whether a value comes back.

2. Returning an object from an arrow function

This is where the two traps combine. An arrow function that returns an object needs parentheses around the object literal, because the opening brace would otherwise be treated as a block.

// Incorrect — the braces are a block, not an object
const makeUser = () => { name: 'Ada' };

makeUser();   // undefined

// Correct — wrapped in parentheses, so it is an expression
const makeUser2 = () => ({ name: 'Ada' });

makeUser2();  // { name: 'Ada' }

// Or use an explicit return in a block body
const makeUser3 = () => {
    return { name: 'Ada' };
};

3. Template literal placeholders

The ${ } placeholder in a template literal expects an expression. A statement inside it is a syntax error.

4. Hoisting

Function declarations are hoisted completely. Function expressions — including arrow functions assigned to const — are not. This is a direct consequence of one being a statement and the other an expression.

// Works — the declaration is hoisted
sayHi();
function sayHi() { console.log('hi'); }

// Fails — the arrow function is an expression,
// and `const` variables are not accessible
// before their declaration line
sayBye();
const sayBye = () => console.log('bye');

// ReferenceError: Cannot access 'sayBye'
// before initialization

5. Conditional declarations

You cannot conditionally declare a function with the declaration syntax inside a block in a predictable way. But you can conditionally assign a function expression, because an assignment is a statement whose right side is a value.

Blocks vs Object Literals

This single ambiguity causes more confusion than anything else on the topic. The same characters mean two different things depending on where they appear.

The rule

The classic example

// This is a block. It runs and does nothing visible.
{
    name: 'Ada'
}

// The braces were a block.
// Inside, `name:` was a label,
// and 'Ada' was an expression
// statement. No object was created.

// This creates an object.
const user = { name: 'Ada' };

// And this one — wrapped in parentheses —
// is an expression, so it creates an object
// that is then discarded.
({ name: 'Ada' });

A label is a rarely used feature that lets you name a statement so break or continue can refer to it. Inside a block, name: is read as a label, not as an object key.

Statements, Semicolons, and ASI

A statement usually ends with a semicolon. JavaScript has a feature called Automatic Semicolon Insertion — ASI — that inserts the semicolon for you in most situations. It is convenient, but the rules occasionally guess wrong.

// Works without semicolons
const a = 1
const b = 2

// Breaks — ASI joins the lines instead
const c = 1
const d = 2
[1, 2, 3].forEach(n => console.log(n))

// The parser sees: const d = 2[1, 2, 3].forEach(...)
// Because a line starting with [ continues the previous one.

The same problem occurs with a line starting with (, `, +, or -. Each one can continue the previous statement instead of starting a new one.

Statement completion values

In a browser console or inside eval(), a statement can produce a completion value — the value the console prints back to you. This is a limited special case, not something ordinary code can use.

// In the browser console:
2 + 3
// ← 5      the console displays the completion value

let x = 5;
// ← undefined   a declaration produces no value

// But in a real script:
// const y = if (true) {};    ← syntax error
// Statements cannot be assigned.

The Comma Operator

The comma has two entirely separate roles in JavaScript, and only one of them is an operator.

// The comma as a separator — in a list
const a = 1, b = 2, c = 3;              // declarations
fn(1, 2, 3);                            // arguments
const arr = [1, 2, 3];                  // array elements
const obj = { x: 1, y: 2 };             // object properties

// The comma as an operator — evaluates left to right
// and returns the value of the last expression
const result = (1 + 1, 2 + 2, 3 + 3);
// result is 6 — the first two are evaluated and discarded

// Common in a for loop header
for (let i = 0, j = 10; i < j; i++, j--) {
    // i and j move toward each other
}

The comma operator is rarely useful and often harms readability. It appears in loop headers and occasionally in minified output, and almost nowhere else.

Class and Module Declarations

The same statement-versus-expression pattern appears in two more places you will meet regularly.

Classes

// A class declaration — a statement
class User {
    constructor(name) { this.name = name; }
}

// A class expression — a value
const User2 = class {
    constructor(name) { this.name = name; }
};

// Named class expression
const User3 = class NamedUser { };

// Because it is an expression, it can be
// passed or returned
function createClass() {
    return class { greet() { return 'hi'; } };
}

Class declarations are hoisted but not initialized. That means the name exists in scope from the top of the block, but any attempt to use it before its declaration line throws a ReferenceError — the temporal dead zone.

Modules

// Import declarations — statements
import { formatPrice } from './utils.js';
import defaultExport from './app.js';

// Export declarations — statements
export const TAX_RATE = 0.2;
export function formatTotal(value) { /* ... */ }

// Export as an expression — a statement with an expression inside
export default function () { }

// Dynamic import — an expression, so it can be awaited
const module = await import('./chart.js');

Static import and export are statements. They must appear at the top level of a module, not inside a block or a condition. import(), on the other hand, is a function-like expression that returns a promise — which is why it can be used inside an async function or a conditional.

Common Mistakes

Every one of these is a symptom of the statement-versus-expression distinction. They are the errors that come up most often.

1. An arrow function with braces and no return

2. Returning an object without parentheses

3. A statement inside a template literal placeholder

4. A bare object literal on its own line

5. Using a function expression before it is defined

6. Confusing the comma separator with the comma operator

7. A missing semicolon before a line that starts with a bracket

8. Expecting a statement to have a value

Best Practices

These follow directly from the distinction. None of them is enforced by the language, but each one removes a category of confusion.

Key Takeaways

• An expression produces a value; a statement performs an action.
• The test: if it can go on the right of =, it is an expression.
• Function and class declarations are statements; function and class expressions are values.
• A function declaration is hoisted; a function expression assigned to const is not.
• An expression statement is an expression written on its own line — the value is discarded.
• Two expressions cannot be statements: one starting with {, one starting with function.
• Wrapping in parentheses forces expression context — that is why IIFEs need them.
• An arrow function with braces has a statement body and needs an explicit return.
• An arrow returning an object needs parentheses: () => ({ ... }).
• Template literal placeholders expect expressions, not statements.
• The comma is a separator in lists and an operator in expressions — the two behave differently.
• Write semicolons and let a formatter handle the rest.

What to Learn Next

Now that the two categories are clear, the next step is the language around them. Start with JavaScript Syntax Explained and JavaScript Functions Explained.

From there, explore JavaScript Operators, JavaScript Conditionals, and JavaScript Loops. For the execution model underneath, read How JavaScript Works and JavaScript Hoisting Explained.

If you are still connecting the pieces, read What Is JavaScript?, How to Add JavaScript to HTML, and JavaScript Comments for the surrounding context.

Practice Challenge

The fastest way to internalize the distinction is to try to use each construct as a value and watch what happens. This exercise takes about twenty minutes.

1. Create index.html and app.js, and load the script with <script src="app.js" defer></script>.
2. In app.js, write five expressions on separate lines — a literal, an arithmetic expression, a ternary, an array literal, and an object literal assigned to a const. Log each one.
3. Now try to assign an if statement to a const. Read the syntax error.
4. Try to assign a for loop to a const. Read the syntax error.
5. Write an arrow function with an expression body and confirm it returns a value. Add braces and confirm it now returns undefined. Add an explicit return and confirm it works again.
6. Write an arrow function that returns an object without parentheses. Confirm the result is undefined. Fix it with parentheses.
7. Write a bare object literal on its own line with no assignment. Refresh. Note that no error occurs and no object is created.
8. Wrap that same object in parentheses. Confirm it is now treated as a value.
9. Write an IIFE. Remove the wrapping parentheses and read the syntax error. Put them back.
10. Put an if statement inside a template literal placeholder. Read the syntax error. Replace it with a ternary and confirm it works.
11. Call a function declaration before its line and confirm it works. Do the same with a function expression assigned to const and read the ReferenceError.
12. Finally, open DevTools and type each expression into the console one at a time. Note how the console prints the value back for an expression, and undefined for a declaration.

If you complete those steps, you have produced four different syntax errors by hand, watched an arrow function silently return undefined, seen a bare object literal do nothing at all, and confirmed in the console that declarations have no value. Once you have caused each of these failures yourself, the rule behind them stops being something you memorize and becomes something you recognize instantly.