JavaScript Syntax Fundamentals

If you’ve been going through this JavaScript series with us, you already know how the engine works under the hood and how the call stack processes your code. We went through all of that in How JavaScript Runs. And in Your First JavaScript Program, we started writing actual code.

But there’s a layer we haven’t talked about yet: the grammar. The rules the JavaScript interpreter uses to figure out what you’re actually trying to say.

This is where statements, expressions, and the whole semicolons question live. And honestly, this is one of those topics that saves you a lot of confusion later. The kind of confusion where your code looks completely fine but returns undefined out of nowhere, or throws an error on a line you didn’t even touch.

Let’s walk through it properly.

01What Is a Statement in JavaScript, Anyway?

A statement is a complete instruction. It’s a full unit of work that JavaScript can execute.

Think of it like a sentence. A sentence in English has a subject, a verb, maybe an object, and it expresses a complete thought. A statement in JavaScript is similar, it does one complete thing.

let score = 0;           // declares a variable: one complete instruction
score = score + 10;      // updates that variable: another complete instruction
console.log(score);      // prints it out: complete instruction

if (score > 5) {         // decides what to do: complete instruction
  console.log("Passed!");
}

Each of those lines (or blocks) is a statement. They all do something. They’re instructions JavaScript can follow.

One thing worth knowing: statements don’t produce a value you can use elsewhere. You can’t do this:

// This doesn't work: you can't assign a statement to a variable
let x = if (true) { 5 }; // SyntaxError

That fails. An if block is a statement, not something that produces a value. Keep that in mind, it’ll make sense when we compare with expressions in a moment.

02The Types of Statements Worth Knowing

Not all statements are the same. There are a few categories that show up in almost every JavaScript file you’ll ever read:

Declaration Statements

These introduce something new into your code. A variable, a function, a class.

let username = "Daniyal";      // variable declaration
const MAX_SCORE = 100;         // constant declaration
var oldWay = "still works";    // var (older style, still around)

function greet(name) {         // function declaration
  console.log("Hey, " + name);
}

class Player {                 // class declaration
  constructor(name) {
    this.name = name;
  }
}

The keyword at the start (let, const, var, function, class) is what makes these declaration statements.

Control Flow Statements

These tell JavaScript which direction to go: run this block, skip that one, repeat until something is true.

// if / else
if (score >= 50) {
  console.log("Passed");
} else {
  console.log("Try again");
}

// for loop
for (let i = 0; i < 3; i++) {
  console.log(i);
}

// while loop
while (score < 100) {
  score += 10;
}

// switch
switch (grade) {
  case "A": console.log("Excellent"); break;
  case "B": console.log("Good"); break;
  default:  console.log("Keep going");
}

Jump Statements

These change the flow mid-execution: stop the loop, exit the function, or throw an error.

function checkAge(age) {
  if (age < 0) {
    throw new Error("Age can't be negative"); // throw statement
  }
  if (age < 18) {
    return false; // return statement: exits the function here
  }
  return true;
}

for (let i = 0; i < 10; i++) {
  if (i === 5) break;    // break statement: exits the loop
  if (i % 2 === 0) continue; // continue statement: skips to next iteration
  console.log(i);
}

These are the building blocks of almost every program you'll write. Now let's look at the other half: expressions.

03What Is an Expression in JavaScript?

An expression is any piece of code that produces a value. If it evaluates to something, it's an expression.

A simple test: can you assign it to a variable? If yes, it's an expression.

// All of these are expressions, they all produce a value

5 + 3                    // produces 8 (arithmetic expression)
"hello" + " world"       // produces "hello world" (string concatenation)
true && false            // produces false (logical expression)
score > 50               // produces true or false (comparison expression)
"hello"                  // produces "hello" (literal expression)
score                    // produces whatever score holds (identifier expression)
Math.random()            // produces a number (function call expression)
user.name                // produces a string (member access expression)
isLoggedIn ? "Hi" : "Login" // produces one of two values (ternary expression)

Notice what they all have in common: every single one resolves to something. A number, a string, a boolean, an object. Something.

You can assign any of these to a variable because they produce a value:

let result   = 5 + 3;                      // 8
let greeting = "hello" + " world";         // "hello world"
let isAdult  = age >= 18;                  // true or false
let random   = Math.random();              // a number
let name     = user.name;                  // whatever user.name holds
let label    = isLoggedIn ? "Hi" : "Login"; // one of two strings

That's the key property of expressions: they evaluate to a value you can work with.

04Expression Statements: Where Things Get Interesting

Here's where a lot of beginners get confused. And honestly, it tripped me up for a while too.

Expressions can be used as statements. When you take an expression and use it as a complete line of instruction, it becomes an expression statement.

