DEV Community: Osama Abu Motlaq

From a Real-World Problem to a Software Project: The Idea Behind Haseen.

Osama Abu Motlaq — Tue, 20 Oct 2026 11:48:55 +0000

From a Real-World Problem to a Software Project: The Idea Behind Haseen

Every software project should begin with a question worth answering.

Not which framework to use. Not which library to install. Not how the dashboard should look.

But what problem am I trying to solve, and why does it matter?

That question led me to the idea behind Haseen a project focused on identity and access governance.

The Problem: Who Should Have Access to What?

Imagine a company with dozens or hundreds of employees.

Each employee needs access to specific systems, files, and resources to perform their job. An accountant might need access to financial reports, while an HR employee needs access to personnel records.

Now imagine an accountant accidentally having access to confidential HR files, or a former team member retaining permissions they no longer need.

These situations raise important questions:

Who has access to a particular resource?
Are those permissions actually necessary for the employee's role?
How can administrators review and manage permissions without losing track of them?
What happens when someone needs temporary access to a resource outside their usual responsibilities?

As organizations grow, answering these questions becomes more complicated. Managing permissions is not simply about granting or denying access. It is about maintaining control, visibility, and accountability over time.

That is the problem space I wanted to explore.

Introducing Haseen

Haseen is an in-progress project built around the idea of an identity and access governance dashboard.

The goal is to provide administrators with a structured interface for reviewing employee permissions, understanding access relationships, and managing access requests.

Rather than treating permissions as a collection of disconnected settings, I want Haseen to present them in a way that makes their relationships easier to understand.

The project revolves around three main ideas.

1. Understanding Permissions

Administrators need a clear picture of which employees have which permissions.

A permission matrix can help make this relationship visible by presenting employees, roles, and permissions in a structured format.

A permission tree can provide another way to navigate resources and understand how access is organized.

These are not just visual components. Their design affects how easily someone can identify an unexpected permission or understand the consequences of a change.

2. Managing Access Through Roles

Instead of assigning every permission independently to every employee, a system can use roles to organize access.

For example, an accountant role might include permissions related to financial reports and accounting tools.

Employees assigned to that role receive the permissions associated with it, subject to the system's access rules.

This introduces an important design consideration: roles and permissions have a many-to-many relationship. A role can contain multiple permissions, and the same permission can belong to multiple roles.

Modeling these relationships correctly matters because the interface must represent the underlying data accurately. A visually convincing dashboard is not enough if its data model cannot express the rules it is supposed to manage.

3. Temporary Access Requests

Some employees occasionally need access to resources outside their normal responsibilities.

Giving them permanent access may create unnecessary risk, especially when the requirement is temporary.

Haseen explores the idea of temporary access requests, allowing access to be requested for a limited period.

For example, an employee might need access to a particular resource to complete a short-term task. That access should have a defined expiration rather than remain available indefinitely.

There is an important engineering detail here: temporary access expiration must be enforced by the backend, not merely by a frontend timer.

The interface can display the expiration time and communicate the request's status, but the server must enforce the actual access rules.

This distinction is one of the architectural considerations I want to understand as the project develops.

Why I Chose This Project

I did not want to build another dashboard that only displays charts, cards, and tables.

I wanted a project with a meaningful problem behind its interface, where the design requires more than arranging components on a screen.

Haseen provides an opportunity to explore several engineering challenges:

Modeling relationships between users, roles, and permissions.
Designing interfaces for complex data rather than isolated components.
Managing filtering, searching, and navigation through a large set of records.
Representing different states of access requests clearly.
Thinking about security boundaries and the responsibilities of the frontend and backend.

Each of these challenges creates an opportunity to make deliberate design decisions and understand why those decisions matter.

The project also gives me a reason to think beyond individual React components. A component may work correctly in isolation, but it still needs to fit into a consistent data model and a coherent application structure.

Why React and TypeScript?

My current focus is frontend development, particularly React and TypeScript, so I am approaching Haseen primarily from that perspective.

React provides a way to organize the interface into reusable components and manage the relationships between different parts of the UI.

TypeScript adds explicit types that help describe entities such as users, roles, permissions, and access requests. It also makes different states easier to represent clearly.

For example, an access request might be pending, approved, rejected, or expired. Modeling these states deliberately can make the application's behavior easier to reason about than relying on arbitrary strings scattered throughout the codebase.

However, neither React nor TypeScript automatically makes an application secure. Real access control requires backend enforcement, appropriate data handling, and careful authorization checks.

Understanding where the frontend's responsibilities end—and where the backend's responsibilities begin—is part of what makes this project valuable to me.

More Than Building a UI

One of the most important things I want to get out of Haseen is a deeper understanding of software engineering decisions.

Why should relationships between roles and permissions be modeled in a particular way?

Which state belongs in the URL, which belongs in the UI, and which should come from the server?

How should an interface communicate that an operation is pending, has failed, or is no longer allowed?

What should happen when two administrators make conflicting changes?

These questions do not always have one universally correct answer. The right approach depends on the requirements, constraints, and architecture of the system.

Working through them is an important part of moving from writing components that work to designing software that is maintainable and reliable.

Where Haseen Stands Today

Haseen is still a work in progress.

My current priority is building a solid frontend foundation, improving the data modeling, and understanding the architectural decisions behind the interface. I am not presenting it as a completed enterprise access governance platform or a production-ready security product.

Instead, I see it as an opportunity to develop a more disciplined approach to building software around a real problem.

There is still more to explore, particularly around backend authorization, persistence, and enforcing temporary access rules. Those concerns need to be understood and implemented properly before a system of this kind could be trusted with real organizational access.

Final Thoughts

The idea behind Haseen is straightforward: make employee permissions easier to understand, review, and manage.

