DEV Community: Mahdi Hosseini

Tailwind CSS 4 vs. CSS Modules: Which Wins for Scalable Projects?

Mahdi Hosseini — Wed, 03 Sep 2025 18:14:18 +0000

Tailwind CSS 4 vs. CSS Modules:

Which Wins for Scalable Projects?
As web development evolves, choosing the right styling approach for your projects becomes increasingly critical. With the release of Tailwind CSS 4 in 2025, the debate between utility-first frameworks and traditional CSS methodologies like CSS Modules has reignited. Both tools offer unique strengths, especially when it comes to building scalable applications. But which one should you pick for your next big project? Let’s dive into a detailed comparison of Tailwind CSS 4 and CSS Modules, exploring their architecture, performance, maintainability, and suitability for large-scale development.

The Foundations: What Are We Comparing?

Tailwind CSS 4: A Utility-First Evolution

Tailwind CSS has long been celebrated for its utility-first approach, allowing developers to style directly in their markup with pre-defined classes like bg-blue-500 or p-4. The latest iteration, Tailwind CSS 4, brings significant improvements over its predecessors, including a CSS-first configuration, faster build times (up to 5x for full builds and 100x for incremental builds), and enhanced support for modern CSS features like container queries and 3D transforms. It’s designed to streamline development while maintaining flexibility through a customizable tailwind.config.css file.

CSS Modules: Scoped Styling Done Right

CSS Modules, on the other hand, take a more traditional route by enabling locally scoped CSS. Introduced as a way to avoid global namespace collisions, CSS Modules process your CSS files at build time (e.g., with Webpack or Vite) to generate unique class names. This approach keeps styles encapsulated within components, making it a favorite for developers who prefer writing vanilla CSS with a modern twist.
Performance: Build Times and Bundle Size
Scalability often hinges on performance, and both tools handle this differently.

Tailwind CSS 4: With its Just-In-Time (JIT) compilation and purging capabilities, Tailwind 4 generates only the CSS you use, resulting in remarkably small production bundles (often under 10kB). The new engine optimizes build times, making it ideal for large projects where rapid iteration is key. However, during development, the initial setup can still feel heavy if not properly configured.

CSS Modules: CSS Modules don’t inherently optimize bundle size unless paired with tools like PurgeCSS. Since each module is processed separately, projects with many components can lead to larger CSS files if unused styles aren’t removed. Build times are generally faster for small projects but can scale poorly as the number of modules grows.

Verdict: Tailwind 4 edges out in performance for scalable projects due to its built-in optimization and faster incremental builds, provided you configure purging correctly.
Maintainability: Consistency vs. Control
Maintaining a large codebase is where the rubber meets the road.

Tailwind CSS 4: The utility-first paradigm enforces a consistent design system through predefined scales for colors, spacing, and typography. This reduces the risk of style drift across teams. However, verbose HTML with long class lists (e.g., flex justify-center items-center p-4 bg-gray-100) can become hard to read, especially for complex components.
The learning curve for new developers and the need for strict coding standards can also pose challenges.
CSS Modules: With locally scoped styles, CSS Modules offer granular control and encourage modular design. You can write semantic CSS (e.g., .card-title { font-size: 1.5rem; }) that’s easier to trace and refactor. However, managing global styles or reusing utilities across components requires additional effort, such as creating a shared CSS file or using CSS custom properties.

Example: Imagine a reusable button component.

Tailwind:

<button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click Me
</button>

CSS Modules (with styles.module.css):

import styles from './styles.module.css';
<button className={styles.button}>Click Me</button>
css.button {
  background-color: #3b82f6;
  color: white;
  font-weight: bold;
  padding: 0.5rem 1rem;
  border-radius: 0.25rem;
}
.button:hover {
  background-color: #1d4ed8;
}

Verdict: CSS Modules win for maintainability in projects requiring custom, semantic styles, while Tailwind 4 shines for enforcing consistency with less CSS overhead.
Scalability: Handling Growth
As projects scale, the ability to adapt to new features and team sizes becomes crucial.