The most common example:

console.log("hello");   // function call expression, used as a statement
score++;                // increment expression, used as a statement
myArray.push(99);       // method call expression, used as a statement
x = 10;                 // assignment expression, used as a statement

console.log("hello") is technically an expression. It produces a value (it returns undefined). But when you write it on its own line with a semicolon at the end, you're using it as a statement, a complete instruction to "do this thing."

Statements can't be used as expressions. But expressions can be used as statements. That's the asymmetry worth remembering.

Now let's test yourself before we move on:

05How the JavaScript Interpreter Actually Reads Your Code

We touched on this in the JavaScript engine article, but here's the part that's relevant to syntax: when JavaScript reads your code, it needs to figure out where one statement ends and another begins.

The process goes roughly like this:

Step 1, Tokenizing: Your code gets broken down into smallest meaningful pieces. Keywords, variable names, operators, symbols. The line let x = 5; becomes the tokens: let, x, =, 5, ;.

Step 2, Parsing: Those tokens get arranged into a tree structure called an Abstract Syntax Tree (AST). This is where JavaScript figures out the grammar: what's a declaration, what's an expression, what's a block, what's an argument.

Step 3, Execution: The engine runs through that tree and executes the instructions.

During parsing, the interpreter needs to know where one statement ends. The semicolon is the official signal for that. It says: this statement is done. Start the next one.

But here's where things get interesting: JavaScript doesn't always require you to write that semicolon. It can figure it out on its own. Most of the time.

06The Semicolons Question in JavaScript: Both Sides Are Right

If you've spent any time in JavaScript communities, you've seen this debate. Some developers use semicolons everywhere. Others use none at all. And both approaches produce working code.

Here's the honest take: this isn't really about aesthetics. It's about understanding what JavaScript does when you don't write a semicolon. Once you understand that, you can make an informed choice instead of just copying whatever style the first codebase you worked in used.

The "always use semicolons" crowd says they make the code's intent explicit, they prevent certain classes of bugs, and some tools and linters expect them.

The "no semicolons" crowd says the code looks cleaner, JavaScript handles it automatically, and you can sidestep some problems by being deliberate about code style.

Neither side is wrong. But both sides depend on something called Automatic Semicolon Insertion. And that's what we're going to dig into now.

07Automatic Semicolon Insertion in JavaScript: What's Actually Happening

Automatic Semicolon Insertion, or ASI, is a feature of the JavaScript parser. When it encounters a situation where the code doesn't make sense grammatically without a semicolon at a line break, it inserts one on your behalf.

Simple example:

// What you write:
const name = "Daniyal"
const age = 25
console.log(name, age)

// What JavaScript actually processes (ASI adds ; at each line break):
const name = "Daniyal";
const age = 25;
console.log(name, age);

JavaScript sees the end of the first line, notices the next token (const) can't legally follow whatever's on this line, and inserts a semicolon. Clean, automatic, invisible.

This works great for the majority of everyday code. The problems come in specific situations.

The Three Rules Behind ASI

The ECMAScript specification defines exactly when ASI applies. There are three core rules:

There's also a fourth rule that matters a lot in practice. The spec calls these "restricted productions." For a specific set of keywords, a semicolon is always inserted at a line break, no exceptions. Those keywords are: return, throw, break, continue, and postfix ++ / --.

That last group is where silent bugs live.

08When ASI Creates Silent Bugs in Your JavaScript Code

This is the section that matters most. ASI is helpful 99% of the time. The remaining 1% is where it quietly does the wrong thing, and your code breaks in a way that's genuinely difficult to debug.

Here are the real cases to know about:

The Return Bug: The Most Common ASI Trap

