DEV Community: Swaroop Jadhav

5 JavaScript Mistakes That Wasted Weeks of My Time (And How to Fix Them Fast)

Swaroop Jadhav — Wed, 27 May 2026 15:18:30 +0000

I made all five. Here's exactly what they cost me — so you don't have to find out the hard way.

I thought I was making progress.

I was writing JavaScript daily, finishing tutorials, feeling good. Then one afternoon my code started returning undefined for no reason I could see. Then [object Object] showed up where real data should have been. I stared at the screen for two hours, convinced something was deeply broken.

Nothing was broken. I was just making the same five mistakes on repeat — and nobody had told me they existed.

These aren't rare edge cases. Every beginner hits them. Knowing what they are before they bite you can save weeks of real frustration.

Here they are. No fluff.

Mistake #1 — The Loose Equality Trap (`==` vs `===`)

This one hides in plain sight.

Most beginners use == everywhere because it looks natural. The problem is that == tries to be "smart" — it converts types before comparing. Which leads to results that genuinely feel like the language is broken:

0 == '0'     // true  😬
0 == false   // true  😬
'' == false  // true  😬

JavaScript isn't broken. It's doing exactly what == was designed to do. That design is just genuinely confusing for newcomers.

✅ The Fix

Use === (strict equality) for every comparison. It checks both value and type:

0 === '0'     // false ✓
0 === false   // false ✓

Simple rule: If you catch yourself typing ==, stop and type === instead. There are very few real situations where you actually need ==.

Mistake #2 — Using `var` (and Not Understanding Why It Hurts)

If you've learned from older tutorials, you've seen var everywhere. It works — but it uses function scope, which means it leaks out of if blocks, loops, and places you'd expect it to stay contained:

for (var i = 0; i < 3; i++) {}
console.log(i); // 3  ← leaked outside the loop 😬

This causes subtle bugs that are genuinely hard to track down because the code looks fine.

✅ The Fix

Replace var with let or const — always.

Keyword	When to use
`const`	Value won't be reassigned (default choice)
`let`	Value will change
`var`	Never. Seriously.

for (let i = 0; i < 3; i++) {}
console.log(i); // ReferenceError ✓ (stays where you put it)

Default to const. Reach for let only when you need to reassign. Avoid var entirely.

Mistake #3 — Staying in Tutorial Hell 📺

This one isn't about syntax. It's about how you learn. And it's the mistake that cost me the most time.

Tutorials feel productive. You're watching code, nodding along, following each step. But when you close the tab and try to build something on your own — the screen goes blank.

That blank screen is the real test. And tutorials don't prepare you for it.

You're not actually learning when you watch. You're just following. The moment you hit an error you have to solve yourself — without a tutorial to rescue you — is the moment real learning starts.

✅ The Fix

For every 1 hour of learning → spend 2 hours building.

The project doesn't need to be impressive. It just needs to be yours:

Fetch data from a free API and display it on a page
Build a counter with increment and reset buttons
Make a to-do list without following any guide

I shared a beginner API project in my last post — a 10-line fetch that finally made APIs click for me. Check that out if you want a concrete first step.

Mistake #4 — Expecting JavaScript to Wait ⏳

This one breaks code silently — which makes it especially frustrating.

JavaScript doesn't pause for slow operations like fetching data from a server. It moves on immediately. So if you do this:

const data = fetchData();
console.log(data); // undefined 😬

You'll get undefined — not because something went wrong, but because the data simply hasn't arrived yet when console.log runs.

I spent a full afternoon confused by this exact thing. The code looked right. The URL was right. But the data was always undefined.

✅ The Fix

Use async/await to tell JavaScript to actually wait:

async function getData() {
  const response = await fetch('https://api.example.com');
  const data = await response.json();
  console.log(data); // real data, every time ✓
}

The await keyword pauses that function until the operation finishes, then continues. Once you understand why it exists, it stops feeling like magic and starts feeling completely obvious.

Mistake #5 — Trying to Memorise Everything 🧠

Early on, I thought being a good developer meant having every method and syntax rule memorised. So I'd spend time rereading notes instead of writing more code.

This is completely backwards.

No working developer has everything memorised. Senior engineers look things up constantly — MDN, Stack Overflow, documentation. That's not a weakness. That's just the job.

✅ The Fix

Stop measuring your skill by what you've memorised. Measure it by what problems you can solve.

Know where to look → MDN is the gold standard for JavaScript
Know the right questions to ask
Know how to read documentation and apply it

The goal is to think clearly about problems. The syntax comes with repetition — not with flashcards.

Quick Reference 📋

Mistake	Fix
Using `==`	Always use `===`
Declaring with `var`	`const` by default, `let` when needed
Watching without building	2 hours building per 1 hour learning
Ignoring async JS	Learn `async/await` early, not later
Trying to memorise syntax	Focus on problem-solving; look things up

Final Thought

If your console is full of red errors today — good.

That means you're in the part where the real learning happens. Every bug you fix is a pattern your brain now recognises forever. The confusion you feel right now isn't a sign that you're bad at this.

It's a sign that you're actually trying.

Which of these five have you hit? Or is there a sixth mistake that frustrated you more than any of these? Drop it in the comments — I'd genuinely like to know. 👇

— Swaroop | Documenting my journey into Full-Stack Development and automation. Building in public, one mistake at a time. 🚀

Stop Watching API Tutorials. Do This Instead.

Swaroop Jadhav — Tue, 19 May 2026 03:39:00 +0000

When I first started learning web development, I kept hearing the term API everywhere. I understood the textbook definition —

