DEV Community: Mo Ghanbari

Why Use a Framework Instead of Vanilla JS?

Mo Ghanbari — Mon, 14 Jul 2025 15:38:36 +0000

📢 Disclaimer

This article was written by me and polished using AI for clarity and flow. The ideas and structure are fully mine. 😊

Why not just use plain JavaScript?

It’s a fair question — especially if you’re just starting out or have been working on small projects. But as your application (and team) grows, the need for structure, consistency, and performance optimization becomes critical. In this article, we’ll break down some core reasons why frameworks like React, Vue, or Svelte exist — and why we force ourselves to learn and use them instead of using Vanilla Javascript in the first place?!

1. Discipline: Scaling Beyond Solo Projects

When you're coding alone, you can afford to "just make it work." But software development in a team setting is a different world. Here's why:

Consistency is key: Without a shared set of conventions, every developer will approach problems differently — which leads to fragmented, inconsistent codebases.
Maintenance becomes a nightmare: Imagine onboarding a new teammate to a codebase where each feature is built using its own unique logic. Good luck debugging or refactoring.
Frameworks enforce structure: React (for instance) pushes you to think in components, manage state predictably, and follow patterns like unidirectional data flow.

Think of it like this: frameworks don’t just help you build faster — they help you build together.

2. DOM Manipulation is Slow

Directly manipulating the DOM with vanilla JavaScript can work fine… until it doesn’t!! The browser needs to do a lot of behind-the-scenes work every time you touch the DOM:

🧩 Recalculation (Recomputing Styles)

Changing a class or inline style? The browser might need to recalculate styles for many elements.

element.style.color = 'red';

📐 Reflow (Layout Calculation)

Insert or remove an element? Change its dimensions? That might require recalculating layout for a whole section of the page.

🎨 Repaint (Visual Redraw)

After layout, the browser repaints the screen — an expensive operation for complex UIs.

⛓️ Unbatched Updates

Doing 10 DOM changes in vanilla JS? You're likely triggering 10 layout + repaint cycles unless you manually batch those changes.

Frameworks like React handle these for you. They use techniques like virtual DOM diffing and batching to minimize costly operations.

3. Component Reusability: Build Once, Use Everywhere

One of the most powerful features of frameworks like React is the ability to write reusable UI components. These are self-contained, customizable blocks of logic and markup — think of them like Lego bricks. You build a button once, and use it in 5 places. Change it in one place — it updates everywhere.

Let’s look at a simple example of a reusable “Card” component:

✅ React Version (Component-Based)

// Card.jsx
export default function Card({ title, description }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      <p>{description}</p>
    </div>
  );
}

// App.jsx
import Card from './Card';

function App() {
  return (
    <>
      <Card title="First Post" description="Hello world" />
      <Card title="Second Post" description="React is awesome!" />
    </>
  );
}

🚫 Vanilla JS Version (Without Components)

<div class="card">
  <h2>First Post</h2>
  <p>Hello world</p>
</div>

<div class="card">
  <h2>Second Post</h2>
  <p>React is awesome!</p>
</div>

Want to change the layout or style? You’ll need to manually update every instance — or write your own templating logic with document.createElement, innerHTML, etc. Even then, it becomes messy fast.

Bottom line: Frameworks help you stop thinking in pages and start thinking in building blocks.

💬 There’s More, But…

There are of course many other good reasons to use a framework:

State management
Routing and navigation
Testing support

..and so on.

But I chose the three above — discipline, performance, and reusability — because I believe they’re the most important to understand first.

What do you think?
Do you think there are more important reasons that should have mentioned before these 3 or no we can run a production ready project using pure Javascript?

Let me know in the comments! 👇

Two best practices of creating modals in React 18

Mo Ghanbari — Mon, 18 Jul 2022 22:32:08 +0000

Initial project
Using custom hooks to easily show and hide modals
- What is the problem?
- What is a custom hook?
- Rewriting our Modal using a custom hook
Use React Portal
- What is the problem?
- What is react Portal
- Use create Portal
Final Project

Initial project

We start with a simple create-react-app project which only has two components, one is our main component which is App, and the other is Modal component.(This project also can be found in this Github repo)

As you can see, Modal component uses a flag(show), which comes from parent component as a prop, to check if it should gets rendered or not. It also sends a click event of close button to the parent component to let the parent know it's time to toggle the flag:



const Modal = ({ show, onCloseButtonClick }) => {
  if (!show) {
    return null;
  }

  return (
    <div className="modal-wrapper">
      <div className="modal">
        <div className="body">Click on the close button to close the modal.</div>
        <div className="footer">
          <button onClick={onCloseButtonClick}>Close Modal</button>
        </div>
      </div>
    </div>
  );
};