You write a function that returns an object. You put the opening { on the next line for readability. JavaScript silently returns undefined instead of your object. No error. Just wrong output.

// BROKEN: ASI inserts a ; after "return" because of the line break
function getConfig() {
  return
  {
    theme: "dark",
    debug: true
  }
}

console.log(getConfig()); // undefined, NOT the object you wrote

// CORRECT: the opening { starts on the same line as return
function getConfig() {
  return {
    theme: "dark",
    debug: true
  }
}

console.log(getConfig()); // { theme: "dark", debug: true } ✓

This one gets developers with years of experience. The rule is simple: never put return on a line by itself if you're returning something. Put the opening brace (or the value) on the same line.

The Line-Starting Bracket Trap

Lines that start with [ or ( don't trigger ASI. JavaScript treats them as a continuation of the previous line. This one is less obvious:

// BROKEN: no semicolon before the [ on line 4
const a = 1
const b = 2

[a, b].forEach(n => console.log(n))

// JavaScript reads this as:
// const b = 2[a, b].forEach(n => console.log(n))
// TypeError: Cannot read properties of undefined

JavaScript sees 2 followed by [ and thinks you're trying to access an array index. It doesn't insert a semicolon because that's a perfectly legal token sequence.

// FIXED option 1: semicolon at the end of line 2
const a = 1
const b = 2;

[a, b].forEach(n => console.log(n))

// FIXED option 2: defensive leading semicolon (common pattern)
const a = 1
const b = 2

;[a, b].forEach(n => console.log(n))

The leading semicolon on the last line looks odd at first but it's a known defensive pattern used by developers who prefer semicolon-free code. It essentially says: whatever came before ends here.

The Same Problem with Parentheses

Same idea, but with (. Immediately Invoked Function Expressions (IIFEs) can trigger this if you're not careful:

// BROKEN: JavaScript reads this as: const x = 5(function() {...})()
const x = 5

(function() {
  console.log("runs fine... except it doesn't")
})()

// TypeError: 5 is not a function

// FIXED: semicolons make the boundary explicit
const x = 5;

(function() {
  console.log("this one runs correctly")
})();

Now let's see all of this in an interactive format:

const name = "Daniyal";
const age  = 25;
const score = 88;

console.log(name, age, score);

function getConfig() {
  return;      // ← ASI inserts ; here because of the line break
  {
    theme: "dark",
    debug: true
  }
}

console.log(getConfig());   // prints: undefined

const a = 1;
const b = 2    // ← NO semicolon here! [ on next line continues this

[a, b].forEach(n => console.log(n));

// JavaScript actually reads lines 2-4 as:
// const b = 2[a, b].forEach(n => console.log(n))
// TypeError: Cannot read properties of undefined

09The Habits That Actually Protect You

Understanding ASI is one thing. Building the habits that keep you safe is the practical part. Here's what experienced JavaScript developers actually do:

Habit 1: Pick a Style and Commit to It Completely

The issues come from inconsistency, not from the choice itself. If you use semicolons, use them everywhere. If you don't, be deliberate about it. Don't mix.

// Style 1: Always use semicolons (explicit and predictable)
const x = 10;
const y = 20;
console.log(x + y);
[x, y].forEach(n => console.log(n)); // no ambiguity

// Style 2: No semicolons (clean, relies on ASI intentionally)
const x = 10
const y = 20
console.log(x + y)
;[x, y].forEach(n => console.log(n)) // defensive leading semicolon

Habit 2: The Return Rule is Non-Negotiable

Whatever style you use, always keep the opening brace or the returned value on the same line as return. This is the one rule that trips up even senior developers. The same applies to throw.

// NEVER do this (with or without semicolons)
function getUser() {
  return
  { id: 1, name: "Daniyal" } // unreachable: ASI already inserted ; after return
}

// ALWAYS do this
function getUser() {
  return {
    id: 1,
    name: "Daniyal"
  };
}

// Same rule applies to throw
function validate(value) {
  if (!value) {
    throw new Error("Value is required"); // opening token on same line ✓
  }
}

Habit 3: Defensive Semicolons Before Risky Characters

If you prefer semicolon-free code, add a defensive semicolon before any line that starts with (, [, or a template literal backtick. These three characters are the ones that can chain with the previous line.

const list = [1, 2, 3]
const prefix = "item"

// Defensive semicolons before the risky characters
;[...list].map(n => prefix + n).forEach(console.log)
;(async function() { await doSomething() })()

Habit 4: Use a Linter

ESLint is the standard for JavaScript. It catches ASI-related issues automatically and can enforce whichever semicolon style your project uses. If you're on a team, a shared ESLint config means everyone writes consistent code without having to think about it.

Most code editors have ESLint integration. It underlines the problem before you even run the code.

10Putting It All Together

Here's a quick summary to anchor everything:

Statements are complete instructions. They do something. Declaration statements introduce variables and functions. Control flow statements direct execution. Jump statements exit or redirect. They don't produce a usable value.

Expressions produce a value. Arithmetic, comparisons, function calls, property access. If you can assign it to a variable, it's an expression. Expressions can be used as statements (expression statements), but statements can't be used as expressions.

Semicolons signal the end of a statement. You can write them yourself or let ASI handle it. ASI is reliable in everyday code but has specific traps around return (and related keywords) and lines that start with (, [, or `.

The habits that matter: pick a consistent style, never put return alone on a line, and use a linter. That's genuinely it. Once these patterns are in your hands, you stop making the category of bugs that show up silently and take an hour to track down.

Next up in this series: JavaScript Comments. We'll go beyond the basics and cover JSDoc comments, when comments actually help vs when they get in the way, and the habits that make your code readable months later. It's one of those topics that sounds simple but has a lot of practical depth.