Tailwind CSS 4: Its configuration file allows you to define a design system upfront, which scales well with growing teams. Container queries and responsive utilities make it adaptable to complex layouts. However, refactoring a Tailwind-heavy codebase (e.g., updating a color scheme) can be tedious, requiring changes across numerous class references.
CSS Modules: The modular nature scales naturally with component-based architectures like React or Vue. Adding new components with isolated styles is seamless, but managing a growing number of modules can lead to redundancy unless a strict naming convention (e.g., BEM) is enforced.

Real-World Consideration: In a project with 50+ components, Tailwind’s purging keeps the CSS lean, while CSS Modules might require manual optimization to avoid bloat.
Developer Experience: Productivity and Learning Curve

Tailwind CSS 4: The utility-first approach accelerates prototyping and reduces context-switching between files. IntelliSense in modern IDEs (e.g., VS Code) enhances productivity. However, the initial learning curve can be steep for developers accustomed to traditional CSS.
CSS Modules: Familiar to developers with a CSS background, CSS Modules offer a gentler learning curve. Modern tools provide autocompletion and error checking, but the need to manage imports and scope can slow down rapid development.

Verdict: Tailwind 4 boosts productivity for experienced teams, while CSS Modules are more accessible for beginners or teams with diverse skill levels.
When to Choose What?

Choose Tailwind CSS 4 if:

You prioritize rapid development and consistent design.
Your team is comfortable with utility classes and can enforce coding standards.
Performance and small bundle sizes are critical for your scalable app.

Choose CSS Modules if:

You need fine-grained control over custom designs and animations.
Your project involves complex theming or dynamic styling.
Your team prefers traditional CSS workflows with local scoping.

A Hybrid Approach?
Many teams find success blending both. Use Tailwind for rapid prototyping and utility-driven layouts, while reserving CSS Modules for highly specific or reusable styles. This hybrid strategy leverages Tailwind’s speed and CSS Modules’ maintainability.

Conclusion:

Tailwind CSS 4 and CSS Modules each bring unique strengths to the table. For scalable projects, Tailwind 4’s performance optimizations and design system consistency make it a powerhouse, especially with its 2025 enhancements. However, CSS Modules remain a robust choice for teams needing control and modularity. The decision hinges on your project’s needs, team expertise, and long-term maintenance goals. Why not experiment with both in a small project to see which fits your workflow best?
As we continue to push the boundaries of web development, tools like these evolve to meet our needs. What’s your go-to styling approach? Share your thoughts in the comments

I’d love to hear how you tackle scalability in your projects!

Async Like a Senior: Understand JavaScript Timing Without the Confusion

Mahdi Hosseini — Thu, 29 May 2025 05:30:52 +0000

From Callbacks to Async/Await, Explained Simply and Professionally

If you're working as a frontend developer, mastering asynchronous behavior in JavaScript is non-negotiable.
Whether you're dealing with APIs, loading data, timers, or any kind of delayed execution, async code is everywhere ⚙️

But here’s the real question:
What is async, really? Why do we even need it? And how do callbacks, promises, and async/await actually differ not just in syntax, but in philosophy?

In this article, I’ll break it all down for you, not just so you “know” it, but so you understand it. Because in real-world development, surface knowledge won’t cut it.

First, How Does JavaScript Run Code?
JavaScript is single-threaded, which means it can only do one thing at a time.
But we’re constantly working with tasks that take time, like calling an API, reading files, or waiting for a timeout ⏳
If we were to run these things synchronously, everything would freeze until they finish 🧊

That’s exactly why asynchronous programming exists: to keep the app responsive while those tasks finish in the background.