export default Modal;

In the App component however, a state is being used to pass as a prop to Modal. Additionally, App is listening to click event of close button in Modal and set the state/flag to false whenever click event happens or in other words, close the modal:



function App() {
  const [showModal, setShowModal] = useState(false);

  const openModal = () => {
    setShowModal(true);
  }

  const closeModal = () => {
    setShowModal(false);
  }

  return (
    <div className="App">
      <Modal show={showModal} onCloseButtonClick={closeModal} />
      <div className="button" onClick={openModal}>Open Modal</div>
    </div>
  );
}

Using custom hooks to easily show and hide modals

What is the problem?

The problem with this method though is whenever you need to use the Modal, you have to repeat yourself by adding one state as the flag(showModal), and two methods which are responsible for toggling the state(openModal() and closeModal()):



const [showModal, setShowModal] = useState(false);

const openModal = () => {
  setShowModal(true);
}

const closeModal = () => {
  setShowModal(false);
}

However, in this section we'll see that by using a simple custom hook, you are no longer required to add this bunch of repeated code.

What is a custom hook?

React Hooks are powerful tools introduced in React 16 and we've already used them above to create our only state(showModal). Custom Hooks in the other hand, simply are hooks created by you, and you can use them to extract components logic into reusable functions.

Based on official definition:

A custom Hook is a JavaScript function whose name starts with ”use” and that may call other Hooks

Rewriting our Modal using a custom hook

As I mentioned earlier, in our project, we're repeating the logic of using Modal, and now we can use our custom hook to keep the logic.

Step 1: Create
To name our custom hook, we already know that a custom hook's name must start with use and as we are creating this custom hook for our Modal, we can simply call it useModal:



const useModal = () => {

}

export default useModal;

Step 2: Add
We already know about the repeated logic for modal, we need a state and a function to toggle it. As this logic is already exists in App component, we can simply cut and paste it into our custom hook:



import { useState } from 'react';

const useModal = () => {
    const [isShowing, setIsShowing] = useState(false);

    function toggle() {
        setIsShowing(!isShowing);
    }
}

export default useModal;

Step 3: Return
Now we should make the state and toggle function accessible outside of our custom hook, and because we have two things to return, like the standard useState hook in React library, we can simply return values as an array:



import { useState } from 'react'

const useModal = () => {
    const [isShowing, setIsShowing] = useState(false);

    function toggle() {
        setIsShowing(!isShowing);
    }

    return [
        isShowing,
        toggle
    ];
}

export default useModal;

Step 4: Use
Now it's time to use our gorgeous custom hook wherever we need to use the Modal component:



function App() {
  const [isShowingModal, toggleModal] = useModal();

  return (
    <div className="App">
      <Modal show={isShowingModal} onCloseButtonClick={toggleModal} />
      <div className="button" onClick={toggleModal}>Open Modal</div>
    </div>
  );
}

And here is the result:

Use React Portal

What is the problem?

There is still one more thing that we can improve in our Modal. Here is how Modal gets render in the DOM:

As you can see, the Modal appears inside <div class="App"> simply because we put the modal inside the App component. However, does it really belong there? A modal usually considered a component that belongs outside the DOM hierarchy.

What is React Portal?

React Portals render our component outside the DOM hierarchy of the parent component. Here is how we use it:



ReactDOM.createPortal(child, container);

And now let's see how we use it in our Modal.

Use create Portal

This part is so simple. The only thing we have to do is to wrap our modal with a portal:



import ReactDOM from 'react-dom';

const Modal = ({ show, onCloseButtonClick }) => {
  if (!show) {
    return null;
  }

  return ReactDOM.createPortal(
    <div className="modal-wrapper">
      <div className="modal">
        <div className="body">
          Click on the close button to close the modal.
        </div>
        <div className="footer">
          <button onClick={onCloseButtonClick}>Close Modal</button>
        </div>
      </div>
    </div>
    , document.body
  );
};

export default Modal;

Just keep in mind that the second parameter(document.body) is the rest of the DOM which you have to pass, otherwise you will get an error.

And here is how our Modal looks like inside our DOM after using Portal:

Final Project

You also can find the final code in this repository

What do you think about this? Is there any other way that I haven't mentioned? Please please please let me know by commenting down below. I can't wait to hear that. Thanks

Why writing comments are bad

Mo Ghanbari — Sun, 10 Jul 2022 19:03:34 +0000

