DEV Community: Osama Abu Motlaq

I Learned React Before I Truly Understood JavaScript — Here's What Happened

Osama Abu Motlaq — Wed, 26 Aug 2026 18:02:31 +0000

If you're learning web development today, there's a good chance your journey looks something like this:

HTML → CSS → JavaScript → React → Next.js

At least, that's how it is supposed to go.

But what if you skip the part where you truly understand JavaScript?

That's exactly what I did.

I learned React before I had a solid understanding of JavaScript, and at first, it felt like I was making incredible progress.

I could build components.

I could use useState.

I could fetch data.

I could create forms.

I could build pages that looked like real applications.

Everything seemed fine.

Until it wasn't.

Eventually, I started encountering problems that React couldn't explain for me.

And that's when I realized something important:

I wasn't struggling with React. I was struggling with JavaScript.

React Made Me Feel Like I Was Progressing

When you start learning React, the progress can feel exciting.

You write:

function App() {
  return <h1>Hello World</h1>;
}

Then you learn components:

function UserCard({ user }) {
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

Then state:

const [count, setCount] = useState(0);

Then effects:

useEffect(() => {
  fetchUsers();
}, []);

And suddenly, you're building applications.

That feels like real progress.

But there was a problem.

I could write the syntax.

I couldn't always explain what was happening underneath it.

The First Warning Sign: Array Methods

One of the first things that exposed this problem was something as simple as:

const activeUsers = users.filter(user => user.active);

I knew that filter() returned an array.

But I didn't initially understand the function being passed to it.

What exactly was:

user => user.active

Why does it run multiple times?

Where does user come from?

Why does filter() return a new array?

These aren't React questions.

They're JavaScript questions.

And React uses these concepts everywhere.

Then Came Destructuring

React code is full of destructuring.

For example:

const { name, email } = user;

Or:

const [count, setCount] = useState(0);

At first, I treated this as React syntax.

It isn't.

It's JavaScript.

The second example is simply array destructuring applied to the value returned by useState().

Once I understood destructuring properly, React code became much easier to read.

Then I Met the Spread Operator

Another example:

const updatedUser = {
  ...user,
  name: "Osama"
};

I knew that this was commonly used in React.

But knowing how to use it and understanding what it actually does are two different things.

The spread syntax is JavaScript.

React doesn't own it.

React simply makes heavy use of JavaScript features like this.

The same applies to:

map()
filter()
reduce()
find()
some()
every()

If your JavaScript foundation is weak, React code can quickly become a collection of syntax that you memorize instead of concepts that you understand.

`useState` Wasn't the Real Problem

At some point, I started asking:

"Why does React need state?"

I knew how to write:

const [count, setCount] = useState(0);

But understanding React state requires a deeper understanding of JavaScript concepts.

Variables.

References.

Objects.

Functions.

Closures.

Immutability.

Execution.

Re-rendering.

For example:

const user = {
  name: "Osama"
};

user.name = "Ali";

This changes the existing object.

But in React, you will often work with state like:

setUser({
  ...user,
  name: "Ali"
});

Why?

Because understanding object references and immutable updates becomes important when working with React state.

Without understanding JavaScript, React's rules can feel arbitrary.

Then `this` Appeared

JavaScript's this was another wake-up call.

I had seen code like:

const user = {
  name: "Osama",

  sayHello() {
    console.log(this.name);
  }
};

Then I encountered arrow functions:

const user = {
  name: "Osama",

  sayHello: () => {
    console.log(this.name);
  }
};

Why do these behave differently?

Why does this depend on how a function is called?

Why don't arrow functions have their own this?

These aren't React concepts.

But if you don't understand them, JavaScript can feel unpredictable.

And when JavaScript feels unpredictable, React becomes even more confusing.

Closures Changed Everything

Closures were probably one of the most important concepts I eventually had to understand.

Consider:

function createCounter() {
  let count = 0;

  return function () {
    count++;
    return count;
  };
}

The returned function can still access count.

Why?

Because of closures.

And closures are not some obscure JavaScript feature that only matters in interviews.

They are fundamental to understanding how functions retain access to variables from their surrounding scope.

Once you understand closures, many concepts in modern JavaScript start making more sense.

Including patterns you encounter when working with React.

Async JavaScript Was Another Story

Then came API requests.

I started with something like:

fetch("/api/users");

Then:

fetch("/api/users")
  .then(response => response.json())
  .then(users => {
    console.log(users);
  });

Then:

async function getUsers() {
  const response = await fetch("/api/users");
  const users = await response.json();

  return users;
}

I knew how to write the code.

But understanding asynchronous JavaScript required much more than memorizing async and await.

I had to understand:

Promises
Callbacks
The Event Loop
Microtasks
Asynchronous execution
Error handling

And suddenly, something that looked like a React problem turned out to be a JavaScript problem again.

The Biggest Mistake Was Learning Syntax Instead of Concepts

Looking back, I wasn't really learning React.

I was learning how to make React code work.

There's a big difference.

Learning syntax looks like:

"How do I write useEffect?"

Learning concepts looks like:

"What problem is useEffect solving, and what does this code actually do?"

Learning syntax:

"How do I update state?"

Learning concepts:

"Why does React care about state updates and references?"

Learning syntax:

"How do I fetch data?"

Learning concepts:

"How does asynchronous JavaScript work, and what happens while I'm waiting for the response?"

The second approach takes longer.

But it creates a much stronger developer.

React Started Making More Sense After I Went Back

Eventually, I made what felt like a step backward.

I went back to JavaScript.

Not because React was bad.

Not because I wanted to abandon modern development.

I went back because I needed the foundation.

I started focusing on:

Variables
Data Types
Functions
Arrays
Objects
Scope
Closures
this
Prototypes
Destructuring
Spread Syntax
Array Methods
Promises
async/await
Event Loop
Modules
DOM
Events
Error Handling

And something interesting happened.

I didn't feel like I was starting over.

I was finally connecting the pieces.

React Became a Layer Instead of a Mystery

Before that, React sometimes felt like a collection of special rules.

After understanding JavaScript better, I started seeing React differently.

React became another layer on top of concepts I already understood.

For example:

users.map(user => (
  <UserCard key={user.id} user={user} />
))

Before:

"That's React syntax."

After:

"map() is JavaScript. The arrow function is JavaScript. The object being passed is JavaScript. React is using these concepts to describe UI."

That distinction is extremely important.

The Framework Shouldn't Be the Foundation

A framework should sit on top of your fundamentals.

Not replace them.

Think about it like this:

                Next.js
                   ↓
                 React
                   ↓
              JavaScript
                   ↓
          Programming Fundamentals

If the bottom layer is weak, everything above it becomes harder.

You can still build things.

You can still follow tutorials.

You can still copy patterns from documentation.

But debugging becomes much harder.

And sooner or later, you'll encounter a problem that the tutorial didn't cover.

That's when fundamentals matter.

Does This Mean You Should Master JavaScript Before React?

Not necessarily.

I don't think you need to spend years learning JavaScript before touching React.

You can learn both together.

The important part is not letting React replace your JavaScript learning.

A healthy learning path could look like:

HTML + CSS
      ↓
JavaScript Fundamentals
      ↓
Small Vanilla JS Projects
      ↓
React
      ↓
Advanced JavaScript
      ↓
Next.js / Node.js
      ↓
Full Stack Development

You don't have to know everything before moving forward.

But whenever React exposes a JavaScript concept you don't understand, stop and learn that concept.

That's much better than memorizing the React-specific solution.

Build Something Without React

One of the best things I did was build projects using Vanilla JavaScript.

Not because Vanilla JavaScript is better than React.

But because it forced me to understand what was happening.

For example, building a Todo application without React makes you think about:

DOM manipulation
Events
State
Data structures
Array methods
Forms
Local Storage
Rendering
Updating the UI

Then when you build the same kind of application with React, you start appreciating what React is actually solving.

You don't just use the abstraction.

You understand why the abstraction is useful.

The Real Lesson

The biggest lesson wasn't:

"Don't learn React early."

The lesson was:

"Don't let learning React prevent you from learning JavaScript."

React is an incredibly powerful tool.

But tools change.

Frameworks change.

Libraries become unpopular.

New technologies appear.

The fundamentals remain.

If tomorrow you move from React to another framework, your JavaScript knowledge comes with you.

That's your transferable skill.

If You're Learning React Right Now

Don't panic if you're already learning React.

You don't need to throw away everything you've learned.

Instead, whenever you encounter something you don't understand, ask:

"Is this actually a React concept, or is it JavaScript?"

For example:

map()?

JavaScript.

Destructuring?

JavaScript.

Spread syntax?

JavaScript.

Closures?

JavaScript.

Promises?

JavaScript.

async/await?

JavaScript.

Modules?

JavaScript.

Objects and references?

JavaScript.

Once you start making this distinction, your learning becomes much more structured.

Conclusion

Learning React before deeply understanding JavaScript wasn't a complete mistake.

It actually taught me something valuable.

It showed me exactly why fundamentals matter.

React can help you build applications faster.

But JavaScript helps you understand what your application is actually doing.

You don't have to choose between modern frameworks and strong fundamentals.

Learn both.

Use React.

Build with Next.js.

Work with Node.js.

Explore the ecosystem.

But whenever you feel that a framework is doing something "magical," go one level deeper.

Ask what's happening underneath.

Because eventually, you'll discover that much of the "magic" isn't magic at all.

It's JavaScript.

And the better you understand JavaScript, the less mysterious React becomes.

Don't learn React to avoid JavaScript. Learn JavaScript so you can truly understand React.

Vanilla JavaScript — Why It Still Matters in the Age of React and Next.js

Osama Abu Motlaq — Wed, 26 Aug 2026 17:39:22 +0000

Vanilla JavaScript — Why It Still Matters in the Age of React and Next.js

In modern web development, it's easy to feel like JavaScript alone is no longer enough.

You open GitHub or LinkedIn and see:

React.

Next.js.

Vue.

Angular.

TypeScript.

Vite.

And sometimes dozens of libraries that a project seems to need before you even write your first line of code.

So beginners often ask:

"If all these tools exist, why should I learn Vanilla JavaScript?"

It's a reasonable question.

But the problem is that many developers learn the tools built on top of JavaScript before understanding the language those tools are built on.

It's like learning to drive a modern car without understanding the basics of controlling a vehicle.

You may be able to drive.

But when something unexpected happens, it becomes much harder to understand why.

What Does Vanilla JavaScript Mean?

Vanilla JavaScript isn't a different programming language.

It's simply a term developers use when they mean JavaScript without a framework or library such as React or Vue.

For example:

const button = document.querySelector("#btn");

button.addEventListener("click", () => {
  console.log("Button clicked");
});

That's Vanilla JavaScript.

No React.

No Vue.

No jQuery.

Just JavaScript and the Web APIs provided by the browser.

Why Does a React Developer Need Vanilla JavaScript?

Because React doesn't replace JavaScript.

React is built with JavaScript and runs within the JavaScript ecosystem.

When you write:

const result = users.filter(user => user.age > 18);

you're using JavaScript.

When you write:

const names = users.map(user => user.name);

you're using JavaScript.

And when you work with:

Promise
async
await
fetch
map
filter
reduce
objects
arrays
destructuring
modules
closures

you're working with JavaScript.

React provides a way to organize and build user interfaces.

It doesn't replace the language itself.

The Problem Starts When You Learn a Framework Before the Language

Imagine someone starts learning development like this:

HTML
↓
React
↓
Next.js
↓
Node.js
↓
MongoDB

They can build a beautiful page.

But when they encounter:

const result = users.filter(user => user.age > 18);

they don't know why filter works.

Or:

const newUser = {
  ...user,
  active: true
};

they don't understand Spread Syntax.

Or:

const data = await fetch("/api/users");

they don't understand what await actually does.

That's when the problem becomes clear.

A developer can use a framework without truly understanding the language underneath it.

A Framework Is Not a Replacement for Fundamentals

Frameworks solve important problems.

React, for example, helps developers build user interfaces in a structured and reusable way.

Next.js adds a large set of capabilities on top of React for building web applications.

But when something goes wrong inside these tools, you often end up going back to JavaScript.

This happens all the time.

The problem might involve:

Scope
Closures
Objects
Arrays
References
Asynchronous JavaScript
Promises
Event Loop
Modules
DOM
Browser APIs

The stronger your JavaScript foundation is, the easier frameworks become.

Vanilla JavaScript Forces You to Understand What Is Happening

When you use a framework, many details are organized or abstracted away from you.

That's a good thing.

But when you work with Vanilla JavaScript, you are forced to interact with things such as:

document.querySelector();

addEventListener();

classList.add();

fetch();

localStorage;

setTimeout();

This helps you understand the relationship between JavaScript and the browser.

You're not just learning how to write code.

You're learning about the environment in which that code runs.

The DOM Is Not JavaScript

This is a very important distinction.

Many beginners assume that:

document.querySelector();

is part of the JavaScript language itself.

The reality is more precise.

JavaScript is a programming language.

document, window, localStorage, fetch, and many other APIs are provided by the environment in which JavaScript runs.

In a browser, you have Web APIs.

In Node.js, you have a different set of APIs.

Understanding this distinction becomes increasingly important as you go deeper into JavaScript.

A Simple Example

Suppose we have a button:

<button id="btn">Click me</button>

We can interact with it using Vanilla JavaScript:

const button = document.querySelector("#btn");

button.addEventListener("click", () => {
  alert("Hello!");
});

Several things are happening here:

JavaScript gets a reference to the element.
The browser provides the document API.
We register an event listener.
The browser waits for a click event.
When the event occurs, the callback function runs.

Once you understand this process, many React concepts become easier to understand.

React Doesn't Make These Concepts Disappear

When you write:

function Button() {
  return (
    <button onClick={() => console.log("Clicked")}>
      Click me
    </button>
  );
}

it may look completely different.

But the underlying ideas haven't disappeared.

You still have:

JavaScript
Functions
Events
Callbacks
Objects
State
Asynchronous behavior

React provides a different abstraction and structure for building user interfaces.

But JavaScript is still underneath it.

Vanilla JavaScript Teaches You to Solve Problems Before Reaching for a Library

There is a common habit among some developers:

"I need to do X, so I'll find a library that does X."

That isn't always wrong.

The problem starts when it becomes the only solution.

A good developer asks first:

"Do I actually need a library for this?"

Sometimes the problem is extremely simple.

For example:

const uniqueUsers = [...new Set(users)];

You don't need a library just to remove duplicate values.

Or:

const activeUsers = users.filter(user => user.active);

You don't need a library to filter data.

Or:

const userNames = users.map(user => user.name);

You don't need a library to extract values from an array.

Understanding JavaScript reduces your dependence on libraries for simple problems.

But This Doesn't Mean Vanilla JavaScript Is Always Better

This is where we need to be realistic.

I'm not saying:

"Don't use React."

And I'm not saying:

"Vanilla JavaScript is better than frameworks."

That's not true.

As an application grows, manually managing the UI, state, and component structure can become complicated.

That's where frameworks and libraries become valuable.

The problem isn't using tools.

The problem is using them without understanding the problem they're solving.

When Should You Use Vanilla JavaScript?

Vanilla JavaScript is excellent for projects such as:

Simple interactive websites
Landing pages
Small tools
Scripts
Widgets
Prototypes
Educational projects
Projects that don't require a framework

It's also excellent for learning.

Because you interact directly with JavaScript and the browser.

When Do You Need React or a Framework?

As a project grows, you may need:

Component Architecture
State Management
Reusable UI
Routing
Complex Interactions
Data Fetching
Large Application Structure

At that point, frameworks such as React and Next.js can become a logical choice.

But using these tools doesn't make understanding JavaScript less important.

It makes it even more important.

Vanilla JavaScript Is Not a Phase You Should Leave Behind

Sometimes Vanilla JavaScript is treated as a temporary stage:

JavaScript
↓
React
↓
Forget JavaScript

But the better path looks more like:

JavaScript
↓
Deep JavaScript Understanding
↓
React
↓
Next.js
↓
Full Stack

Each stage builds on the previous one.

You don't move from JavaScript to React so that you can forget JavaScript.

You move to React because you're ready to use a higher-level tool.

What Should You Understand Before React?

You don't need to become an expert in everything.

But you should be comfortable with:

Variables
Data Types
Functions
Arrays
Objects
Destructuring
Spread Syntax
Rest Parameters
Array Methods
Scope
Closures
this
DOM
Events
Promises
async/await
Fetch API
Modules
Error Handling

Once you start learning React, many concepts will already feel familiar.

The Best Way to Learn Vanilla JavaScript

Don't just watch tutorials.

Build small projects.

Todo List

You'll learn:

DOM
Events
Arrays
Objects
Local Storage

Weather App

You'll learn:

Fetch
Promises
Async/Await
APIs
Error Handling

Quiz App

You'll learn:

State-like logic
Events
Arrays
Objects
Conditional Rendering

Expense Tracker

You'll learn:

Data manipulation
Forms
Local Storage
Array methods

After building these projects, React will feel much less mysterious.

JavaScript First, Tools Second

One of the biggest challenges in the modern JavaScript ecosystem is the sheer number of tools.

Every week, a new library may appear.

A new framework.

A new tool.

A new way of building applications.

If you try to memorize all of them, you'll enter a race that never ends.

But if you understand JavaScript well, you can learn new tools much faster.

Because you aren't starting from zero.

You're simply learning:

How to use a new tool to solve a problem you already understand.

Conclusion

Vanilla JavaScript isn't a competitor to React.

And it's not an outdated technology that should be discarded.

It's the foundation that makes React, Node.js, Next.js, and the rest of the JavaScript ecosystem easier to understand.

You can learn a framework without deeply understanding JavaScript.

You may even be able to build a working application.

But when something unexpected happens, you'll often find yourself searching for a ready-made solution instead of understanding the underlying cause.

When your foundation is strong, frameworks become tools.

And that's the real goal.

Don't learn JavaScript just so you can use React.

Learn JavaScript so you can understand what React is doing when you use it.

In the end, the best developer isn't the person who knows the largest number of libraries.

It's the person who understands the problem, knows when to use JavaScript directly, knows when a higher-level tool is needed, and—most importantly—understands why.

JavaScript — A Programming Mess That Succeeded by Accident

Osama Abu Motlaq — Wed, 26 Aug 2026 17:14:12 +0000

JavaScript — A Programming Mess That Succeeded by Accident

If you've been writing JavaScript for a while, you've probably had a moment when you asked yourself:

"Why was the language designed this way?"

Why do we have == and ===?

Why are there both null and undefined?

Why can the result of some operations be so strange?

Why does this behave differently depending on how a function is called?

And why do you sometimes need to understand the history of the language to understand why certain behaviors exist?

It's easy to look at JavaScript and say that it's a language full of strange design decisions.

But the truth is more interesting.

JavaScript wasn't originally built to become the language we know today.

It started as a simple language for the web, then expanded dramatically and eventually became a fundamental part of modern web development—from the browser to the server, from mobile applications to developer tools.

That's why it can be described, somewhat humorously, as:

JavaScript — a programming mess that succeeded by accident.

But was it really an accident?

The Beginning Was Much Simpler

When JavaScript appeared in the mid-1990s, the goal wasn't to build massive modern applications.

The primary goal was to add some interactivity to web pages.

The web at that time was completely different from the web we know today.

There was no React, Vue, or Angular.

There was no Node.js.

Modern web applications didn't exist in their current form.

Web pages relied heavily on HTML, and there was a growing need for a language that could interact with the page and add dynamic behavior.

And that's where JavaScript came in.

The problem was that the language evolved incredibly quickly.

What seemed like a reasonable decision at the time eventually became part of the language that had to be preserved because of compatibility with millions of websites and applications.

And that's where the real story of JavaScript begins.

One of the biggest reasons JavaScript can feel strange is that the language cannot simply throw away its history.

When a programming language is used by millions of projects, changing old behavior can potentially break a huge number of applications.

As a result, many historical behaviors have to remain.

Even when they no longer look like the best possible design.

And this explains a large part of the "mess."

`==` vs `===`

One of the most famous examples is:

5 == "5"; // true

While:

5 === "5"; // false

The reason is that == allows type coercion, meaning that JavaScript may convert types during the comparison.

===, on the other hand, compares both the value and the type without performing the same kind of implicit conversion.

That's why you'll usually see developers prefer:

===

over:

==

Not because == doesn't work, but because === is generally clearer and less likely to produce unexpected results.

And this leads to one of the most important lessons in JavaScript:

It's not enough to know what the code does. You should understand why it does it.

`null` vs `undefined`

We also have two values that may look very similar:

null

and:

undefined

But they are used differently.

In simple terms:

undefined often means that a value hasn't been assigned or isn't available.

let username;

console.log(username); // undefined

While null is commonly used to explicitly represent the absence of a value.

let selectedUser = null;

In other words, the developer is explicitly saying:

There is a variable, but it currently has no value.

Having two different values for situations that can appear similar may seem confusing, but it's part of the language's history and behavior that has become part of the ecosystem.

`typeof null`... Wait, What?

Now we come to one of JavaScript's most famous oddities:

typeof null

The result is:

"object"

Even though null isn't an object in the way a modern developer would normally expect.

This is one of those behaviors that became part of the language's historical legacy.

The lesson isn't simply to memorize this strange fact.

The more important lesson is:

Programming languages aren't always designed from scratch according to the best possible design.

Some languages evolve on top of old decisions and have to maintain compatibility with the past.

JavaScript Isn't a "Bad Language"

After seeing examples like these, it's easy to say:

"JavaScript is a bad language."

But that's an unfair conclusion.

Every programming language has design decisions that not every developer will like.

More importantly, modern JavaScript is not simply the same language that appeared in the 1990s.

The language has evolved dramatically.

Features such as these have been introduced:

let and const
Arrow Functions
Classes
Modules
Promises
async/await
Destructuring
Spread Syntax
Optional Chaining
Nullish Coalescing
Iterators
Generators
And many more

For example, instead of relying on older patterns for asynchronous operations, we can now write:

async function getUsers() {
  const response = await fetch("/api/users");
  const users = await response.json();

  return users;
}

This shows how the language has evolved to become more powerful and more comfortable to work with.

The Problem Isn't Just JavaScript

There is another important point to understand:

JavaScript is more than just a programming language.

It is part of a huge ecosystem.

Today, when you say JavaScript, you may be talking about:

JavaScript
│
├── Browser
│
├── Node.js
│
├── React
│
├── Next.js
│
├── Express
│
├── TypeScript
│
├── npm
│
└── Thousands of libraries and tools

And this is one of JavaScript's greatest strengths.

The language started as a scripting language inside the browser, but it eventually became the foundation of an entire development ecosystem.

From the Browser to the Server

One of the biggest transformations in JavaScript's history was the emergence of Node.js.

Suddenly, JavaScript was no longer limited to the browser.

Developers could use JavaScript to build:

Web Servers
REST APIs
Backend Applications
CLI Tools
Automation
Real-time Applications
Developer Tools

This made JavaScript one of the few languages that developers can use across both sides of an application:

Frontend
   ↓
JavaScript
   ↓
Backend
   ↓
Database

Then came powerful frameworks and libraries such as React, Express, Next.js, and many others.

Its Success Wasn't Entirely Accidental

The title of this article says:

"A Programming Mess That Succeeded by Accident."

But if we want to be more precise, JavaScript's success wasn't simply an accident.

Many factors contributed to it.

1. It Was Already in the Browser

JavaScript became a fundamental part of the web.

That gave it an enormous user base.

2. It Was Easy to Get Started With

You could simply write:

<script>
  console.log("Hello World");
</script>

You didn't need to build a complicated project just to get started.

3. The Language Kept Evolving

JavaScript didn't stop at its original design.

It continued to evolve and introduce new capabilities.

4. The Rise of Node.js

Node.js dramatically expanded JavaScript's use beyond the browser.

5. A Massive Ecosystem

The existence of npm, libraries, frameworks, and developer tools made JavaScript capable of handling many different types of projects.

6. React and What Came After

Modern frontend libraries and frameworks made JavaScript an essential part of building large web applications.

What Should a JavaScript Developer Learn?

One of the biggest mistakes beginners can make is jumping directly into a framework.

They might start like this:

HTML
↓
React
↓
Next.js
↓
Node.js
↓
MongoDB

Then they encounter a simple JavaScript problem and have no idea why it happens.

A better approach is to build a strong foundation first.

Start by understanding:

Variables
Data Types
Operators
Functions
Arrays
Objects
Scope
Closures
this
Prototypes
Classes
DOM
Events
Promises
Async/Await
Modules
Error Handling
Fetch API

Then move on to frameworks and ecosystem tools.

Because React won't make you a good JavaScript developer.

Understanding JavaScript will make you a better React developer.

Don't Memorize JavaScript's Weirdness — Understand It

You may find long lists online titled:

"100 Weird Things About JavaScript."

They're entertaining, but that's not the real goal.

A good developer doesn't memorize:

[] + []

or:

typeof null

just to prove that they know JavaScript's quirks.

What matters more is understanding:

Type Coercion
Equality
Scope
Execution Context
Closures
Prototypes
Event Loop
Asynchronous JavaScript

Once you understand these concepts, many of JavaScript's "weird" behaviors stop being mysterious and become predictable.

Sometimes the Mess Is Part of the Success

That's the interesting paradox of JavaScript.

If the language had disappeared because of its early design flaws, we wouldn't have what we have today:

React
Next.js
Node.js
Express
Electron
React Native
Vite
npm

And thousands of tools and libraries built around JavaScript and TypeScript.

Its massive success created a new problem:

It became extremely difficult to change the past.

That's why modern JavaScript carries layers of history on top of each other.

Old decisions.

New features.

Backward compatibility.

Modern tools.

Frameworks.

Libraries.

All working together within one enormous ecosystem.

Conclusion

JavaScript isn't a perfect language.

And honestly, I don't think there is such a thing as a perfect programming language.

But JavaScript is an excellent example of how success in programming isn't determined only by the quality of a language's original design.

Sometimes the deciding factors are:

Timing
Adoption
Community
Ecosystem
Backward compatibility
The ability to evolve

So perhaps the better description is:

JavaScript isn't simply a mess that succeeded by accident. It's a language that started small, accumulated decades of history, and evolved into one of the foundations of the modern web.

If you're learning JavaScript today, don't try to run away from the strange parts of the language.

Understand them.

Because the more you understand why the language behaves the way it does, the less you rely on memorization—and the better you become at writing predictable, maintainable code.

And in the end, that's the difference between someone who knows JavaScript...

and someone who understands JavaScript.

DEV Community: Osama Abu Motlaq

I Learned React Before I Truly Understood JavaScript — Here's What Happened

React Made Me Feel Like I Was Progressing

The First Warning Sign: Array Methods

Then Came Destructuring

Then I Met the Spread Operator

useState Wasn't the Real Problem

Then this Appeared

Closures Changed Everything

Async JavaScript Was Another Story

The Biggest Mistake Was Learning Syntax Instead of Concepts

React Started Making More Sense After I Went Back

React Became a Layer Instead of a Mystery

The Framework Shouldn't Be the Foundation

Does This Mean You Should Master JavaScript Before React?

Build Something Without React

The Real Lesson

If You're Learning React Right Now

Conclusion

Vanilla JavaScript — Why It Still Matters in the Age of React and Next.js

Vanilla JavaScript — Why It Still Matters in the Age of React and Next.js

What Does Vanilla JavaScript Mean?

Why Does a React Developer Need Vanilla JavaScript?

The Problem Starts When You Learn a Framework Before the Language

A Framework Is Not a Replacement for Fundamentals

Vanilla JavaScript Forces You to Understand What Is Happening

The DOM Is Not JavaScript

A Simple Example

React Doesn't Make These Concepts Disappear

Vanilla JavaScript Teaches You to Solve Problems Before Reaching for a Library

But This Doesn't Mean Vanilla JavaScript Is Always Better

When Should You Use Vanilla JavaScript?

When Do You Need React or a Framework?

Vanilla JavaScript Is Not a Phase You Should Leave Behind

What Should You Understand Before React?

The Best Way to Learn Vanilla JavaScript

Todo List

Weather App

Quiz App

Expense Tracker

JavaScript First, Tools Second

Conclusion

JavaScript — A Programming Mess That Succeeded by Accident

JavaScript — A Programming Mess That Succeeded by Accident

The Beginning Was Much Simpler

== vs ===

null vs undefined

typeof null... Wait, What?

JavaScript Isn't a "Bad Language"

The Problem Isn't Just JavaScript

From the Browser to the Server

Its Success Wasn't Entirely Accidental

1. It Was Already in the Browser

2. It Was Easy to Get Started With

3. The Language Kept Evolving

4. The Rise of Node.js

5. A Massive Ecosystem

6. React and What Came After

What Should a JavaScript Developer Learn?

Don't Memorize JavaScript's Weirdness — Understand It

Sometimes the Mess Is Part of the Success

Conclusion

`useState` Wasn't the Real Problem

Then `this` Appeared

`==` vs `===`

`null` vs `undefined`

`typeof null`... Wait, What?