Step 1: Callbacks – The Old School Way
`You pass a function that gets called once the job is done.

🧠 It works fine, but once callbacks get nested, it becomes a nightmare to read and debug. That’s what we call callback hell 😵‍💫

Step 2: Promises – A Formal Deal with the Future
A Promise is like a contract. It will either resolve (succeed) or reject (fail).
You can then define:
→ What to do when it succeeds
→ What to do when it fails

👍 Easier to read, better error handling, and cleaner structure. But chaining multiple promises still starts to stretch your code.

Step 3: Async/Await – Clean Code, Clear Mind
The newest and cleanest syntax for writing async code.
It looks like regular synchronous code, but works asynchronously under the hood.

🌟 It’s easy to write, easier to read, and much more comfortable to debug. You’re still writing async code, but in a much more natural way.

But What’s Actually Happening Behind the Scenes?
JavaScript uses an Event Loop system to handle async tasks without blocking the main thread.

Think of it like a queue system at a coffee shop ☕
The main thread handles orders (sync code)
Async tasks get pushed to a queue
The Event Loop keeps checking: "Is the main thread free now? Cool, let’s run the next async task"

So when you run a setTimeout or fetch, JavaScript doesn’t wait. It keeps going and comes back to it later. That’s what keeps your UI smooth and responsive.
**
Why Should You Really Understand This?**
It’s not enough to just use await. You need to know:

When async is needed

How to manage async flow and errors

What’s happening under the hood

Because in real projects:
❌ Async mistakes cause ugly bugs
❌ Delayed data can ruin the user experience
❌ Unhandled errors crash the whole app

But when you master async, you code with confidence 💪
You control time instead of fearing it.

Final Words
✅ Callback was the foundation
✅ Promise brought structure
✅ Async/Await made it elegant

If you only know one style, time to explore the others.
If you know them all but don’t feel confident, build a project.
Even a simple one.
Create a fake login page with loading delays. Call an external API. Simulate a failure.
It’s practice that burns this into your brain 🔥

Thanks For Reading, Mahdi.

Monitoring Frontend Applications in Next.js, From Errors to Insights 🚀

Mahdi Hosseini — Sat, 17 May 2025 14:17:06 +0000

Hey there! 👋
I'm Mahdi, a frontend developer with a few years of experience working with React and particularly Next.js. In this article, I want to share my real-world experience with monitoring in frontend projects - something I underestimated until a few serious bugs hit our production environment and taught me otherwise. 😅

Why Monitoring Matters in Frontend 🤔

The thing about frontend is that our code runs on the user's browser, not our own machine. Everything might seem perfect in development, but do we really know:
🔹 Are users experiencing errors?
🔹 Is the page loading fast?
🔹 Does Safari behave differently?
🔹 Are key interactions breaking?
To answer these questions, proper monitoring is essential. 💡

What Should We Monitor? 📊

Before diving into tools, let's define what we actually want to keep an eye on:
🔹 JavaScript runtime errors
🔹 Failed API requests
🔹 Core Web Vitals (LCP, FID, CLS, etc.)
🔹 UI freezes or crashes
🔹 User behavior (rage clicks, drop-offs, session flows)

Tools I've Used and Recommend 🛠️

Sentry - My First Line of Defense 🛡️

Sentry is always the first thing I set up in my Next.js projects. It gives detailed error tracking, browser context, and user insights. It helps me catch unexpected bugs early and fix them with confidence. 🚀

LogRocket - Replay User Sessions 🎥

If Sentry tells you what went wrong, LogRocket shows you how it happened. It records user sessions, including mouse movements, clicks, and DOM changes. It has saved me so much time debugging issues that only occur under specific circumstances. 🕵️‍♂️

Vercel Analytics - Lightweight Performance Monitoring 📈

If you're using Vercel, their built-in analytics tool is a great way to track performance metrics like page load times and layout shifts. It's simple, privacy-friendly, and requires zero setup. 😎

Google Analytics (GA4) - Track User Behavior 📊

GA4 gives high-level insights into how users move through your app, where they drop off, and what events they trigger. It helps connect technical metrics with business goals. 💼

Custom Logging - Tailored to Your Product 🛠️

Sometimes generic tools aren't enough. I also implement custom logging for specific user actions or edge cases that matter to my product team. It's lightweight, flexible, and surprisingly powerful. ⚡

Monitoring Is a Culture, Not Just a Tool 🌟

In one of the teams I worked with, we had a simple pre-release checklist that made all the difference:
🔹 Is Sentry enabled for this module?
🔹 Are critical errors being alerted via email or Slack?
🔹 Are we tracking important user actions?
🔹 Are performance metrics being recorded?
Monitoring isn't something you "add later." It should be part of the delivery process from day one. ✅

A Real-World Story 📖

One day, a user reported that the app "just doesn't load" - but only in Safari. Everything worked fine on Chrome and Firefox.
Thanks to monitoring, I discovered that an optional chaining operator caused a crash in Safari 13, which didn't support it. I shipped a quick patch, and the issue disappeared. 🛠️
Without monitoring, I would have had no idea this bug existed. 😱

Final Thoughts 💬

Monitoring in a frontend Next.js app isn't a luxury - it's a requirement. Start with Sentry for error reporting, add LogRocket for session replays, and use GA4 or Vercel Analytics for behavior and performance tracking.
Monitor. Understand. Improve. 🌈
If you've had similar experiences or want to share tools that worked for you, I'd love to hear about them. 😊

Mahdi

7 Mistakes I Made When I First Learned React (And How I Fixed Them)

Mahdi Hosseini — Sat, 19 Apr 2025 18:39:50 +0000

Learning React was one of the most exciting—and confusing—parts of my frontend journey. I made a bunch of mistakes early on that, looking back, totally slowed me down. If I had known what I know now, things would’ve moved much faster.

So here are 7 real mistakes I made when I was just getting started with React, and how I eventually figured them out.

1. Overusing useState for everything

🟥 What I did:
At first, I thought useState was the only way to manage state. I used it for everything, even complex or deeply nested data.

✅ What I learned:
I discovered useReducer for more complex state logic, and started using Context to share state across components. Life got easier real quick.

2. Ignoring project structure

🟥 What I did:
I dumped everything—components, styles, assets—into one big folder. Zero organization.

✅ What I learned:
I started following better structures like feature-based folders and Atomic Design. It made my codebase way easier to manage and scale.

3. Relying too much on CSS classes

🟥 What I did:
I used a million CSS classes for every UI element. It looked messy and was hard to maintain.

✅ What I learned:
Switching to Tailwind CSS and breaking my UI into reusable components helped a lot with both readability and maintainability.

4. Not understanding the difference between JSX and HTML

🟥 What I did:
I treated JSX like it was just plain old HTML, which caused a lot of syntax errors and confusion.

✅ What I learned:
Once I understood that JSX is JavaScript, not HTML (e.g. className, self-closing tags, camelCase), things started to click.

5. Misusing useEffect

🟥 What I did:
I used useEffect without really understanding how it worked. I ended up causing infinite loops or making duplicate API calls.

✅ What I learned:
I learned how to properly use the dependency array and started using tools like React Query and SWR for data fetching.

6. Mixing UI and logic in the same file

🟥 What I did:
All the logic and UI were in the same file. It was hard to test, hard to update, and a mess to read.

✅ What I learned:
I started creating custom hooks to separate logic from presentation. My components became a lot cleaner and easier to manage.

7. Skipping testing entirely

🟥 What I did:
I didn’t write any tests. Debugging was a nightmare when something broke.

✅ What I learned:
I started writing simple tests using Jest and React Testing Library. Even basic tests gave me more confidence in my code.

Final thoughts:

Every one of these mistakes helped me grow. If you’re just getting into React, I hope my experience helps you avoid some of these traps—or at least spot them early.
And if you’ve made similar mistakes, I’d love to hear about them. Let’s learn from each other!

✍️ Written by *Mahdi *– a frontend developer who loves learning and sharing his journey.

🚀 12 JavaScript Interview Questions You NEED to Know (2025 Edition) 🎯

Mahdi Hosseini — Mon, 31 Mar 2025 12:59:34 +0000

Hey fellow devs! 👋 If you're prepping for a frontend interview in 2025, buckle up! You’re gonna face JavaScript fundamentals, tricky async stuff, and some brain-teasing real-world problems. Let's get you ready with 12 must-know questions (and answers) so you can crush your next interview! 💪🔥

1️⃣ `var` vs. `let` vs. `const` – What’s the deal? 🤔

var = Function scope, hoisted like a magic trick 🪄 (but can be messy).
let = Block scope, no redeclaration, safer!
const = Like let but locked in (you can’t reassign it, but you can mutate objects!).

👉 Rule of thumb: Use const by default, let when needed, and avoid var like it’s a memory leak.

2️⃣ How does JavaScript handle async operations? 🤯

JavaScript is single-threaded but deals with async stuff using:

Callbacks (old-school, hello callback hell 👿)
Promises (.then() & .catch() make life easier)
Async/Await (the cleanest way to handle async code)

async function fetchData() {
  try {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error(error);
  }
}

👉 Use async/await. Your future self will thank you. 😎

3️⃣ Explain the Event Loop like I’m 5 🎡

The Event Loop is what keeps JavaScript non-blocking and fast. 🏎️

Call Stack: Runs sync code first.
Task Queue: Holds async callbacks (like setTimeout).
Microtask Queue: Holds promises, gets priority over Task Queue.

👉 Ever wondered why setTimeout(() => console.log(‘Hi’), 0) doesn’t run immediately? Because promises cut the line! ⏳

4️⃣ Closures: What, why, and when? 🧐

A closure is a function that remembers variables from its outer scope even when the outer function has finished executing. 🧠

function outer() {
  let count = 0;
  return function inner() {
    count++;
    console.log(count);
  };
}

const counter = outer();
counter(); // 1
counter(); // 2

👉 Closures are 🔥 for data encapsulation, private variables, and function factories.

5️⃣ Prototypal Inheritance – What’s the magic? ✨

JavaScript doesn’t use classical OOP inheritance (like Java or C#). Instead, it uses prototypes. Every object has a hidden __proto__ that links to another object. 🧬

function Person(name) {
  this.name = name;
}
Person.prototype.sayHello = function() {
  console.log(`Hello, I’m ${this.name}!`);
};

const user = new Person('Alice');
user.sayHello(); // Hello, I’m Alice!

👉 Prototypes are the backbone of JavaScript's object system! Modern syntax? Use class!

6️⃣ Shallow vs. Deep Copy – Clone Wars 🏴‍☠️

Shallow Copy = Only copies the first level, deeper objects are still referenced.
Deep Copy = Fully clones an object, including nested structures.

const obj = { a: 1, b: { c: 2 } };
const shallowCopy = { ...obj };
shallowCopy.b.c = 42;
console.log(obj.b.c); // 42 (Oops! 😱)

const deepCopy = JSON.parse(JSON.stringify(obj));
deepCopy.b.c = 100;
console.log(obj.b.c); // 42 (Phew! 🎉)

7️⃣ `==` vs. `===` – The Battle of Equality ⚔️

== does type coercion (sometimes useful, mostly dangerous).
=== is strict (always prefer it!).

console.log(5 == '5'); // true (😬 weird but true)
console.log(5 === '5'); // false (👍 expected behavior)

👉 Just use ===. Unless you enjoy debugging nightmares. 😆

8️⃣ Generators – The Pause Button ⏸️

Generators are functions that can pause and resume execution. Perfect for iterators and async flows!

function* numberGenerator() {
  yield 1;
  yield 2;
  yield 3;
}

const gen = numberGenerator();
console.log(gen.next().value); // 1
console.log(gen.next().value); // 2

9️⃣ What’s up with `this`? 🤨

this is the most confusing keyword in JavaScript.

Global = window (or undefined in strict mode).
Object method = Refers to the calling object.
Arrow function = Inherits this from its surrounding scope.

const obj = {
  name: 'Alice',
  sayName() {
    console.log(this.name);
  },
};
obj.sayName(); // Alice

👉 Pro tip: If this is acting weird, check how the function is called! 🧐

🔟 Debouncing & Throttling – The Speed Limit 🚦

Debouncing = Delays function execution until after a certain time has passed.
Throttling = Ensures a function runs at most once in a given period.

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

const handleResize = debounce(() => console.log('Resized!'), 300);
window.addEventListener('resize', handleResize);

1️⃣1️⃣ Memory Leaks – Avoiding JavaScript Hoarding 🗑️

Common memory leak causes:

Uncleared event listeners 🛑
Global variables hanging around 🎭
Detached DOM elements 👻
Closures holding onto large objects 🎒

✅ Fix: Use WeakMap, remove event listeners, and clean up DOM nodes properly!

1️⃣2️⃣ `map()`, `forEach()`, or `reduce()`? 🤷‍♂️

map() → Returns a new array.
forEach() → Loops, but doesn’t return a new array.
reduce() → Reduces an array to a single value.

const nums = [1, 2, 3];
const doubled = nums.map(n => n * 2); // [2, 4, 6]
const sum = nums.reduce((acc, n) => acc + n, 0); // 6

🔥 That’s a wrap! If you found this useful, share it with your dev friends! 🚀 Let’s ace those interviews! 💼

frontend #javascript #js #reactjs #interview