"A way for applications to communicate with each other."

But honestly? That didn't help much. I couldn't feel how it worked. So I kept watching tutorials, copying code, moving on. For weeks, APIs were this invisible, slightly intimidating thing happening somewhere behind the scenes.

This blog is about the moment that stopped — and exactly what broke it open for me.

01 — The Real Problem: I Was Stuck in Tutorial Mode

I could write JavaScript. I knew the basics. But every time APIs came up, I'd hit the same wall. The questions in my head went in circles:

Where does the data actually come from?
What is fetch() really doing under the hood?
Why do we even need .json() — isn't the response already data?
What happens if it fails? Does the whole page crash?

I'd watch a video, nod along, close the tab, and still feel like I didn't truly get it. The code made sense line by line — but the mental model wasn't there.

"I could read the recipe. I just couldn't taste the food."

So instead of watching another tutorial, I decided to build something tiny and deliberately simple. No framework. No boilerplate. Just me, a browser console, and a free API.

02 — The Project: Fetching a Random User — That's It

I picked the simplest API I could find: randomuser.me. It gives you a random fake person — name, email, location — every time you hit it. No API key. No setup. Just a URL.

The goal was intentionally tiny: fetch one user, log their first name to the console. Nothing rendered. Nothing fancy. Just proof that I could ask for data and get it back.

Here's the exact code I wrote:

fetch('https://randomuser.me/api/')
  .then(response => response.json())   // ← this line changed everything
  .then(data => {
    console.log(data.results[0].name.first);
  })
  .catch(error => console.log(error));

I ran it. A name appeared in the console.

I ran it again. A different name.

I sat there for a second and ran it a third time just to be sure.

That's when the wall cracked.

03 — The Breakdown: What's Actually Happening, Line by Line

Here's what made the mental model finally lock in — understanding each piece not as syntax, but as a conversation:

`fetch(url)`

You're knocking on a server's door and asking for something. Think of it as: "Hey, can you send me some data?" — the browser sends that request out over the internet.

`.then(response => response.json())`

The server answers — but the answer is wrapped, like a letter in an envelope. .json() opens the envelope. Before this line, you just have a blob of bytes. After it, you have a real JavaScript object you can work with.

This step isn't optional. It's the translation.

`.then(data => { ... })`

Now the data is in your hands. data.results[0].name.first is just navigating a JavaScript object — the same dot notation you already know. The API didn't do magic. It handed you a structured object.

`.catch(error => ...)`

If the server doesn't answer, the URL is wrong, or there's no internet — this catches it. Graceful failure instead of a silent crash.

04 — The Click: What Actually Changed

The insight wasn't in the code itself. It was in seeing it work — and realising how ordinary it was. Here's what I understood that I couldn't before:

An API is just a URL that gives back data when you ask nicely.
fetch() is literally just making a request — like typing a URL in your browser, but in code.
The response isn't data yet. .json() converts it. That step is the translation, not a formality.
Once you have the object, you navigate it with dot notation you already know.
That's the whole thing. The mystery was just unfamiliarity.

Once this clicked, I started seeing APIs everywhere — weather apps, login systems, payment flows, social feeds. Same pattern, different data. The intimidation was gone because the mental model was finally there.

05 — Where to Go Next: Three Small Experiments to Try

Don't read more about APIs. Build more with them. These three modifications to the same code will teach you more than another hour of tutorials:

Experiment	What to do	Why it helps
Log the full name	Combine `name.first` and `name.last`	Practice navigating the response object
Display the avatar	Grab `picture.large`, render an `<img>` tag	Move output from console to the actual page
Add a refresh button	Trigger a new `fetch()` on click	Understand how to wire JS to UI events

Each one forces you to navigate the response object differently — and that repetition is where the understanding solidifies.

Final Thought

The fastest path to understanding something isn't a better tutorial. It's a smaller project — one where you can see exactly what each line does.

Build something small. Break it. Fix it.

That one loop will clear more confusion than ten videos ever could.

If this clicked for you, try one of the experiments above and share what you built. The best way to learn is to show your work.

— Swaroop | Sharing my journey into Full-Stack Development and automation

DEV Community: Swaroop Jadhav

5 JavaScript Mistakes That Wasted Weeks of My Time (And How to Fix Them Fast)

I made all five. Here's exactly what they cost me — so you don't have to find out the hard way.

Mistake #1 — The Loose Equality Trap (== vs ===)

✅ The Fix

Mistake #2 — Using var (and Not Understanding Why It Hurts)

✅ The Fix

Mistake #3 — Staying in Tutorial Hell 📺

✅ The Fix

Mistake #4 — Expecting JavaScript to Wait ⏳

✅ The Fix

Mistake #5 — Trying to Memorise Everything 🧠

✅ The Fix

Quick Reference 📋

Final Thought

Stop Watching API Tutorials. Do This Instead.

01 — The Real Problem: I Was Stuck in Tutorial Mode

02 — The Project: Fetching a Random User — That's It

03 — The Breakdown: What's Actually Happening, Line by Line

fetch(url)

.then(response => response.json())

.then(data => { ... })

.catch(error => ...)

04 — The Click: What Actually Changed

05 — Where to Go Next: Three Small Experiments to Try

Final Thought

Mistake #1 — The Loose Equality Trap (`==` vs `===`)

Mistake #2 — Using `var` (and Not Understanding Why It Hurts)

`fetch(url)`

`.then(response => response.json())`

`.then(data => { ... })`

`.catch(error => ...)`