Common JavaScript Mistakes Beginners Make

Certain JavaScript mistakes trip up nearly every beginner at least once. This guide covers the most common ones, why they happen, and how to avoid them going forward.

If you’ve worked through this entire JavaScript Basics series, you’ve likely already encountered a few of these. This guide names them explicitly, closing out the fundamentals covered throughout the series.

Confusing = with ===

According to W3Schools’ list of common JavaScript mistakes, accidentally using the assignment operator instead of a comparison operator in a condition is one of the most frequent beginner errors:

let name = "Alex";
if (name = "John") {
  console.log("Hello John"); // Always runs — this assigns, not compares!
}

Fix: Always use === for comparisons. Some editors and linters flag this automatically, which is one more reason to set one up early.

Confusing == with ===

Loose equality (==) converts types before comparing, sometimes producing surprising results:

console.log(5 == "5");  // true — types converted
console.log(5 === "5"); // false — types must match

Fix: Default to === everywhere, as covered in our if/else guide, to avoid this category of confusion entirely.

Mixing Up + for Addition and Concatenation

According to GeeksforGeeks’ rundown of common mistakes, the + operator handles both addition and string concatenation, which causes confusion when a variable’s type isn’t what you expect:

console.log(10 + "5"); // "105" — number converted to string
console.log(10 + 5);   // 15

Fix: Convert explicitly with Number() or String() when you’re not certain what type a value actually is, especially with user input, which always arrives as a string.

Forgetting var Is Function-Scoped, Not Block-Scoped

Covered in depth in our var/let/const guide — using var inside a block can leak the variable outside where you expected it to stay contained.

Fix: Default to const, use let only when reassignment is needed, and avoid var in new code entirely.

Poorly Named Variables

According to freeCodeCamp’s list of common JavaScript mistakes, names like thing1, tmp, or x give no context about what a variable actually holds, making code significantly harder to read and debug later — including for the person who originally wrote it.

// Unclear
const arr = ["James", "Jess"];
let str = "";

// Clear
const names = ["James", "Jess"];
let initials = "";

Forgetting `this` Inside Object Methods

Accessing a property directly by name inside a method, instead of through this, produces a ReferenceError:

const person = {
  name: "Alice",
  greet() {
    console.log(name); // ReferenceError
  }
};
// Fix: console.log(this.name);

Learning Frameworks Before JavaScript Fundamentals

A recurring theme in beginner advice: jumping into React or Vue before understanding vanilla JavaScript tends to slow overall progress, since frameworks build directly on the fundamentals covered throughout this series — variables, functions, arrays, the DOM. Solid fundamentals make framework concepts click faster, not slower.

Modifying an Array or Object While Looping Through It

Removing or adding items to an array while iterating over it with a standard for loop can cause items to be skipped or processed twice, since the indices shift as the array changes size mid-loop:

const numbers = [1, 2, 3, 4, 5];
// Risky: modifying while looping
for (let i = 0; i < numbers.length; i++) {
  if (numbers[i] % 2 === 0) {
    numbers.splice(i, 1); // shifts remaining items, skips one
  }
}

Fix: Build a new array with filter() instead of mutating the original array mid-loop, or loop through a copy of the array if mutation is genuinely necessary.

Forgetting That Arrays and Objects Are Passed by Reference

Assigning an array or object to a new variable doesn't create a copy — both variables point to the exact same underlying data:

const original = [1, 2, 3];
const copy = original;
copy.push(4);
console.log(original); // [1, 2, 3, 4] — original changed too!

Fix: Use [...original] (the spread operator) or Array.from(original) to create a genuine copy when you need one, rather than a second reference to the same data.

Not Handling Asynchronous Code Correctly

Code that fetches data or waits on a timer doesn't pause execution — the rest of your script keeps running immediately, before that data arrives:

let data;
fetch("https://api.example.com/data")
  .then(response => response.json())
  .then(result => { data = result; });

console.log(data); // undefined — fetch hasn't finished yet

Fix: Work with the data inside the .then() callback (or using async/await, a related pattern worth exploring once basic asynchronous concepts feel comfortable), rather than expecting it to be immediately available on the next line.

Comparing Objects or Arrays Directly

Even with identical contents, two separately created objects or arrays are never considered equal with ===, since it compares references, not contents:

console.log([1, 2] === [1, 2]); // false — different objects in memory

Fix: Compare specific properties individually, or use a dedicated deep-comparison approach (like JSON.stringify() for simple cases) when you genuinely need to check whether contents match.

Common Questions

How do I catch these mistakes before running my code? A linter (covered in our VS Code extensions guide) flags many of these automatically as you type, well before you'd otherwise discover them at runtime.

Are these mistakes a sign I'm not cut out for programming? No — they're genuinely universal. Every experienced developer made every one of these mistakes early on; recognizing and fixing them quickly is the actual skill being built.

Quick-Reference Guide

• = vs === — assignment vs. comparison; always use === in conditions.
• == vs === — loose vs. strict equality; default to strict.
• + operator — can mean addition or concatenation depending on type.
• var scope leaks — use const/let instead.
• Descriptive names — avoid tmp, x, thing1.
• this inside methods — needed to access an object's own properties.

Conclusion

These mistakes are universal — recognizing them by name, rather than being surprised each time, turns a frustrating debugging session into a quick, familiar fix. Combined with the fundamentals covered throughout this JavaScript Basics series, you now have a genuinely solid foundation to keep building on.

Explore More JavaScript Basics Guides →

Alex Carter

When not writing, Alex is probably debugging someone else’s code.