The engineering challenge is turning that idea into a system whose interface, data model, and access rules work together consistently.

For me, that is what makes the project worth building.

I want Haseen to be more than a portfolio screenshot. I want it to be a project through which I can demonstrate how I approach problems, make technical decisions, and improve my understanding of software engineering.

Because building software is not just about making something work.

It is about understanding what should work, why it should work that way, and what it takes to make it reliable.

Haseen (حصين) is an ongoing personal project exploring identity and access governance through React, TypeScript, and software engineering fundamentals.

A Beginner's Guide

Osama Abu Motlaq — Wed, 30 Sep 2026 13:53:07 +0000

Osama Abu Motlaq

Sep 30

Using TypeScript with React: A Beginner's Guide

#beginners #learning #react #typescript

4 min read

Using TypeScript with React: A Beginner's Guide

Osama Abu Motlaq — Wed, 30 Sep 2026 13:50:10 +0000

If you are learning React and have started hearing about TypeScript everywhere, you may be wondering:

Why should I use TypeScript with React?

I recently started learning React with TypeScript, and one of the first things I noticed is that TypeScript helps make React code more predictable and easier to understand.

In this article, I'll explain some of the basic concepts I have learned so far.

What is TypeScript?

TypeScript is a programming language built on top of JavaScript.

It adds static typing to JavaScript, which means we can define what kind of data our variables, functions, and objects should contain.

For example:

let username: string = "Osama";
let age: number = 22;
let isStudent: boolean = true;

If we try to assign a number to username:

username = 100;

TypeScript will warn us because username was defined as a string.

This can help us catch many mistakes while writing code instead of discovering them later at runtime.

Why Use TypeScript with React?

React applications often contain a lot of data moving between components.

For example:

Props
State
Event handlers
API responses
Forms
Context
Reducers

TypeScript allows us to describe the shape of this data.

This becomes especially useful as an application grows.

Typing React Props

One of the first things I learned was how to type component props.

Suppose we have a component that receives a user's name and age:

type UserProps = {
name: string;
age: number;
};

const User = ({ name, age }: UserProps) => {
return (

{name}

Age: {age}

);
};

Now TypeScript knows exactly what this component expects.

We can use it like this:

But if we accidentally write:

TypeScript will show errors because the values don't match the types we defined.

What is children?

React components can also receive something called children.

For example:

type CardProps = {
children: React.ReactNode;
};

const Card = ({ children }: CardProps) => {
return

{children};
};

Now we can write:

Hello

This content is inside the Card.

The content between and becomes the component's children.

React.ReactNode is commonly used when we want a component to accept different types of React content, such as text, elements, or other components.

Typing State with useState

TypeScript can also help us with React state.

For example:

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

Here we are telling TypeScript that count should be a number.

We can then do:

setCount(count + 1);

But something like this would cause a type error:

setCount("Hello");

In many simple cases, TypeScript can infer the type automatically:

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

TypeScript understands that count is a number.

Typing Events

React event handlers are another area where TypeScript is very useful.

For example, with an input:

type InputProps = {
value: string;
handleChange: (
event: React.ChangeEvent
) => void;
};

Now TypeScript knows that handleChange receives a React change event from an HTML input.

We can use it like this:

const Input = ({ value, handleChange }: InputProps) => {
return (
value={value}
onChange={handleChange}
/>
);
};

This gives us better autocomplete and helps prevent mistakes when working with events.

TypeScript and useReducer

TypeScript becomes particularly useful when working with useReducer.

For example, we can define the possible actions:

type UpdateAction = {
type: "increment" | "decrement";
payload: number;
};

type ResetAction = {
type: "reset";
};

type CounterAction = UpdateAction | ResetAction;

Now our reducer knows which actions are allowed.

const reducer = (
state: CounterState,
action: CounterAction
) => {
switch (action.type) {
case "increment":
return {
count: state.count + action.payload,
};

case "decrement":
  return {
    count: state.count - action.payload,
  };

case "reset":
  return {
    count: 0,
  };

default:
  return state;

}
};

This is one of the areas where I started to see why TypeScript is useful with React.

Instead of passing arbitrary strings and values around, we can clearly define which actions are valid.

TypeScript Doesn't Replace Understanding React

One important thing I have learned is that TypeScript does not replace understanding React.

You still need to understand:

Components
Props
State
Events
Hooks
Rendering
Component composition

TypeScript simply adds a type system that helps us describe and validate the data used by our React application.

For me, the best approach is to learn React concepts first and then understand how TypeScript describes those concepts.

Final Thoughts

Using TypeScript with React can feel a little difficult at first.

There are new concepts such as:

Types
Interfaces
Union types
Generics
Type inference
React.ReactNode
Event types

But once you understand the basics, TypeScript starts to make React code easier to reason about.

I'm still learning React and TypeScript, and one of the things I like most about this combination is that the code becomes more explicit about what data a component expects and what it can return.

There is still a lot for me to learn, but learning TypeScript alongside React has already changed the way I think about writing React applications.

If you're also learning React with TypeScript, don't try to memorize everything at once. Learn one concept, use it in a small component, and gradually build from there.

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

From a Real-World Problem to a Software Project: The Idea Behind Haseen.

From a Real-World Problem to a Software Project: The Idea Behind Haseen

The Problem: Who Should Have Access to What?

Introducing Haseen

1. Understanding Permissions

2. Managing Access Through Roles

3. Temporary Access Requests

Why I Chose This Project

Why React and TypeScript?

More Than Building a UI

Where Haseen Stands Today

Final Thoughts

A Beginner's Guide

Using TypeScript with React: A Beginner's Guide

Using TypeScript with React: A Beginner's Guide

{name}

Hello

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?