To write comments or Not to write comments, that is the question

Without doubt, this is one of the most controversial topics among developers. Some believe that writing comments should be the last option, and others think comments can be use freely. As you might have guessed I am personally against writing comments to describe code and here are some of the reasons I can mention why.

Ok at first, Outdated after a while

If you write a code that doesn't work, unit tests will fail or your editor (aka compiler) will complain. However, there is no mechanism to check your comments. Let's say after one year of writing a comment for a function, you or other developer change the functionality of that function without paying attention to change the comment accordingly specially because there is no unit test to check if your comment still describes what your code does. Eventually, this will be the cause of so many obsolete comments in the project. This mostly happens because most of developers don't bother to even read comments.

Good code doesn't need comments

If your code clearly describes the purpose of the code then why would you need comments in the first place? If you are able to write clear, readable code accompanied by readable tests, no comment will be able to beat that.
As an example, here is a code which uses comments to describe some parts of the code and we'll see if we can eliminate the need for them.

Well, I can thing of 3 things here:

Change the function name

As we can see the function name doesn't say much, so if we use a more descriptive name instead of just a word, it would certainly eliminates the need for the first comment. My suggestions would be getRemainingDaysToBirthday or calculateRemainingDaysToBirthday.

Use descriptive condition

// if birthday has already passed, set next year as birthday
if (today > upcomingBday) {
  upcomingBday.setFullYear(today.getFullYear() + 1);
}

Here we can describe condition inside the code without using comments:

const birthdayHasAlreadyPassed = today > nextBirthday;
if (birthdayHasAlreadyPassed) {
  upcomingBday.setFullYear(today.getFullYear() + 1);
}

Easy right?

Using another function

// getTime() returns in milliseconds so we divide the result in milliseconds to get number of days
const result = Math.ceil((upcomingBday.getTime() - today.getTime()) / (24 * 60 * 60 * 1000));

First of all whoever reads this code probably wouldn't understand what 24 * 60 * 60 * 1000 does specially what the 1000. Instead, we can use descriptive constants to describe each what each digit represents.

  const hoursInADay = 24;
  const minutesInAnHour = 60;
  const secondsInAMinute = 60;
  const oneSecondInMilliseconds = 1000;

But how about the first part? Well we can use functions to increase readability, and in this case, describe what this piece of code does:

function getDaysToBirthday(nextBirthday, today) {
  const hoursInADay = 24;
  const minutesInAnHour = 60;
  const secondsInAMinute = 60;
  const oneMillisecond = 1000;
  const OneDayInMilliseconds = hoursInADay * minutesInAnHour * secondsInAMinute * oneMillisecond;

  const daysToBirthday = Math.ceil(nextBirthday.getTime() - today.getTime() / OneDayInMilliseconds);

  return daysToBirthday;
}

Makes you a bad developer

You can always describe what you are doing in comments so why bother to write a clean code? It always takes some effort and time to write a cleaner code without needing a comment so by having restrict rules about them, everyone in the team will force to write a code which describe itself.

So should I avoid comments at all costs?

I don't think you can find anyone who says "never" to comments, however, in general you should always avoid writing comments as much as possible by writing clean, readable code which explain itself accompanied by good tests. this will certainly eliminates the need for comments.
However, there are some cases which they could be useful such as using comments to document APIs or describing complex operations which is impossible the team tried their best to write a good code but still needs comments to clarify what the operations does or why this code exist.

Disclaimer

I am pretty sure there are so many good developers out there who can complete this list or they have other opinions. Please let me know what you think in the comment section below it means so much to me and help me grow my knowledge. I appreciate in advance.

DEV Community: Mo Ghanbari

Why Use a Framework Instead of Vanilla JS?

📢 Disclaimer

Why not just use plain JavaScript?

1. Discipline: Scaling Beyond Solo Projects

2. DOM Manipulation is Slow

🧩 Recalculation (Recomputing Styles)

📐 Reflow (Layout Calculation)

🎨 Repaint (Visual Redraw)

⛓️ Unbatched Updates

3. Component Reusability: Build Once, Use Everywhere

💬 There’s More, But…

Two best practices of creating modals in React 18

Table of Contents

Initial project

Using custom hooks to easily show and hide modals

What is the problem?

What is a custom hook?

Rewriting our Modal using a custom hook

Use React Portal

What is the problem?

What is React Portal?

Use create Portal

Final Project

Why writing comments are bad

Ok at first, Outdated after a while

Good code doesn't need comments

Makes you a bad developer

So should I avoid comments at all costs?

Disclaimer