DEV Community: gerry leo nugroho

No More Messy Code: How to Master HTML, CSS, and JS Linting in VS Code Like a Pro

gerry leo nugroho — Sun, 04 Jan 2026 06:39:10 +0000

1. Let’s face it: bugs aren’t always born from bad logic.

Happy New Year, code-buddy, marketer, or anyone in between, and welcome to the year of 2026! A new year, a clean slate, and why not a chance to write cleaner code? If you’re like me, you’ve probably kicked off the year with big dreams and an ever-growing to-do list. But let’s take a moment to talk about something that might not be on your vision board but definitely deserves some love: Sometimes it’s the tiniest things, a missing closing tag, a sneaky typo in a class name, or wonky indentation, that bring your UI crashing down. In today’s world of fast-growing front-end ecosystems, where teams, tools, and frameworks collide, it’s all too easy for these little gremlins to slip through unnoticed. Enter linting: your new (or renewed?) best friend!

1.1 What is Linting?

Linting is the process of running a program that analyzes your code for potential errors, bad practices, or deviations from coding standards. Think of it as a spellchecker, but for code. It doesn't just look for typos; it enforces structure, style, and semantics.

The term “lint” originated from a Unix utility written in 1978 to flag suspicious C code. Today, it’s evolved into a vital part of modern development, helping developers write clean, readable, and consistent code across languages like HTML, CSS, and JavaScript.

Reference: Wikipedia - Lint (software)

1.2 Why It Matters in Front-End Development

Unlike compiled languages, HTML, CSS, and JavaScript don’t always scream at you when something goes wrong. Browsers tend to silently ignore mistakes or fallback to default behavior. That might seem forgiving,until you spend hours hunting down why your layout broke or why your JavaScript silently fails on mobile.

Linting helps catch these issues early, ideally right in your code editor before the file is even saved.

Some real benefits of linting:

Cleaner Code: Catch unclosed tags, unused variables, and bad syntax as you type.
Team Consistency: Enforce a shared style guide automatically,no more nitpicking in code reviews.
Faster Debugging: Errors become visible before they reach the browser.
Fewer Production Bugs: Lint rules reduce chances of semantic and runtime issues going unnoticed.

1.3 How Linting Works in VS Code

Modern editors like Visual Studio Code integrate beautifully with linting tools through extensions and configuration files. As you write code, the editor will underline potential issues in real time,offering suggestions, auto-fixes, and sometimes even refactoring help.

Examples:

In HTML, linters like HTMLHint will warn you if an image lacks an alt attribute.
For CSS, Stylelint can catch duplicate properties, invalid values, or even vendor prefix issues.
In JavaScript, ESLint highlights everything from unused variables to deprecated syntax,and integrates seamlessly with modern tooling like Prettier.

1.4 A Quick Real-Life Example

Imagine you're building a product landing page. Your teammate uses 2-space indentation in HTML, while you prefer tabs. One developer forgets to add alt tags to images, another uses a var instead of const in JavaScript. By the time you merge your branches, the code works,but it’s a readability and maintainability nightmare.

Now imagine this instead:

Linting runs the moment you hit save. Errors and warnings appear inline. Code formatting aligns instantly. No more subjective code review debates,your team agrees on code style through config, not discussion.

“An ounce of prevention is worth a pound of cure.”

– Ben Franklin (and probably every senior dev ever)

2. Real Scenario: A Team Working on a Marketing Landing Page

2.1 The Challenge: A Disjointed Development Effort

Imagine a scenario where a marketing team is preparing for a significant product launch. Three developers are tasked with creating a responsive landing page using HTML, CSS, and JavaScript. Each developer brings their unique coding style and preferences:

Developer A prefers using tabs for indentation and is meticulous about semantic HTML but occasionally overlooks alt attributes for images.
Developer B uses spaces for indentation and focuses on rapid development, sometimes at the expense of code clarity.
Developer C is adept at JavaScript but tends to use outdated syntax and lacks consistency in code formatting.

As the project progresses, the team encounters several issues:

Inconsistent Code Formatting: The mix of tabs and spaces leads to misaligned code, making it difficult to read and maintain.
Accessibility Oversights: Missing alt attributes on images compromise the page's accessibility, affecting users relying on screen readers.
Outdated JavaScript Syntax: The use of deprecated JavaScript features results in compatibility issues across different browsers.

These inconsistencies culminate in:

Merge Conflicts: Differing code styles cause frequent conflicts during version control merges, slowing down development.
Quality Assurance Delays: QA testers spend additional time identifying and reporting issues that could have been prevented.
Visual Bugs: Inconsistent styling leads to layout issues, affecting the user experience.

2.2 The Solution: Implementing Linting Tools in VS Code

To address these challenges, the team decides to integrate linting tools into their development workflow using Visual Studio Code (VS Code). Here's how they proceed:

Setting Up Linting Extensions:
- HTMLHint: Helps identify issues in HTML code, such as missing alt attributes and improper tag usage.
- Stylelint: Enforces consistent CSS styling, catching errors like duplicate properties or invalid values.
- ESLint: Analyzes JavaScript code to detect outdated syntax and potential errors.
- Prettier: Automatically formats code according to predefined style rules, ensuring consistency across the codebase.
Configuring Linting Rules:
- The team establishes a shared configuration for each linter, aligning on coding standards and best practices.
- They incorporate these configurations into the project's version control system, ensuring all team members adhere to the same rules.
Integrating with Version Control:
- By incorporating linting checks into the version control workflow, the team ensures that code is validated before merges, reducing conflicts and maintaining code quality.
Continuous Feedback:
- With linting tools integrated into VS Code, developers receive immediate feedback on code issues, allowing for prompt corrections and fostering a culture of clean coding.

2.3 The Outcome: A Cohesive and Efficient Development Process

The implementation of linting tools yields significant benefits:

Enhanced Code Consistency: Uniform formatting and coding standards improve code readability and maintainability.
Reduced Merge Conflicts: Standardized code minimizes discrepancies, leading to smoother merges.
Improved Accessibility and Compatibility: Early detection of issues ensures the landing page is accessible and functions correctly across browsers.
Accelerated Development: Immediate feedback and automated formatting streamline the development process, allowing the team to meet tight deadlines.

By adopting linting tools in VS Code, the team transforms their development workflow, producing a high-quality, accessible, and consistent landing page ready for the product launch.

3. Setting Up Your Environment

In the previous section, we explored the challenges of inconsistent code formatting and how it can hinder collaboration and code quality. Now, let's take actionable steps to set up your VS Code environment with the necessary tools to enforce consistency and catch errors early.

3.1 Essential VS Code Extensions

To enhance your development workflow, consider installing the following extensions:

HTMLHint: Analyzes HTML files for potential issues and enforces best practices.
Stylelint: Lints CSS and SCSS files, ensuring adherence to defined style rules.
ESLint: Identifies and fixes problems in JavaScript code, promoting code quality.
Prettier: Automatically formats code to maintain a consistent style across your project.
EditorConfig for VS Code: Maintains consistent coding styles between different editors and IDEs. (Visual Studio Marketplace, Microsoft Learn)

3.2 Installation Steps

Open VS Code.
Navigate to the Extensions view by clicking on the Extensions icon in the Activity Bar on the side of the window.
Search for each extension by name and click Install. (DEV Community, Visual Studio Marketplace)

3.3 Configuring Each Tool

3.3.1 HTMLHint

Installation: Install the HTMLHint extension from the VS Code Marketplace.

Configuration:

Create a .htmlhintrc file in your project's root directory.

Define your preferred rules. For example:

{
  "tagname-lowercase": true,
  "attr-lowercase": true,
  "attr-value-double-quotes": true,
  "doctype-first": true,
  "tag-pair": true,
  "spec-char-escape": true,
  "id-unique": true,
  "src-not-empty": true,
  "attr-no-duplication": true
}

This configuration enforces lowercase tags and attributes, requires double quotes for attribute values, and ensures that each ID is unique.

3.3.2 Stylelint

Installation:
- Install Stylelint as a development dependency:(Visual Studio Marketplace)
```
npm install --save-dev stylelint stylelint-config-standard
```
- Install the Stylelint extension in VS Code.
Configuration:
- Create a .stylelintrc.json file in your project's root directory with the following content (DEV Community).
```
{
  "extends": "stylelint-config-standard"
}
```
- This setup extends the standard configuration, providing a solid foundation for CSS linting.

3.3.3 ESLint

Installation:
- Install ESLint as a development dependency (Reddit).
```
npm install --save-dev eslint
```
- Install the ESLint extension in VS Code.
Configuration:
- Initialize ESLint in your project:(Visual Studio Marketplace)
```
npx eslint --init
```
- Follow the prompts to configure ESLint according to your project's needs.

3.3.4 Prettier

Installation:
- Install Prettier as a development dependency:
```
npm install --save-dev --save-exact prettier
```
- Install the Prettier extension in VS Code.
Configuration:
- Create a .prettierrc file in your project's root directory to define formatting rules. For example:
```
{
  "semi": true,
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}
```
- This configuration enforces the use of semicolons, single quotes, a maximum line width of 80 characters, and a tab width of 2 spaces.

3.3.5 EditorConfig

Installation: Install the EditorConfig for VS Code extension.
Configuration:
- Create a .editorconfig file in your project's root directory with the following content (Stack Overflow).
```
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
```
- This configuration ensures consistent indentation, line endings, character encoding, and whitespace handling across different editors.

3.4 Enabling Format on Save

To automatically format your code upon saving:

Open VS Code settings (Ctrl + , or Cmd + , on macOS).
Search for "Format On Save" and enable the checkbox.

Alternatively, add the following to your settings.json:

{
  "editor.formatOnSave": true
}

3.5 Integrating Linting with Version Control

To enforce linting rules before code is committed, consider using tools like husky and lint-staged:

Install the dependencies:(Stack Overflow)

npm install --save-dev husky lint-staged

Configure husky to run linting scripts during the pre-commit hook.

This setup ensures that only code adhering to your defined standards is committed to the repository. And by following these steps, you establish a robust development environment that promotes code consistency, reduces errors, and enhances collaboration. In the next section, we'll explore how to configure each linter from scratch, tailoring them to your project's specific needs.

4. Configuring Each Linter from Scratch

4.1 HTMLHint – Enforcing HTML Best Practices

Installation:

Install HTMLHint as a development dependency:(htmlhint.com)

npm install --save-dev htmlhint

Configuration:

Create a .htmlhintrc file in your project's root directory to define your HTML linting rules. Here's an example configuration:

{
  "tagname-lowercase": true,
  "attr-lowercase": true,
  "attr-value-double-quotes": true,
  "doctype-first": true,
  "tag-pair": true,
  "spec-char-escape": true,
  "id-unique": true,
  "src-not-empty": true,
  "attr-no-duplication": true
}

This setup ensures that your HTML code adheres to best practices, such as using lowercase tags and attributes, double quotes for attribute values, and unique IDs.

Usage:

To lint your HTML files, run:

npx htmlhint "**/*.html"

But as in my case, since I’d be doing a lot of Vue.js based project, it should have been modified to the following command line instructions :

npx htmlhint "dist/**/*.html" --config .htmlhintrc

For more details, refer to the HTMLHint Getting Started Guide.

4.2 Stylelint – Maintaining Consistent CSS

Installation:

Install Stylelint along with the standard configuration:(stylelint.io)

npm install --save-dev stylelint stylelint-config-standard

Configuration:

Create a .stylelintrc.json file in your project's root directory with the following content:

{
  "extends": "stylelint-config-standard"
}

This configuration extends the standard Stylelint rules, promoting consistent and error-free CSS code.

Usage:

To lint your CSS files, run: (stylelint.io)

npx stylelint "**/*.css"

This would depend on your current setup, either you're using a framework or plain vanilla CSS, so your milage may vary, but here’s how I go about to apply according to my Vite.js’ needs.

npx stylelint "dist/**/*.css" --config .stylelintrc.json --formatter verbose --color

For more information, visit the Stylelint Configuration Guide.

4.3 ESLint – Ensuring JavaScript Code Quality

Installation:

Install ESLint as a development dependency:

npm install --save-dev eslint

Configuration:

Initialize ESLint in your project:

npx eslint --init
# You can also run this command directly using 
npm init @eslint/config@latest

Follow the prompts to configure ESLint according to your project's needs.

Alternatively, you can create a .eslintrc.json file with a basic configuration:

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "single"]
  }
}

This setup enforces the use of semicolons and single quotes, among other best practices.

Usage:

To lint your JavaScript files, run:

npx eslint "**/*.js"

For comprehensive guidance, refer to the ESLint Configuration Documentation.

4.4 Prettier – Automated Code Formatting

Installation:

Install Prettier as a development dependency:

npm install --save-dev --save-exact prettier

Configuration:

Create a .prettierrc file in your project's root directory to define your formatting preferences:

{
  "semi": true,
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}

This configuration enforces the use of semicolons, single quotes, a maximum line width of 80 characters, and a tab width of 2 spaces.

Usage:

To format your code, run:

npx prettier --write .

For more details, visit the Prettier Configuration Guide. (Prettier)

4.5 Integrating with VS Code:

To enhance your development experience, install the corresponding VS Code extensions for each tool:

Ensure that your VS Code settings enable these tools to run automatically on file save for a seamless development workflow. By meticulously configuring each linter, you establish a robust foundation for maintaining code quality and consistency across your projects. Further more we'll explore how to integrate these tools seamlessly into your development workflow, ensuring that code quality checks are an integral part of your coding process.

5. Integrating Linting into Your Workflow

5.1 Automate Linting with npm Scripts

Incorporate linting commands into your package.json to standardize code checks:

{
  "scripts": {
    "lint:js": "eslint .",
    "lint:css": "stylelint '**/*.css'",
    "format": "prettier --write ."
  }
}

This setup allows your team to execute npm run lint:js, npm run lint:css, or npm run format to enforce code standards consistently.

5.2 Enable Format on Save in VS Code

Configure VS Code to automatically format code upon saving:

Open Settings (Ctrl + , or Cmd + , on macOS).
Search for Format On Save and enable it.

Alternatively, add the following to your settings.json:

{
  "editor.formatOnSave": true
}

This ensures that Prettier formats your code each time you save, maintaining consistency effortlessly.

5.3 Implement Pre-Commit Hooks with Husky and lint-staged

Prevent inconsistent code from entering your repository by setting up pre-commit hooks:

Install dependencies:

npm install --save-dev husky lint-staged

Initialize Husky:
```
npx husky install
```

Add a pre-commit hook:

npx husky add .husky/pre-commit "npx lint-staged"

Define lint-staged tasks in your package.json (Stack Overflow)

{
  "lint-staged": {
    "*.{js,jsx}": ["eslint --fix", "prettier --write"],
    "*.css": ["stylelint --fix", "prettier --write"]
  }
}

This configuration ensures that only code adhering to your linting rules is committed, enhancing code quality across the team.

4. Integrate Linting into Continuous Integration (CI) Pipelines

Automate linting checks in your CI workflows to catch issues early:

GitHub Actions:

name: Lint Code Base

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Dependencies
        run: npm install
      - name: Run ESLint
        run: npm run lint:js
      - name: Run Stylelint
        run: npm run lint:css

This setup ensures that every push or pull request triggers linting checks, maintaining code integrity throughout the development cycle.

5. Customize VS Code Settings for Enhanced Linting

Tailor your VS Code environment to align with your linting tools:

Enable ESLint and Stylelint:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
    "source.fixAll.stylelint": true
  },
  "eslint.validate": ["javascript", "javascriptreact"],
  "stylelint.validate": ["css", "scss"]
}

These settings ensure real-time feedback and automatic fixes, fostering a smoother development experience. By integrating linting tools into your workflow, you establish a robust framework that promotes code consistency, reduces errors, and enhances team collaboration.

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #5)

gerry leo nugroho — Wed, 30 Jul 2025 01:03:51 +0000

Welcome back, blog architects! We’ve laid down our core layout components, setting a sleek foundation with a blurry navbar, multi-column footer, and tailored page layouts. Now, let’s amp up the UX with Navigation, Cards & Grids, and some Interactive Elements, channeling modern’s bold aesthetic—think responsive menus, animated cards, and engaging hover effects. We're going wild with loads of creativity here, leveraging Next.js 15.x.x’s server-side magic and Tailwind CSS 4.x.x’s modern utilities, all while ensuring the code is digestible for newbies and SEO-optimized. Let’s dive into this vibrant continuation!

Navigation: Guiding Users with Style

Navigation is the compass of our blog—intuitive, responsive, and visually striking. We’ll craft a desktop menu with dropdowns, a mobile off-canvas menu, SEO-friendly breadcrumbs, and dynamic pagination.

`src/components/DesktopMenu.tsx` – Horizontal Menu with Dropdowns

"use client"; // Client-side for dropdown interactivity

import Link from "next/link";
import { useState } from "react";
import { FaChevronDown } from "react-icons/fa";

export default function DesktopMenu() {
  const [isDropdownOpen, setIsDropdownOpen] = useState(false); // Tracks dropdown state

  return (
    <nav>
      {/* Simple Links */}
      <Link href="/about">About</Link>
      <Link href="/blog">Blog</Link>

      {/* Dropdown Menu */}
      <div
        onMouseEnter={() => setIsDropdownOpen(true)}
        onMouseLeave={() => setIsDropdownOpen(false)}
      >
        Categories
        {isDropdownOpen && (
          <ul>
            <li>Tech</li>
            <li>Lifestyle</li>
            <li>Coding</li>
          </ul>
        )}
      </div>
      <Link href="/search">Search</Link>
    </nav>
  );
}

Why It’s Awesome

Dropdown: A hover-triggered menu with backdrop-blur-md for a glassy effect, fading in/out smoothly.
Hover Effects: Links scale up with hover:scale-105—a subtle nod to modern design’s interactivity.
Accessibility: ARIA attributes enhance screen reader support.

`src/components/MobileMenu.tsx` – Off-Canvas with Animations

Already integrated into BlurNavbar.tsx from the last section—its off-canvas design uses translate-y animations for a slick mobile experience.

`src/components/Breadcrumbs.tsx` – SEO-Friendly Navigation

import Link from "next/link";

type Crumb = { label: string; href: string };

export default function Breadcrumbs({ crumbs }: { crumbs: Crumb[] }) {
  return (
    <nav>
      <Link href="/">Home</Link>
      {crumbs.map((crumb, index) => (
        <span key={crumb.href}>
          /
          {index === crumbs.length - 1 ? (
            <span>{crumb.label}</span>
          ) : (
            <Link href={crumb.href}>{crumb.label}</Link>
          )}
        </span>
      ))}
    </nav>
  );
}

Usage Example

In src/app/blog/[slug]/page.tsx, add:

<Breadcrumbs
  crumbs={[
    { label: "Blog", href: "/blog" },
    { label: "Post Title", href: "/blog/post-title" },
  ]}
/>

Why It Shines

SEO: Links improve crawlability; the final crumb is text-only for current page semantics.
Responsive: Wraps gracefully on small screens.

`src/components/Pagination.tsx` – Dynamic Pagination

"use client";

import Link from "next/link";
import { usePathname, useSearchParams } from "next/navigation";

export default function Pagination({
  totalPages,
  basePath,
}: {
  totalPages: number;
  basePath: string;
}) {
  const pathname = usePathname();
  const searchParams = useSearchParams();
  const currentPage = Number(searchParams.get("page")) || 1;

  const pages = Array.from({ length: totalPages }, (_, i) => i + 1);

  return (
    <div>
      {pages.map((page) => (
        <Link
          key={page}
          href={`${pathname}?page=${page}`}
          className={currentPage === page ? "active" : ""}
        >
          {page}
        </Link>
      ))}
    </div>
  );
}

Usage Example

In src/app/blog/page.tsx, add:

<Pagination totalPages={10} basePath="/blog" />

Why It’s Great

Dynamic: Uses Next.js’s useSearchParams for page tracking.
Styling: Rounded buttons with hover transitions aligned with modern web design polish.

Cards & Grids: Visual Storytelling

Cards are the heartbeat of our blog’s content—responsive, interactive, and eye-catching.

`src/components/PostCard.tsx` – Enhanced from Last Section

Updated with more flair:

import Link from "next/link";
import Image from "next/image";

type Post = {
  slug: string;
  frontmatter: {
    title: string;
    description: string;
    imageOg?: string;
    category: string;
  };
};

export default function PostCard({
  post,
  variant = "grid",
}: {
  post: Post;
  variant?: "grid" | "list";
}) {
  return (
    <div>
      {/* Image with Hover Zoom */}
      {post.frontmatter.imageOg && (
        <Image
          src={post.frontmatter.imageOg}
          alt={post.frontmatter.title}
          width={300}
          height={200}
          className="hover:scale-105 transition-transform"
        />
      )}

      {/* Content */}
      <div>
        <span>{post.frontmatter.category}</span>
        <h3>{post.frontmatter.title}</h3>
        <p>{post.frontmatter.description}</p>
      </div>
    </div>
  );
}

What’s New?

Category Badge: A rounded tag adds visual hierarchy.
Hover Effects: Card lifts with hover:shadow-xl and image zooms—pure modern design's energy.
Responsive Images: sizes attribute optimizes image loading.

`src/components/CategoryCard.tsx` – Category Highlights

import Link from "next/link";

export default function CategoryCard({
  category,
  count,
}: {
  category: string;
  count: number;
}) {
  return (
    <div>
      {/* Overlay Effect */}
      <div>
        <span>{category}</span>
        <span>{count} Posts</span>
      </div>
    </div>
  );
}

Usage Example

In src/app/page.tsx’s trending section:

<CategoryCard category="Tech" count={15} />

Why It Pops

Gradient: A bold background with a hover overlay adds depth.
Relative Positioning: Ensures text stays above the overlay.

`src/components/AuthorCard.tsx` – Author Spotlight

import Image from "next/image";
import { FaTwitter, FaLinkedin } from "react-icons/fa";

export default function AuthorCard({
  name,
  bio,
  avatar,
  twitter,
  linkedin,
}: {
  name: string;
  bio: string;
  avatar: string;
  twitter?: string;
  linkedin?: string;
}) {
  return (
    <div>
      <Image src={avatar} alt={name} width={100} height={100} />
      <h3>{name}</h3>
      <p>{bio}</p>
      {twitter && <a href={twitter}><FaTwitter /></a>}
      {linkedin && <a href={linkedin}><FaLinkedin /></a>}
    </div>
  );
}

Why It Works

Compact: A clean layout for author bios, with social icons for engagement.
Dark Mode: Tailwind’s dark: classes ensure readability.

Interactive Elements: Engaging Users

Let’s add some interactivity with hover effects and reusable components.

`src/components/HoverImage.tsx` – Image with Zoom

import Image from "next/image";

export default function HoverImage({
  src,
  alt,
  width,
  height,
}: {
  src: string;
  alt: string;
  width: number;
  height: number;
}) {
  return (
    <div className="group">
      <Image
        src={src}
        alt={alt}
        width={width}
        height={height}
        className="group-hover:scale-110 transition-transform"
        loading="lazy"
      />
    </div>
  );
}

Why It’s Engaging

Zoom: group-hover:scale-110 creates a subtle, inviting effect.
Lazy Loading: Native loading="lazy" boosts performance.

`src/components/Tooltip.tsx` – Contextual Info

"use client";

import { useState } from "react";

export default function Tooltip({
  content,
  children,
}: {
  content: string;
  children: React.ReactNode;
}) {
  const [isVisible, setIsVisible] = useState(false);

  return (
    <div
      onMouseEnter={() => setIsVisible(true)}
      onMouseLeave={() => setIsVisible(false)}
    >
      {children}
      {isVisible && <span>{content}</span>}
    </div>
  );
}

Usage Example

<Tooltip content="This is a tooltip">
  <button>Click here</button>
</Tooltip>

Why It’s Handy

Simple: A hover-triggered tooltip with Tailwind styling.
Accessible: Naturally works with mouse and touch (though keyboard support could be added).

To Be Continued

We’ve tackled Navigation, Cards & Grids, and started Interactive Elements—all with modern-design-inspired flair, responsive design, and SEO-friendly code. This is part two of a multi-part journey due to the epic scope you’ve set!

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #4)

gerry leo nugroho — Mon, 21 Jul 2025 23:00:40 +0000

Welcome back, blog architects! With our project initialized, configured, and structured, it’s time to roll up our sleeves and code the beating heart of our Next.js 15.x.x and Tailwind CSS 4.x.x blog. In this section, we’re diving into the "Core Layout Components"—the foundational pieces that define our app’s shell.

Inspired by the bold, user-friendly vibe of Modern web design, we’ll build a responsive, visually stunning blog with modern twists like blurry navbars, dynamic footers, and accessibility-first design. As a senior systems analyst, I’m here to deliver code that’s clean, heavily commented, and packed with cutting-edge techniques—perfect for newbies and pros alike. Let’s start with the App Shell components: BlurNavbar, Footer, Layout, Container, and SkipNav.

Step 1: App Shell, The Blog’s Structural Backbone

The App Shell is the scaffolding that holds our blog together, ensuring consistency, accessibility, and a polished UX across every page. These components leverage Tailwind CSS 4.x.x’s latest utilities—like glassmorphism and gradient transitions—and Next.js 15.x.x’s App Router for seamless integration. Let’s break down each piece with code you can copy, tweak, and love.

- `BlurNavbar`: A Stunning, Scroll-Aware Navbar with Blur Effect

The BlurNavbar is our blog’s crown jewel—a responsive, sticky navbar with a frosted glass effect that shifts opacity on scroll. Think contemporary’s bold header, but with a modern twist.

// src/components/BlurNavbar.tsx
'use client'; // Client-side for scroll handling

import Link from 'next/link';
import { useState, useEffect } from 'react';
import { useTheme } from 'next-themes';
import { FaBars, FaTimes } from 'react-icons/fa'; // Font icons for hamburger menu

export default function BlurNavbar() {
  const { theme, setTheme } = useTheme(); // Dark mode toggle
  const [isScrolled, setIsScrolled] = useState(false); // Track scroll position
  const [isMobileMenuOpen, setIsMobileMenuOpen] = useState(false); // Mobile menu state

  // Handle scroll effect
  useEffect(() => {
    const handleScroll = () => {
      setIsScrolled(window.scrollY > 50); // Opaque after 50px scroll
    };
    window.addEventListener('scroll', handleScroll);
    return () => window.removeEventListener('scroll', handleScroll); // Cleanup
  }, []);

  return (
    <nav
      className={`fixed top-0 left-0 w-full z-50 transition-colors duration-300 ${
        isScrolled ? 'backdrop-blur-md bg-white/80 dark:bg-gray-900/80' : 'bg-transparent'
      }`}
      role="banner"
      aria-label="Main navigation"
    >
      {/* Logo */}
      <div className="container mx-auto px-4 py-3 flex justify-between items-center">
        <Link href="/" className="text-xl font-bold text-black dark:text-white">
          My Blog
        </Link>

        {/* Desktop Menu */}
        <ul className="hidden md:flex space-x-4">
          <li>
            <Link href="/blog" className="hover:underline underline-offset-4">
              Blog
            </Link>
          </li>
          <li>
            <Link href="/about" className="hover:underline underline-offset-4">
              About
            </Link>
          </li>
          <li>
            <Link href="/search" className="hover:underline underline-offset-4">
              Search
            </Link>
          </li>
        </ul>

        {/* Theme Toggle */}
        <button
          onClick={() => setTheme(theme === 'dark' ? 'light' : 'dark')}
          className="p-2 rounded-full bg-white/20 text-white hover:bg-white/30 transition-colors duration-200"
          aria-label="Toggle dark mode"
        >
          {theme === 'dark' ? '☀️' : '🌙'}
        </button>

        {/* Mobile Menu Toggle */}
        <button
          onClick={() => setIsMobileMenuOpen(!isMobileMenuOpen)}
          aria-label="Toggle mobile menu"
        >
          {isMobileMenuOpen ? <FaTimes /> : <FaBars />}
        </button>
      </div>

      {/* Mobile Menu */}
      {isMobileMenuOpen && (
        <ul className="md:hidden bg-white dark:bg-gray-900 p-4 space-y-2">
          <li>
            <Link href="/blog" className="block hover:underline underline-offset-4">
              Blog
            </Link>
          </li>
          <li>
            <Link href="/about" className="block hover:underline underline-offset-4">
              About
            </Link>
          </li>
          <li>
            <Link href="/search" className="block hover:underline underline-offset-4">
              Search
            </Link>
          </li>
          <li>
            <button
              onClick={() => setTheme(theme === 'dark' ? 'light' : 'dark')}
              className="text-white"
            >
              {theme === 'dark' ? 'Light Mode' : 'Dark Mode'}
            </button>
          </li>
        </ul>
      )}
    </nav>
  );
}

Why It’s Awesome

Blur Effect: backdrop-blur-md creates a frosted glass look, a Tailwind 4.x.x gem.
Scroll-Aware: The navbar shifts from transparent to a gradient background on scroll, using useEffect for smooth transitions.
Responsive: Hidden desktop menu on mobile, replaced with an animated hamburger toggle (FaBars/FaTimes from react-icons).
Hover Effects: Links get an underline with underline-offset-4 on hover—a subtle, modern touch.
Accessibility: role="banner" and aria-label ensure screen reader compatibility.

- Footer: A Multi-Column Masterpiece

Our Footer is a multi-column beauty with social links, a newsletter signup, and a sitemap—perfect for modern design-style engagement.

// src/components/Footer.tsx
import Link from 'next/link';
import { FaTwitter, FaFacebook, FaLinkedin } from 'react-icons/fa';

export default function Footer() {
  return (
    <footer className="bg-gradient-to-t from-gray-900 to-gray-800 text-white py-12">
      <div className="container mx-auto px-4 grid grid-cols-1 md:grid-cols-4 gap-8">
        {/* About Section */}
        <div>
          <h3 className="text-lg font-bold">About My Blog</h3>
          <p className="mt-2">
            A modern blog built with Next.js 15 and Tailwind CSS 4, delivering cutting-edge content.
          </p>
        </div>

        {/* Sitemap */}
        <div>
          <h3 className="text-lg font-bold">Sitemap</h3>
          <ul className="mt-2 space-y-2">
            <li>
              <Link href="/" className="hover:underline">
                Home
              </Link>
            </li>
            <li>
              <Link href="/blog" className="hover:underline">
                Blog
              </Link>
            </li>
            <li>
              <Link href="/about" className="hover:underline">
                About
              </Link>
            </li>
            <li>
              <Link href="/search" className="hover:underline">
                Search
              </Link>
            </li>
          </ul>
        </div>

        {/* Social Links */}
        <div>
          <h3 className="text-lg font-bold">Follow Us</h3>
          <div className="flex space-x-4 mt-2">
            <Link href="#" className="hover:text-blue-400">
              <FaTwitter />
            </Link>
            <Link href="#" className="hover:text-blue-600">
              <FaFacebook />
            </Link>
            <Link href="#" className="hover:text-blue-700">
              <FaLinkedin />
            </Link>
          </div>
        </div>

        {/* Newsletter Signup */}
        <div>
          <h3 className="text-lg font-bold">Newsletter</h3>
          <form className="mt-2">
            <input
              type="email"
              placeholder="Enter your email"
              className="w-full p-2 bg-gray-700 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500"
            />
            <button
              type="submit"
              className="mt-2 w-full bg-blue-600 text-white py-2 rounded-md hover:bg-blue-700 transition-colors"
            >
              Subscribe
            </button>
          </form>
        </div>
      </div>

      {/* Copyright */}
      <div className="mt-8 text-center text-sm">
        © {new Date().getFullYear()} My Blog. All rights reserved.
      </div>
    </footer>
  );
}

Highlights

Multi-Column: A responsive grid layout shifts from one column on mobile to four on desktop.
Gradient: bg-gradient-to-t ties into our theme for a cohesive look.
Social Icons: react-icons adds flair with hover transitions.
Newsletter: A simple form (extendable with backend logic) styled with Tailwind’s focus states.
SEO: External links use rel="noopener noreferrer" for security.

- Layout: The Universal Wrapper

The Layout component ensures every page has a consistent structure, integrating our navbar and footer.

// src/components/Layout.tsx
import { ThemeProvider } from 'next-themes';
import BlurNavbar from './BlurNavbar';
import Footer from './Footer';
import SkipNav from './SkipNav';
import { NextSeo } from 'next-seo';

export default function Layout({ children, title, description }: { children: React.ReactNode; title?: string; description?: string }) {
  // Default SEO props, overrideable by pages
  const defaultTitle = 'My Blog';
  const defaultDescription = 'A modern blog built with Next.js 15 and Tailwind CSS 4';

  return (
    <ThemeProvider attribute="class">
      <NextSeo
        title={title || defaultTitle}
        description={description || defaultDescription}
      />
      <SkipNav />
      <BlurNavbar />
      <main>{children}</main>
      <Footer />
    </ThemeProvider>
  );
}

Key Features

SEO: NextSeo injects dynamic meta tags, configurable per page.
Dark Mode: ThemeProvider ensures theme consistency across components.
Accessibility: Links to SkipNav for keyboard navigation.
Flexibility: Props allow page-specific titles and descriptions.

- Container: Responsive Content Wrapper

The Container keeps our content centered and constrained, with responsive padding.

// src/components/Container.tsx
export default function Container({ children, className = '' }: { children: React.ReactNode; className?: string }) {
  return (
    <div className={`container mx-auto px-4 sm:px-6 lg:px-8 ${className}`}>
      {children}
    </div>
  );
}

Why It Works

Responsive: Tailwind’s sm: and lg: prefixes adjust padding based on screen size.
Max-Width: max-w-7xl (1280px) mimics modern design’s readable content width.
Customizable: Optional className prop for extra styling.

- SkipNav: Accessibility First

The SkipNav component boosts accessibility by letting users bypass the navbar.

// src/components/SkipNav.tsx
export default function SkipNav() {
  return (
    <a
      href="#main"
      className="sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 focus:z-50 focus:bg-blue-600 focus:text-white focus:py-2 focus:px-4 focus:rounded-md"
    >
      Skip to main content
    </a>
  );
}

Accessibility Win

Screen Reader: sr-only hides it visually but keeps it accessible.
Focus Styling: Becomes visible and styled on focus, with a gradient background for flair.

Step 2: Tying It Together

To use these components, update src/app/layout.tsx:

// src/app/layout.tsx
import Layout from '@/components/Layout';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <Layout>{children}</Layout>
      </body>
    </html>
  );
}

And test with src/app/page.tsx:

// src/app/page.tsx
import Container from '@/components/Container';

export default function Home() {
  return (
    <Container>
      <h1>Welcome to My Blog</h1>
      <p>Built with Next.js 15 and Tailwind CSS 4.</p>
    </Container>
  );
}

Run npm run dev --turbopack and visit http://localhost:3000. You’ll see a stunning navbar, centered content, and a rich footer—all responsive and SEO-ready.

TLDR, Core Layout Components

These App Shell components set the stage for a blog that’s as beautiful as it is functional. With a blurry, scroll-aware navbar, a feature-packed footer, and accessibility baked in, we’re channeling modern web’s energy while pushing the envelope with Tailwind 4.x.x and Next.js 15.x.x. Next, we’ll tackle Page Layouts—stay tuned for hero sections, grids, and more!

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #3)

gerry leo nugroho — Mon, 21 Jul 2025 02:28:37 +0000

Hello again, blog builders! After initializing our project and configuring the setup of Next.js 15.x.x and Tailwind CSS 4.x.x, we are ready to carve out the folders fstructure that will bring our modern blog to life. I’m so thrilled to guide you through this step with the depth and detail you’ve come to expect.

Our goal? A clean, intuitive directory layout that supports our feature-rich blog—think categories, tagging, search, dark mode, and more—all while keeping our codebase organized and maintainable. Reflecting your updates (like the unplugin-fonts switch and Tailwind’s manual install), let’s craft a blueprint that’s both functional and fabulous.

Step 1: Why Structure Matters

A well-organized folder structure isn’t just about aesthetics—it’s about efficiency. With Next.js’s App Router, reusable components, MDX content, and utility functions, we need a layout that scales with our ambitions. Our blog will live in the src/ directory (thanks to our create-next-app choice), keeping source code tidy and separate from config files. Let’s break down each folder, its purpose, and how it ties into our tech stack.

Step 2: The Full Project Folder Structure

Here’s the complete directory tree for our blog/ project, heavily commented for clarity:

blog/
├── src/                      # Source code lives here, keeping the root clean
│   ├── app/                 # App Router directory for pages and layouts
│   │   ├── layout.tsx       # Root layout with global SEO and theme setup
│   │   ├── page.tsx         # Home page (blog index with latest posts)
│   │   ├── about/           # Static page directory
│   │   │   ├── page.tsx     # About page with static content
│   │   ├── blog/            # Blog-related pages
│   │   │   ├── page.tsx     # Blog listing page (all posts)
│   │   │   ├── [slug]/      # Dynamic route for individual posts
│   │   │   │   ├── page.tsx # Blog detail page with MDX content
│   │   ├── author/          # Author-specific pages
│   │   │   ├── [authorId]/  # Dynamic route for author profiles
│   │   │   │   ├── page.tsx # Author page listing their posts
│   │   ├── search/          # Search functionality
│   │   │   ├── page.tsx     # Search results page with fuzzy search
│   ├── components/          # Reusable UI components
│   │   ├── StickyNav.tsx    # Sticky navigation bar with gradient styling
│   │   ├── Footer.tsx       # Footer with RSS link and copyright
│   │   ├── PostCard.tsx     # Card component for blog post previews
│   │   ├── CommentSection.tsx # Client-side commenting system
│   │   ├── ThemeToggle.tsx  # Dark mode toggle button
│   ├── content/             # MDX files for blog posts
│   │   ├── post1.mdx        # Sample post 1 (more to come later)
│   │   ├── post2.mdx        # Sample post 2
│   │   └── ...              # Space for 10 total dummy posts
│   ├── lib/                 # Utility functions and logic
│   │   ├── posts.ts         # Functions to fetch and parse MDX posts
│   │   ├── rss.ts           # RSS feed generation logic
│   │   ├── search.ts        # Fuzzy search implementation with Fuse.js
│   │   ├── seo.ts           # SEO and JSON-LD helper functions
│   ├── styles/              # Global stylesheets
│   │   ├── globals.css      # Tailwind setup and custom variables
├── public/                  # Static assets for the blog
│   ├── images/              # Folder for OG images and other assets
│   │   ├── og-default.jpg   # Default Open Graph image
│   ├── rss.xml              # Generated RSS feed file
│   └── favicon.ico          # Site favicon
├── package.json             # Dependency and script definitions
├── next.config.ts           # Next.js configuration
├── postcss.config.mjs       # PostCSS setup for Tailwind
├── tailwind.config.js       # Tailwind CSS configuration
├── tsconfig.json            # TypeScript settings
├── .gitignore               # Git ignore rules

Step 3: Diving Into Each Directory

Let’s dive into each folder, detailing its purpose and seamless integration with Next.js 15.x.x and Tailwind CSS 4.x.x. From the app/ directory’s dynamic routing to reusable components in components/, MDX content in content/, and utility functions in lib/, this structure ensures scalability, maintainability, and efficiency for our modern blog. Each folder plays a vital role in our feature-rich setup.

3.1: `src/app/` – The Heart of Our Pages

The app/ directory leverages Next.js’s App Router, introduced in version 13 and refined in 15.x.x. It’s where our pages and layouts live, using file-system-based routing.

layout.tsx: The root layout wraps all pages, setting up global SEO with next-seo, dark mode with next-themes, and our StickyNav and Footer components. It’s the glue that holds our UI together.
page.tsx: Our home page doubles as the blog index, displaying a grid of posts fetched server-side with React Server Components—a Next.js 15 superpower.
about/page.tsx: A static page for “About Us” content, styled with Tailwind’s modern utilities.
blog/: Houses blog-related routes.
- page.tsx: Lists all blog posts, perfect for browsing by category or tag later.
- [slug]/page.tsx: A dynamic route rendering individual MDX posts, complete with comments and SEO metadata.
author/[authorId]/page.tsx: Dynamic author pages showing their posts—great for multi-author blogs.
search/page.tsx: A client-side search page powered by fuse.js, displaying results in a responsive grid.

3.2 `src/components/` – Reusable Building Blocks

Components are the Lego bricks of our UI, styled with Tailwind CSS 4.x.x for consistency and flair.

StickyNav.tsx: A sticky navigation bar with a gradient background, linking to key pages and featuring our ThemeToggle.
Footer.tsx: A simple footer with copyright info and an RSS link, styled for dark mode compatibility.
PostCard.tsx: A card component for post previews, using Tailwind’s responsive classes and hover effects.
CommentSection.tsx: A client-side commenting system (marked 'use client' for Next.js), extendable with a backend later.
ThemeToggle.tsx: A button to switch between light and dark modes, synced with next-themes.

3.3 `src/content/` – Where Blog Posts Live

This folder stores our MDX files—the lifeblood of our blog. Each file (e.g., post1.mdx) contains frontmatter (title, tags, etc.) and Markdown content, parsed by @next/mdx and gray-matter. We’ll add 10 dummy posts later, but for now, it’s a placeholder for our creative output.

3.4 `src/lib/` – Utility Functions for Logic

The lib/ directory keeps our codebase DRY (Don’t Repeat Yourself) with reusable functions.

posts.ts: Handles fetching and parsing MDX files, supporting categories and tags.
rss.ts: Generates our RSS feed with the rss library, output to public/rss.xml.
search.ts: Implements fuzzy search with fuse.js, optimized for quick post lookups.
seo.ts: Centralizes SEO and JSON-LD logic with next-seo for consistency.

3.5 `src/styles/` – Styling Headquarters

globals.css: Our global stylesheet imports Tailwind’s base, components, and utilities, plus custom CSS variables for theming. It’s where Tailwind 4.x.x’s CSS-first approach shines.

3.6 `public/` – Static Assets Depot

images/: Stores Open Graph images (e.g., og-default.jpg) and other static visuals.
rss.xml: The generated RSS feed, accessible at /rss.xml.
favicon.ico: A favicon for browser tabs—small but essential.

Step 4: Root-Level Files

package.json: Defines our dependencies (e.g., next@15.1.7, tailwindcss@4.0.9) and scripts, updated per your input.
next.config.ts, postcss.config.mjs, tailwind.config.js: Our configs from the last section, driving Next.js and Tailwind.
tsconfig.json: TypeScript settings, auto-generated with our create-next-app options.
.gitignore: Excludes node_modules/, .next/, and logs, keeping Git clean.

Step 5: Testing the Structure

Create these folders manually or tweak the scaffolded output from create-next-app. Add a basic src/app/page.tsx if it’s missing:

export default function Home() {
  return (
    <div className="to-light-blue-500 flex h-screen items-center justify-center bg-gradient-to-tl from-cyan-400">
      <h1 className="bg-clip-text text-center font-mono text-9xl text-cyan-700">
        Welcome to My Blog
      </h1>
    </div>
  );
}

Run npm run dev --turbopack and visit http://localhost:3000. Seeing “Welcome to My Blog” styled with Inter confirms our structure and configs are humming along.

Step 6: Wrapping Up the Folder Structure

There you have it—a meticulously crafted folder structure for our Next.js and Tailwind CSS blog! From the App Router’s dynamic pages to reusable components and MDX content, this layout sets us up for success. It’s clean, commented, and ready to scale with features like search, dark mode, and SEO. Next, we’ll breathe life into these folders with code—stay tuned for the implementation!

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #2)

gerry leo nugroho — Sun, 20 Jul 2025 01:06:47 +0000

Welcome Back, Fellow Builders! After laying the foundation in our project initialization, we’re now ready to shape the heart of our blog with configuration files. This step is where the magic happens—turning our raw tech stack into a finely tuned machine. We’ll configure Next.js 15.1.7 to handle MDX content and modern typography, set up Tailwind CSS 4.x.x for sleek styling.

These files are:

next.config.ts
postcss.config.mjs
tailwind.config.js

And one file to import the default tailwind to out styling.

src/app/globals.css

So let’s dive in with precision and flair.

Step 1: Next.js Configuration with `next.config.ts`

First up is next.config.ts, the command center for our Next.js app. This file lets us customize how Next.js compiles, bundles, and serves our blog, and we’ll spice it up with MDX support, modern features, and a custom Webpack config for advanced use cases. Based on our package.json, we’re running Next.js 15.1.7, so let’s ensure our setup leverages its latest goodies—like the Rust-based MDX compiler and a touch of Webpack magic.

// next.config.ts
import mdx from '@next/mdx';
import UnpluginFonts from 'unplugin-fonts/webpack';

// Enable MDX support with Next.js
const withMDX = mdx({
  extension: /\.mdx?$/, // Support both .md and .mdx files
  options: {
    remarkPlugins: [], // Add remark plugins here if needed
    rehypePlugins: []  // Add rehype plugins here if needed
  }
});

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Specify file extensions Next.js should recognize
  pageExtensions: ['ts', 'tsx', 'md', 'mdx'],

  // Experimental features for Next.js 15.x.x
  experimental: {
    mdxRs: true,         // Use Rust-based MDX compiler for faster builds
    reactCompiler: false  // Integrate React 19 compiler for optimized rendering, but we put false value for the time being.
  },

  // Custom Webpack configuration for advanced use cases
  webpack: (config, { isServer }) => {
    // Add unplugin-fonts to Webpack for Google Fonts integration
    config.plugins.push(
      UnpluginFonts({
        google: {
          families: [
            'Inter:400,700',    // Sleek sans-serif for general text
            'Merriweather:300,400' // Elegant serif for headings
          ]
        }
      })
    );

    // Example: Add custom loader for specific file types (e.g., SVGs)
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'] // Requires `npm install @svgr/webpack` if used
    });

    // Optimize server-side vs client-side builds
    if (!isServer) {
      config.optimization.splitChunks = {
        chunks: 'all', // Enable code splitting for better caching
      };
    }

    return config;
  }
};

// Export the configuration with MDX support
export default withMDX(nextConfig);

What’s Happening Here?

MDX Integration: The @next/mdx plugin lets us write blog posts in MDX, blending Markdown with JSX. We’ve set it to recognize both .md and .mdx files for flexibility.
Experimental Features: mdxRs swaps the default MDX compiler for a Rust-based one—faster builds, happier devs. reactCompiler taps into Next.js 15’s integration with React 19’s compiler, optimizing our components automatically.
Custom Webpack: We’ve added unplugin-fonts/webpack to load Google Fonts efficiently. The Webpack config also includes a placeholder for SVG handling (install @svgr/webpack if needed) and a server-side optimization tweak—demonstrating how to extend Next.js for advanced scenarios.
TypeScript: Written in .ts for type safety, matching your TypeScript-enabled project.

This file ensures our blog is fast, font-ready, and future-proof.

Step 2: PostCSS Configuration with `postcss.config.mjs`

Next, we tackle postcss.config.mjs. Since we’re using Tailwind CSS 4.0.8 with @tailwindcss/postcss, PostCSS is our CSS processor of choice. This config ties Tailwind into our build pipeline, ensuring our styles are processed efficiently. If the file is not available already, please create one in the root of your project folder, give it a name postcss.config.mjs and fill-up the value as per the following:

Here’s the setup:

// postcss.config.mjs

/** @type {import('postcss-load-config').Config} */
const config = {
  plugins: {
    '@tailwindcss/postcss': {}, // Tailwind CSS 4 integration
    // autoprefixer: {}, // Adds vendor prefixes for broader browser support
  },
};

export default config;

Why This Matters

Tailwind Plugin: The @tailwindcss/postcss entry hooks Tailwind into PostCSS, enabling its utility-first magic. Since we installed it manually (npm install tailwindcss@4.x.x @tailwindcss/postcss postcss), this ensures we’re running the latest version.
Autoprefixer: This bonus plugin adds prefixes (e.g., -webkit-) to CSS properties, ensuring our blog looks flawless across browsers like Chrome, Firefox, and Safari.

Place this file in your blog/ root alongside next.config.mjs. It’s a small but mighty piece of the puzzle.

Step 3: Tailwind CSS Configuration: Styling with Elegance

Now, let’s configure Tailwind CSS in tailwind.config.js. This file defines our design system—fonts, colors, and plugins—while embracing Tailwind 4.x.x’s CSS-first approach. Here’s the detailed setup:

// tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
    // Specify where Tailwind should look for classes
    content: [
        "./src/**/*.{ts,tsx,md,mdx}", // Default content directory
        "./src/pages/**/*.{ts,tsx,md,mdx}", // Legacy pages directory (if used)
        "./src/components/**/*.{ts,tsx}", // Reusable components
        "./src/app/**/*.{ts,tsx}", // App Router files
    ],

    theme: {
        extend: {
            // Custom font families from Google Fonts
            fontFamily: {
                sans: ["Inter", "sans-serif"], // Clean, modern sans-serif
                serif: ["Merriweather", "serif"], // Elegant serif for prose
            },

            // Gradient colors for a sleek, modern design
            colors: {
                gradientStart: "#4f46e5", // Indigo for vibrant gradients
                gradientEnd: "#9333ea", // Purple for a trendy finish
            },

            // Customize typography plugin for blog content
            typography: (theme) => ({
                DEFAULT: {
                    css: {
                        color: theme("colors.gray.800"), // Readable text in light mode
                        "h1, h2, h3": {
                            fontFamily: theme("fontFamily.serif"), // Serif headings for flair
                        },
                    },
                },
                dark: {
                    css: {
                        color: theme("colors.gray.200"), // Crisp text in dark mode
                    },
                },
            }),
        },
    },

    // Enable Tailwind plugins
    plugins: [
        require("@tailwindcss/typography"), // Beautiful prose styling
    ],

    // Use class-based dark mode
    darkMode: "class",
};

Breaking It Down

Content: We tell Tailwind where to look for classes—our src/ directory covers components, App Router pages, and any legacy pages/. This ensures purging works efficiently in production.
Theme Extensions:
- Fonts: We sync with unplugin-fonts by defining Inter for body text and Merriweather for headings—modern and readable.
- Colors: Custom gradient colors (gradientStart and gradientEnd) give our blog a trendy, sleek vibe.
- Typography: The @tailwindcss/typography plugin gets a tweak—light and dark mode text colors, plus serif headings for a polished look.
Plugins: Adding @tailwindcss/typography ensures our MDX blog posts render beautifully with sensible defaults.
Dark Mode: The class strategy integrates with next-themes for seamless light/dark switching.

Save this as tailwind.config.js in your blog/ root. It’s our design foundation.

Step 4: Global CSS: Setting the Stage with Tailwind

Finally, let’s craft src/globals.css to apply Tailwind’s base styles and define custom variables for theming. This file lives in src/styles/ (create the folder if it’s not there yet):

/* src/globals.css */
@tailwind base; /* Reset and base styles */
@tailwind components; /* Custom components (if needed later) */
@tailwind utilities; /* Utility classes */

/* Custom CSS variables for theming */
@layer base {
  :root {
    --bg-color: #ffffff; /* Light mode background */
    --text-color: #1f2937; /* Light mode text */
    --card-bg: #f9fafb; /* Light mode card background */
  }
  .dark {
    --bg-color: #1f2937; /* Dark mode background */
    --text-color: #d1d5db; /* Dark mode text */
    --card-bg: #374151; /* Dark mode card background */
  }
  /* Apply variables globally */
  body {
    @apply bg-[var(--bg-color)] text-[var(--text-color)]; /* Dynamic theming */
    font-family: 'Inter', sans-serif; /* Default font */
  }
}

What’s Going On?

Tailwind Directives: @tailwind base resets browser styles, @tailwind components is a placeholder for custom components (we’ll use it later), and @tailwind utilities brings in all those handy classes.
CSS Variables: Inside @layer base, we define --bg-color, --text-color, and --card-bg for light and dark modes. The .dark class toggles these values when next-themes applies the dark class to <html>.
Body Styling: Using @apply, we dynamically set the background and text colors with our variables, ensuring a cohesive look. The font-family defaults to Inter for consistency.

This file ties Tailwind to our app—create src/styles/ and save it there.

Step 5: Testing the Configuration

To verify, update src/app/page.tsx to use our styles:

export default function Home() {
  return (
    <div className="to-light-blue-500 mt-20 bg-gradient-to-r from-cyan-400 p-20">
      <h1 className="bg-clip-text text-center font-mono text-9xl text-cyan-700">
        Welcome to My Blog
      </h1>
    </div>
  );
}

Run the following command in your terminal

npm run dev --turbopack

Next fire-up your browser of choice, and visit [http://localhost:3000](http://localhost:3000). You should see a gradient-styled heading in Mono-font—proof our configs are humming along.

Step 6: Wrapping Up Configuration

There you have it! We’ve configured Next.js 15.1.7 to handle MDX and fonts, set up PostCSS for Tailwind CSS 4.x.x, defined a sleek design system, and applied global styles—all tailored to our project requirements. These files are the backbone of our blog, ensuring it’s fast, stylish, and feature-ready. Next, we’ll venture more for the structure of our project folders—I'll see you there soon!

Jekyll, Cloudflare Pages & Workers: A Guide to Dynamic Image Compression & Delivery (Part #1)

gerry leo nugroho — Sun, 20 Jul 2025 01:05:46 +0000

If you’ve ever built a website, you know that images can make or break the user experience. They bring your content to life, but they can also slow it down if not handled properly. Large, unoptimized images can lead to sluggish load times, frustrated visitors, and even lower search engine rankings. But here’s the good news: you don’t have to manually resize, compress, or convert every image to keep your site running smoothly.

In this guide, we’ll show you how to automate image optimization using Jekyll, Cloudflare Pages, and Cloudflare Workers. Together, these tools create a seamless workflow where your static site stays lightweight and fast, while images are dynamically optimized on the fly. Here’s what we’re aiming for:

Modern Image Formats: Automatically convert images to WebP (or other modern formats) without touching your HTML.
Responsive Images: Resize images dynamically based on the user’s device, so everyone gets the perfect fit—whether they’re on a phone, tablet, or desktop.
Smart Caching: Cache optimized images at Cloudflare’s edge and in the browser, so repeat visitors get lightning-fast load times.
Backward Compatibility: If someone’s using an older browser that doesn’t support WebP, no worries—they’ll still see the original image format.

The best part? You won’t need to change a single line of your HTML. Everything happens behind the scenes, thanks to Cloudflare Workers intercepting and transforming image requests in real time. By the end of this guide, you’ll have a Jekyll-powered site that’s not only beautiful but also blazing fast—and you’ll have learned how to leverage the power of serverless computing to handle heavy lifting like image optimization. Let’s dive in!

1. Setting Up the Jekyll Site: A Step-by-Step Guide

Before we dive into building and optimizing your Jekyll site, let’s make sure you have all the tools you need to get started. Don’t worry, we’ll walk you through everything from installing Git and Ruby to setting up Jekyll itself. By the end of this section, you’ll have a fully functional Jekyll environment ready to roll.

1.1 Installing Git for Version Control

Git is essential for managing your project’s source code, especially since we’ll be deploying our Jekyll site to GitHub later. If you don’t already have Git installed, here’s how to get it up and running:

Windows: Download the latest version of Git from the official website and follow the installer instructions. Once installed, open a terminal and run:

  git --version

This should display the installed version of Git, confirming that it’s ready to go.

macOS: Git usually comes pre-installed on macOS, but you can update to the latest version using Homebrew:

  brew install git

Verify the installation with:

  git --version

Linux: Use your package manager to install Git. For example:

  sudo apt update && sudo apt install git  # For Ubuntu/Debian
  sudo yum install git                     # For CentOS/Fedora

Check the installation with:

  git --version

Once Git is installed, you’re ready to clone the Jekyll theme we’ll be using.

1.2 Installing Ruby: The Backbone of Jekyll

Jekyll is built on Ruby, so you’ll need to install it before proceeding. We recommend using a version manager like rbenv or RVM to handle Ruby installations, as they make it easier to switch between versions if needed.

Windows: Use the RubyInstaller for Windows. During installation, make sure to check the box that adds Ruby to your system PATH. After installation, verify it by running:

  ruby -v

macOS: Ruby is pre-installed on macOS, but it’s often an older version. Use Homebrew to install the latest version:

  brew install ruby

Add Ruby to your PATH by adding the following line to your .zshrc or .bashrc file:

  export PATH="/usr/local/opt/ruby/bin:$PATH"

Verify the installation:

  ruby -v

Linux: Install Ruby using your package manager or a version manager like rbenv. For example:

  sudo apt update && sudo apt install ruby-full  # For Ubuntu/Debian

Or use rbenv:

  sudo apt install rbenv
  rbenv install 3.2.2  # Replace with the latest stable version
  rbenv global 3.2.2

Check the installation:

  ruby -v

1.3 Setting Up a Virtual Environment (Optional but Recommended)

If you want to keep your Ruby environment isolated from your system, consider using a virtual environment. Tools like rbenv or RVM are great for this. Alternatively, you can use Docker to containerize your environment, which ensures consistency across different machines.

For simplicity, we’ll stick with rbenv for this guide. If you’ve already installed it, create a new directory for your project and set the Ruby version, if you haven't already installed rbenv run the following commands :

- Git Clone (Linux/macOS):

git clone https://github.com/rbenv/rbenv.git ~/.rbenv

# Add rbenv to your shell's startup file (e.g., ~/.bashrc, ~/.zshrc)
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init - bash)"' >> ~/.bashrc  # Use `- zsh` for Zsh

exec $SHELL
# OR
source ~/.bashrc

- Homebrew (macOS):

brew install rbenv
# Follow post-install instructions to set up your shell.

Once rbenv is successfully installed, it's time to verify that everything is working as expected. Run the following commands in your terminal to ensure there are no errors and to confirm that the setup is functioning correctly.

mkdir my-jekyll-site
cd my-jekyll-site
rbenv local 3.2.2  # Replace with your installed version

1.4 Installing Jekyll

With Ruby installed, you can now install Jekyll and Bundler (a dependency manager for Ruby). Run the following command:

gem install jekyll bundler

Verify the installation:

jekyll -v

If you see the Jekyll version number, you’re good to go!

1.5 Cloning the Affiliates Jekyll Theme

Now that your environment is set up, let’s grab the Jekyll theme we’ll be working with. Clone the Affiliates Jekyll Theme from GitHub:

git clone https://github.com/wowthemesnet/affiliates-jekyll-theme.git
cd affiliates-jekyll-theme

This theme is packed with <img> tags, making it perfect for testing our image optimization setup.

1.6 Building the Jekyll Site

To ensure everything is working correctly, build the Jekyll site locally:

bundle install  # Installs dependencies
bundle exec jekyll build

After the build process completes, check the _site directory. It should contain the static HTML, CSS, and image files generated by Jekyll.

Serve the site locally to preview it:

bundle exec jekyll serve

If you encountered no errors, fire up your browser and navigate to http://127.0.0.1:4000/affiliates-jekyll-theme/ to see the site in action. And you don't have to worry much about the local clone version of your Jekyll theme just yet, since we're only deploying them to make sure that your system is good to go for the rest of the tutorial.

Aight, by now you’ve got Git, Ruby, and Jekyll installed, and you’ve cloned the Affiliates Jekyll Theme. You’ve also verified that your setup is working by building and serving the site locally. With these tools in place, you’re ready to move on to deploying your site to Cloudflare Pages and setting up the magic of Cloudflare Workers for image optimization.

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #1)

gerry leo nugroho — Sun, 06 Jul 2025 02:20:02 +0000

Welcome to the first step of our journey to create a cutting-edge blog using the latest technologies: Next.js 15.1.7 and Tailwind CSS 4.0.7 (as of this writing). I’m excited to walk you through this process with the depth and clarity you’d expect from a technical deep dive. Our goal here is to establish a robust development environment, ensuring we have full control over our tech stack and laying a solid groundwork for a feature-rich blog.

Let’s dive into the nitty-gritty of initializing our project, step by step. Each step is thoroughly explained, highlighting the reasoning, actions, and verification processes to showcase the setup of a modern blog using Next.js 15.1.7 and Tailwind CSS 4.0.7.

Step 1: Installing Node.js 20.x.x – The Engine of Our Project

Before we can wield the power of Next.js and Tailwind CSS, we need a reliable runtime environment. Node.js is our engine, and version 20.x.x is the latest Long-Term Support (LTS) release as of early 2025, offering stability and modern JavaScript features. To get started, head over to the official Node.js website at nodejs.org. Once there, locate the LTS section and download the installer tailored to your operating system—whether it’s Windows, macOS, or Linux.

Run the installer by double-clicking the downloaded file. For Windows users, a setup wizard greets you with a friendly "Welcome to Node.js" message. Click "Next", accept the license agreement (a quick skim confirms it’s standard fare), and choose the default installation path—typically C:\Program Files\nodejs\. Here’s a pro tip: ensure the box labeled "Add to PATH" is checked. This step makes Node.js and its package manager, npm, globally accessible from your terminal, saving you headaches later. If prompted, opt to install additional tools like Chocolatey on Windows—it streamlines future updates.

Once the installation completes, it’s time to verify our work. Open your terminal (Command Prompt, PowerShell, or your preferred shell) and type node -v. You should see something like v20.x.x—the exact patch version might vary, but the "20" confirms we’re on the right track. Next, check npm with npm -v, expecting a version like 10.x.x. If both commands return these results, congratulations! Node.js 20.x.x is ready to power our blog.

Step 2: Scaffolding the Next.js Project – Crafting Our Blog’s Skeleton

With Node.js humming along, let’s scaffold our blog using Next.js, the React framework that’s revolutionizing web development. In your terminal, execute the following command:

npx create-next-app@latest blog --use-npm

This command leverages npx (a tool bundled with Node.js) to fetch the latest version of create-next-app, ensuring we snag Next.js 15.x.x fresh from the oven. The blog argument names our project directory, and --use-npm specifies npm as our package manager (sorry, Yarn fans!).

As the command runs, you’ll be greeted with a series of prompts to customize your setup. Here’s how we’ll answer them, along with why:

Would you like to use TypeScript? Choose "Yes." TypeScript’s static typing catches errors early, enhances IDE support, and aligns with modern development practices—perfect for a blog we want to scale.
Would you like to use ESLint? Select "Yes." ESLint keeps our code consistent and clean, enforcing rules like proper indentation and no unused variables—a must for maintainable documentation.
Would you like to use Tailwind CSS? Say "No." Here’s the twist: while create-next-app offers Tailwind integration, it installs an older version (likely 3.x.x). We’re after Tailwind CSS 4.x.x, so we’ll handle that manually later for the latest features.
Would you like to use src/ directory? Opt for "Yes." The src/ directory organizes our source code neatly, separating it from configuration files like next.config.mjs—a tidy structure for a polished blog.
Would you like to use App Router? Answer "Yes." The App Router in Next.js 15.x.x unlocks React Server Components, streaming, and advanced routing—ideal for a performant, SEO-friendly blog.
Would you like to customize the default import alias? Choose "Yes" and set it to @/*. This alias simplifies imports (e.g., @/components/Header instead of ../../components/Header), making our code more readable.

After answering these prompts, the scaffolding process whirs to life, creating a blog/ directory with a barebones Next.js app. You’ll see files like next.config.ts, package.json, package-lock.json, next-env.d.ts, tsconfig.json, and an initial src/app/ structure. This skeleton is our canvas—ready for us to paint with features.

Step 3: Manually Installing Next.js 15.x.x – Ensuring the Latest Version

While create-next-app typically grabs the latest Next.js, let’s double-check. In your terminal, run npm info next version to peek at the current stable release—it should read 15.x.x. If, for some reason, the scaffolded version lags (check package.json’s "next" field), update it with npm install next@latest. This command ensures we’re riding the cutting edge of Next.js, with goodies like the React 19 compiler and enhanced Turbopack support.

Step 4: Manually Installing Tailwind CSS 4.0.7 – Precision Styling Control

Since we skipped Tailwind’s default installation coming from the previous scaffolding process, let’s bring in version 4.0.8 manually for its modern CSS-first approach. Run this command:

npm install -D tailwindcss postcss autoprefixer

Here’s the breakdown:

tailwindcss: The core Tailwind CSS library.
postcss: A tool for transforming CSS with JavaScript.
autoprefixer: A PostCSS plugin to add vendor prefixes to CSS.

This trio ensures we harness Tailwind 4.x.x’s full potential—think CSS variables for theming and lightning-fast builds. Post-installation, we’ll configure it through the config file (more on that later), but for now, we’ve got the raw materials all within our disposal.

Step 5: Installing Additional Dependencies – Powering Our Features

Our blog project isn’t just a pretty face—it’s packed with additional functionalities. Let’s install the libraries to make it up and running:

MDX Parsing: npm install @next/mdx gray-matter
- @next/mdx: Integrates MDX (Markdown + JSX) with Next.js 15, letting us write rich blog posts.
- gray-matter: Parses frontmatter (e.g., title, tags) from MDX files, crucial for categorization.
Google Fonts: npm install unplugin-fonts
- A dev dependency for fetching modern fonts like Inter and Merriweather seamlessly.
Typography: npm install -D @tailwindcss/typography
- Enhances blog post readability with beautiful prose styling.
Modern Icons: npm i react-icons
- Adding more beauty to the user interface.
Dark Mode: npm install next-themes
- Enables effortless light/dark mode toggling.
RSS: npm install rss
- Generates an RSS feed for subscribers.
Search: npm install fuse.js
- Powers fuzzy search across posts—fast and flexible.
SEO/Open Graph/JSON-LD: npm install next-seo
- Boosts discoverability with structured data and social previews.

And don't worry if during the installation of the above dependencies and library, you may have encountered some warnings, just ignore them as for now. These tools later on, collectively transform our blog into a powerhouse of modern web development.

Step 6: Verifying the Installation – Double-Checking Our Work

Let us ensure everything’s in place. Open package.json in your blog/ root directory and inspect the "dependencies" and "devDependencies" sections. You should see something like the following code.

{
    "name": "blog",
    "version": "0.1.0",
    "private": true,
    "scripts": {
        "dev": "next dev --turbopack",
        "build": "next build",
        "start": "next start",
        "lint": "next lint"
    },
    "dependencies": {
        "@next/mdx": "^15.1.7",
        "@tailwindcss/postcss": "^4.0.9",
        "fuse.js": "^7.1.0",
        "gray-matter": "^4.0.3",
        "next": "15.1.7",
        "next-seo": "^6.6.0",
        "next-themes": "^0.4.4",
        "react": "^19.0.0",
        "react-dom": "^19.0.0",
        "react-icons": "^5.5.0",
        "rss": "^1.2.2",
        "unplugin-fonts": "^1.3.1"
    },
    "devDependencies": {
        "@eslint/eslintrc": "^3",
        "@tailwindcss/typography": "^0.5.16",
        "@types/node": "^20",
        "@types/react": "^19",
        "@types/react-dom": "^19",
        "autoprefixer": "^10.4.20",
        "eslint": "^9",
        "eslint-config-next": "15.1.7",
        "postcss": "^8.5.3",
        "prettier": "^3.5.2",
        "prettier-plugin-tailwindcss": "^0.6.11",
        "tailwindcss": "^4.0.9",
        "typescript": "^5"
    }
}

Versions might have minor increments (e.g., 15.0.1), but the major versions confirm we are current. To test, run npm run dev and visit http://localhost:3000 in your browser. A basic Next.js welcome page should greet you—proof our foundation is solid.

Step 7: Git/GitHub Integration – Version Control from the Start

Collaboration and version tracking are non-negotiable, so let’s integrate Git and GitHub. Navigate to your project with cd blog and initialize a Git repository: git init. Next, create a .gitignore file to exclude clutter:

node_modules/
.next/
dist/
*.log

Stage everything with git add . and commit: git commit -m "Initial project setup". Now, head to GitHub, create a new repository named blog, and link it locally: git remote add origin <repo-url> (replace with your repo’s URL, like https://github.com/username/blog.git). Push it up with git push -u origin main. Your code is now safely versioned and shareable!

Wrapping Up Project Initialization

And there you have it! We’ve installed Node.js 20.x.x, scaffolded a Next.js 15.x.x project with deliberate options, manually added Tailwind CSS 4.x.x, and loaded up essential libraries—all while setting up Git for collaboration. This setup isn’t just a starting point; it’s a launchpad for a blog packed with modern features like dark mode, search, and SEO optimization. In the next section, we’ll configure Next.js and Tailwind CSS to bring our vision to life. I'll see you on the next page!

Interstellar Insights: Visualizing Length Contraction and Time Dilation

gerry leo nugroho — Fri, 23 May 2025 06:17:27 +0000

1. The Cosmic Speed Limit 🚀

Imagine embarking on a voyage to a galaxy 4 million light-years away and arriving in what feels like an instant. While this scenario seems like pure science fiction, it's grounded in the principles of Einstein's special relativity.

In Interstellar, the crew's expedition near the supermassive black hole Gargantua leads to dramatic time dilation effects. On Miller's planet, just a few hours equate to several years on Earth due to the intense gravitational field, a phenomenon accurately depicted in the film and rooted in general relativity.

But there's another intriguing aspect of relativity that's less visually portrayed: length contraction. As objects approach the speed of light, distances in their direction of motion appear shorter. This means that for a spacecraft traveling at near light speed, the vast expanse between galaxies could contract, making interstellar travel more feasible within a human lifetime.

In this blog post, we'll delve into the concept of length contraction, using intuitive analogies and interactive Python code to bring the theory to life. Whether you're a physics enthusiast or a curious mind inspired by Interstellar, this exploration will illuminate how motion at high speeds can alter our perception of space and time.

2. Understanding Length Contraction 🧠

Length contraction is a phenomenon predicted by Einstein's theory of special relativity, where the length of an object moving at a significant fraction of the speed of light appears shorter along the direction of motion to a stationary observer. This effect becomes noticeable only at speeds approaching the speed of light.

2.1 The Lorentz Factor and the Contraction Formula

The degree of length contraction is quantified by the Lorentz factor (γ), defined as: (BYJU'S)

$\frac{1}{\sqrt{1 - \frac{v^2}{c^2}}}$

Where:

$γ$ is the relative velocity between the observer and the moving object.
$c$ is the speed of light in a vacuum (Wikipedia).

The contracted length $L$ observed is given by (Wikipedia)

$\frac{L_0}{\gamma}$

Or, equivalently:

$L_0 \sqrt{1 - \frac{v^2}{c^2}}$

Where $L_0$ is the proper length (the length of the object in its rest frame)

$L$ : Contracted length.
$L_0$ : Proper length (rest frame).
$v$ : Relative velocity.
$c$ : Speed of light.

2.2 A Real-World Analogy: The Cosmic Treadmill

Imagine you're on a treadmill that's moving at an incredibly high speed. To an outside observer, your body appears compressed along the direction of motion due to the high speed—this is analogous to length contraction.

2.3 Practical Implications

Length contraction isn't just a theoretical concept; it has practical implications in fields like particle physics. For instance, muons—subatomic particles produced in the Earth's upper atmosphere—travel toward the Earth's surface at speeds close to the speed of light.

Due to length contraction, the distance they need to travel appears shorter in their frame of reference, allowing more of them to reach detectors on the Earth's surface than would be expected without considering relativistic effects.

2.4 Further Reading

For a more in-depth exploration of length contraction, consider the following resources:

3. Analogy: The Cosmic Treadmill 🏃‍♂️

Understanding the concept of length contraction in special relativity can be challenging. To make it more intuitive, let's consider an analogy: the cosmic treadmill.

3.1 The Cosmic Treadmill Analogy

Imagine you're standing on a treadmill that's infinitely long and capable of moving at incredibly high speeds. As the treadmill speeds up, you notice something peculiar: the landscape ahead appears to compress, and the distance to your destination seems shorter. This isn't because the treadmill is physically altering the landscape, but rather, your high-speed motion changes your perception of space.

In the realm of special relativity, this analogy mirrors the phenomenon of length contraction. As an object moves closer to the speed of light, the distances in the direction of motion appear contracted to the moving observer. This isn't an optical illusion but a fundamental aspect of how space and time behave at relativistic speeds.

3.2 Real-World Implications

This concept isn't just theoretical. In particle physics, for instance, muons—subatomic particles produced in the Earth's upper atmosphere travel toward the Earth's surface at speeds close to the speed of light. Due to length contraction, the distance they need to travel appears shorter in their frame of reference, allowing more of them to reach detectors on the Earth's surface than would be expected without considering relativistic effects.

3.3 Further Reading

For a more in-depth exploration of length contraction and its implications, consider the following resources:

4. Interactive Python Tool: Calculating Length Contraction 🧪

Understanding the concept of length contraction becomes more intuitive when you can experiment with different scenarios. Below is a Python script that allows you to input various distances and velocities to observe how length contraction manifests at relativistic speeds.

4.1 How It Works 🔧

This script:

Prompts you to enter:
- Proper Length $(L ₀)$ : The original length of the object at rest, in light-years.
- Velocity $(v)$ : The speed of the object as a percentage of the speed of light (e.g., 99.9 for 99.9% of $c$ ).
Calculates the contracted length $(L)$ using the formula: $L_0 \sqrt{1 - \frac{v^2}{c^2}}$
Plots a graph showing how the contracted length varies with speed.

4.2 Python Code 🖥️

from IPython import get_ipython
from IPython.display import display
# %%
import math
import matplotlib.pyplot as plt
import numpy as np
from ipywidgets import interact, FloatSlider

def length_contraction(L0, speed_percent):
    v = speed_percent / 100  # Convert percentage to a fraction
    if v >= 1:
        print("Speed must be less than the speed of light.")
        return
    gamma = 1 / math.sqrt(1 - v**2)
    L = L0 / gamma

    # Calculate percentage of original distance
    percentage_of_original = (L / L0) * 100

    # Revised explanation print statement
    print(f"At {speed_percent:.1f}% the speed of light, the original {L0:,.0f} light-years distance, would shorten to only {L:,.4f} light-years, or only {percentage_of_original:.2f}% of the original distance.")

    # Plotting
    speeds = np.linspace(0, 0.99, 1000)
    gammas = 1 / np.sqrt(1 - speeds**2)
    lengths = L0 / gammas

    plt.figure(figsize=(10, 6))
    plt.plot(speeds * 100, lengths, label='Contracted Length')
    plt.axvline(speed_percent, color='red', linestyle='--', label=f'Input Speed: {speed_percent}%')
    plt.axhline(L, color='green', linestyle='--', label=f'Contracted Length: {L:.4f} ly')
    plt.title('Length Contraction vs. Speed')
    plt.xlabel('Speed (% of the speed of light)')
    plt.ylabel('Contracted Length (light-years)')
    plt.legend()
    plt.grid(True)
    plt.show()

# Interactive widgets
interact(length_contraction,
         L0=FloatSlider(value=4_000_000, min=1_000_000, max=10_000_000, step=100_000, description='Proper Length (ly)'),
         speed_percent=FloatSlider(value=99.9, min=0.1, max=99.99, step=0.1, description='Speed (% of c)'))

Here’s a copy of the code hosted at Google Collab.

4.3 Visualizing the Results 📈

When you run this script:

Proper Length (ly = light years): Use the slider to set the proper length (the length of the object in its rest frame) in light-years.
Speed (% of $c$ ): Adjust the slider to set the speed as a percentage of the speed of light.
Calculation: The script computes the contracted length using the Lorentz contraction formula.
Graphical Output: A plot is generated showing how the contracted length changes with speed, highlighting your specific input.

This interactive approach allows you to see firsthand how increasing speeds lead to more significant length contraction, providing a tangible understanding of this relativistic effect.

4.4 Further Exploration 🧠

For those interested in more advanced simulations and visualizations of relativistic effects, consider exploring the following resources:

Visualizing Relativistic Length Contraction in 2D: An educational tool that helps students grasp the concept of length contraction through 2D visualizations. Physics with Keith
Special Relativity with Jupyter Lab and Sympy: A guide on using Python's Sympy library to perform symbolic computations related to special relativity. Medium Article

5. Relativity in Action: Lessons from Interstellar 🎬

Christopher Nolan's Interstellar masterfully brings complex scientific concepts to the big screen, making phenomena like time dilation and length contraction accessible to a broader audience. While the film primarily focuses on time dilation, it provides a compelling context to discuss length contraction as well.

5.1 Time Dilation on Miller's Planet 🕒

In the film, the crew visits Miller's planet, which orbits close to the supermassive black hole Gargantua. Due to the intense gravitational field, time on Miller's planet passes much slower compared to Earth—a concept known as gravitational time dilation. As a result, one hour on Miller's planet equates to seven years on Earth. This dramatic portrayal underscores the real-world implications of Einstein's theory of general relativity.

5.2 Length Contraction: The Unseen Companion 📏

While Interstellar doesn't explicitly depict length contraction, it's an inherent aspect of special relativity that complements time dilation. As an object approaches the speed of light, not only does time slow down for it relative to a stationary observer, but lengths in the direction of motion also contract. This means that for the traveling object, distances appear shorter, effectively making interstellar travel more feasible from its perspective.

5.3 Visualizing Relativity 🎥

For a deeper understanding of these concepts as portrayed in Interstellar, consider watching the following video:

This video provides an in-depth analysis of the scientific principles depicted in the film, offering a clearer picture of how relativity plays a crucial role in the storyline.

6. Conclusion: Relativity—From Theory to Tangible Reality 🚀

Throughout this journey, we've delved into the fascinating world of Einstein's theory of relativity, exploring how time and space behave under extreme conditions. From the abstract equations of special relativity to the cinematic portrayal in Interstellar, we've seen that these concepts are not just theoretical musings but have real-world implications.

6.1 Recap of Key Concepts 🔄

Time Dilation: Time slows down for objects moving at speeds close to the speed of light or in strong gravitational fields. This effect is vividly depicted in Interstellar when the crew experiences only a few hours on Miller's planet, while years pass on Earth.
Length Contraction: Objects in motion contract along the direction of motion as they approach the speed of light. While not explicitly shown in Interstellar, this phenomenon complements time dilation and is crucial in high-speed space travel scenarios.

6.2 Final Thoughts 🧠

Interstellar serves as a bridge between complex scientific theories and mainstream audiences. The film's depiction of time dilation, influenced by the gravitational pull of a massive black hole, brings to life the profound effects of relativity.

Einstein's theories have reshaped our understanding of the universe, revealing that time and space are interwoven and relative. These concepts, once confined to academic texts, now influence technologies like GPS and inspire cinematic masterpieces.

As we continue to explore the cosmos, the principles of relativity will remain central to our quest, reminding us that the universe is more interconnected and dynamic than we ever imagined.

Semantic HTML in 2025: The Bedrock of Accessible, SEO-Ready, and Future-Proof Web Experiences

gerry leo nugroho — Tue, 13 May 2025 09:21:55 +0000

1. The Semantical Story-telling HTML Realm

We’re living in the age of AI-enhanced search, screen readers powered by machine learning, and ever-expanding frontend frameworks, it might surprise you that one of the most vital elements of modern web development in 2025 is, good old semantic HTML.

Originally standardized in HTML5, semantic HTML refers to the use of meaningful, descriptive tags like <article>, <section>, <header>, and <footer> to structure web content. These elements go beyond presentation—they provide context. This helps not only users and developers, but also assistive technologies, search engines, and even AI agents to interpret and interact with web content more accurately.

1.1 Why Is Semantic HTML More Relevant Than Ever in 2025?

Today’s web is increasingly consumed through non-traditional interfaces: voice search, screen readers, smart devices, and AI assistants like Google’s Search Generative Experience (SGE). These technologies rely on the semantic clarity of markup to understand content hierarchy and intent. In fact, Google has long emphasized that “semantic HTML improves accessibility, search engine optimization (SEO), and maintainability” (source).

According to the W3C, semantic markup plays a foundational role in creating inclusive digital experiences (WAI - Web Accessibility Initiative), and these practices are now considered best-in-class rather than optional. And as more frameworks, and SSG like React and Astro embrace server-rendered, content-focused paradigms, semantic HTML becomes a natural partner in delivering performance-optimized, discoverable pages that meet modern Core Web Vitals standards (Google Lighthouse Guide).

1.2 The Forward View

While it might seem like semantic HTML is a solved problem, the truth is more nuanced. Developers often overlook or misuse semantic tags, particularly in component-driven architectures. The result? Pages that visually appear correct but fail in accessibility audits, miss out on SEO enhancements, and break when interpreted by assistive tech or AI bots.

In this blog post, we’ll explore:

What’s changed (and what hasn’t) in the semantic HTML landscape since the early 2020s
How semantic syntax plays an outsized role in accessibility, SEO, and maintainability
Practical, modern implementations across frameworks and tooling
What’s next in the evolution of semantic HTML

By grounding our front-end practices in semantics, we don’t just write HTML—we write meaningful web experiences.

2. What’s Changed Since the 2020s?

The 2020s saw a massive transformation in how web content is delivered and consumed. While the HTML5 semantic elements themselves have remained relatively stable, the context in which they’re used—and their importance—has dramatically shifted.

2.1 Frameworks Finally Embrace Semantics

In the early 2020s, component-based frameworks like React, Vue, and Svelte prioritized flexibility and abstraction—often at the cost of semantic clarity. Developers would default to <div>s and <span>s, nesting components without considering their structural meaning.

Fast forward to 2025, modern frameworks have baked semantic best practices directly into their conventions:

Next.js 14+ encourages semantic defaults in server components and layout routing (Next.js Layouts).
Astro promotes content-first development using .mdx and HTML-first patterns, encouraging native semantic elements by design (Astro Content Collections).
SvelteKit emphasizes accessibility and minimal abstractions, aligning well with semantic principles (SvelteKit Accessibility Docs).

This shift is driven by a recognition that semantics are not just for screen readers—they enhance every layer of a digital experience, from SEO to developer collaboration.

2.2 The Rise of AI-Powered Search and Content Understanding

In 2025, search engines are no longer just indexing keywords—they are contextual interpreters. Google's Search Generative Experience (SGE) and Microsoft's AI-powered Bing rely heavily on semantic cues to summarize, extract, and rank content appropriately.

“Proper use of semantic markup improves how your page appears in search results and can power rich snippets, FAQs, and voice search summaries.”

— Google Search Central

Semantic tags like <article>, <time>, <h1>-<h6>, and <section> help AI engines detect:

Main content areas
Author and publication metadata
Content hierarchy
Contextual relevance in long-form content

In short, your markup now directly influences whether your content becomes AI-readable and AI-promoted.

2.3. Accessibility Standards Have Matured

Accessibility in 2025 is more regulated and standardized. Governments and organizations increasingly require WCAG 2.2+ compliance, and semantic HTML is often the easiest, most future-proof path toward conformance.

Many ARIA roles are now redundant when native semantic elements are used properly, per WAI-ARIA Authoring Practices.
Browser and assistive tech support has improved, with screen readers like NVDA, VoiceOver, and JAWS natively interpreting semantic HTML with higher fidelity (W3C Assistive Technologies Guide).

2.4. Tooling Encourages Semantic Precision

Developer tools have evolved to actively encourage semantic practices:

Lighthouse SEO audits flag missing landmark elements or improper heading structure (Chrome DevTools Lighthouse).
ESLint plugins such as eslint-plugin-jsx-a11y help React developers enforce accessibility through semantic markup (GitHub).
HTML linting tools and IDE extensions now catch improper element nesting or misuse of non-semantic tags.

What was once a manual review process is now increasingly automated and enforced during development.

2.5. Performance and Semantics: A New Alliance

Performance optimization isn’t just about CSS and JavaScript anymore. Semantic HTML is playing a role in:

Content paint prioritization through predictable element structure.
Lazy-loading media via <picture> and <figure> combined with modern loading="lazy" attributes.
Reduced DOM complexity, leading to better time-to-interactive (TTI) and improved Core Web Vitals.

Semantic elements signal content intent early, helping browsers and bots parse documents efficiently and accurately. While the tags themselves haven’t changed, how we use them—and why we must use them properly—has transformed drastically. In 2025, semantic HTML isn’t just a best practice—it’s a baseline expectation across performance, SEO, accessibility, and AI readiness.

3. Core Semantic Elements in 2025: What You Should Still Be Using

Despite the rapid evolution of the web, semantic HTML remains the backbone of meaningful, accessible, and machine-readable content. These elements are not new—but in 2025, their importance has deepened across frameworks, SEO strategies, and inclusive design practices.

Here’s a breakdown of essential semantic elements, their modern relevance, and example use cases.

3.1. Layout & Landmark Elements

These define document structure, improve screen reader navigation, and help search engines parse intent.

Tag	Purpose	Example Use
`<header>`	Introductory content or branding	Logo, site nav, page title
`<nav>`	Navigational block	Main menu, sidebar links
`<main>`	Primary page content	Everything except header/footer/nav
`<section>`	Thematic grouping of content	A product category, FAQ, or dashboard module
`<article>`	Independent self-contained content	Blog post, news article, forum post
`<aside>`	Indirectly related content	Callout, ad, related links
`<footer>`	Closing or attribution content	Author bio, copyright, related docs

🟢 Modern Best Practice: Use these as layout scaffolding before styling or componentizing. Each has implicit ARIA roles that reduce the need for role="..." attributes (MDN: Landmark Roles).

3.2. Content Semantics

These tags add context to specific parts of the content—ideal for SEO-rich, AI-indexable, and well-structured documents.

Tag	Purpose	Example Use
`<h1>`–`<h6>`	Content hierarchy	Page title to sub-sub headings
`<p>`	Paragraph of text	Body content
`<ul>`, `<ol>`, `<li>`	Lists	Navigation, to-do list, table of contents
`<figure>`	Self-contained visual + caption	Image with explanation
`<figcaption>`	Caption for `<figure>`	Describes a graph, photo, code example
`<blockquote>`	Long quoted text	Testimonial, citation
`<cite>`	Reference to creative work	Book title, author name
`<time>`	Machine-readable timestamp	Event date, publication time
`<mark>`	Highlighted or emphasized segment	Keyword matches in search results

🟢 Modern Best Practice: Use <time datetime="YYYY-MM-DD"> format to ensure both readability and machine parsing. This is especially helpful for publishing content to feed-based systems and SGE-like services.

3.3. Interactive & State-Aware Elements

These bridge the gap between HTML and JavaScript-driven UIs while keeping semantics intact.

Tag	Purpose	Example Use
`<details>`	Disclosure widget	FAQ toggles, collapsible terms
`<summary>`	Label for `<details>`	Clickable header
`<dialog>`	Native modal dialog	Confirm boxes, help popups
`<form>`	Structured user input	Contact, login, search
`<label>`	Form input descriptor	Always pair with input for a11y
`<fieldset>`, `<legend>`	Group related form elements	Credit card fields, multi-part forms

3.4 Did You Know? 🔍

The native <dialog> element gained widespread browser support by late 2023 (Can I use – <dialog>) and is now recommended over custom modal scripts for accessibility and performance.

3.5 When in Doubt, Choose Meaning Over Styling

One of the core principles in 2025: Never use a <div> when a semantic tag better expresses the intent. For instance:

Use <section> instead of <div class="features-section">
Use <button> instead of <div onClick="...">

3.6 ✅ Semantic Tags:

Are more accessible out of the box
Provide SEO benefits (via contextual understanding)
Integrate better with AI/ML content parsing

3.7 Tailwind CSS & Semantic HTML

With Tailwind CSS v4.1+, semantic markup is more maintainable than ever:

<article class="prose dark:prose-invert max-w-2xl mx-auto">
  <header class="mb-6">
    <h1 class="text-4xl font-bold">The State of Semantic HTML in 2025</h1>
    <time datetime="2025-05-10" class="text-sm text-gray-500">May 10, 2025</time>
  </header>
  <section class="space-y-4">
    <p>Semantic HTML isn't just nice to have—it's necessary...</p>
  </section>
</article>

Semantics and utility-first design aren’t mutually exclusive—they’re complementary when structured properly. The semantic elements of HTML aren't just surviving—they're thriving in 2025. As interfaces become more diverse and digital environments more intelligent, the meaning behind your markup is the foundation for accessibility, SEO, and AI readiness.

4. Accessibility by Design: Semantic HTML as a First-Class Citizen

In 2025, accessibility is no longer an afterthought or a compliance checkbox—it’s a core pillar of user experience design. And at the heart of accessible web development is semantic HTML. Semantic tags allow browsers, screen readers, and assistive technologies to understand content without additional hints. Where ARIA attributes were once necessary to bridge semantic gaps, today's best practices encourage using native HTML semantics first—resorting to ARIA only when there's no native alternative.

4.1.1 Why Semantic HTML Enhances Accessibility by Default ✅

Built-in keyboard and screen reader support
Predictable behavior across devices and tools
Better focus management and tab order
Improved context for users navigating non-visually

4.1.2 The 2025 Trends in Accessibility & Semantics 📊

ARIA usage is declining where semantic elements are used correctly.
Major audits (e.g., Lighthouse, axe-core) flag div soup and improper heading structures as critical issues.
Assistive tools like VoiceOver, NVDA, and JAWS interpret semantic landmarks with improved fidelity.

4.2 Practical Example: Accessible Blog Post Layout Using Semantic HTML 🔧

Here’s a breakdown of how to structure a typical blog article for maximum accessibility using native semantic elements:

<article class="prose dark:prose-invert max-w-3xl mx-auto">
  <header class="mb-4">
    <h1 class="text-4xl font-bold">Understanding Semantic HTML in 2025</h1>
    <!-- Semantic date representation for screen readers and bots -->
    <time datetime="2025-05-10" class="block text-sm text-gray-500">
      Published on May 10, 2025
    </time>
  </header>

  <!-- Main content section grouped for logical flow -->
  <section>
    <h2 class="text-2xl font-semibold">Why Semantics Matter</h2>
    <p>
      Using semantic HTML makes your content more understandable not just to browsers, but also to screen readers and search engines.
    </p>
  </section>

  <!-- Related aside content: not core, but contextually linked -->
  <aside class="mt-8 p-4 border-l-4 border-blue-500 bg-blue-50 dark:bg-blue-900/20">
    <h3 class="text-xl font-medium">Did You Know?</h3>
    <p>
      The <code>&lt;article&gt;</code> tag automatically defines a new region for assistive tech, like screen readers.
    </p>
  </aside>

  <!-- Author bio in footer: not part of article content hierarchy -->
  <footer class="mt-12 border-t pt-4 text-sm text-gray-500">
    <p>Written by <strong>Gerry Leo Nugroho</strong>, Digital Strategist & Data Scientist.</p>
  </footer>
</article>

4.2.1 Accessibility Highlights 🗝️

<article>: Defines a self-contained content block. Screen readers announce this as a landmark.
<header> and <footer>: Set the logical bounds of the article context.
<time> with datetime: Helps assistive tools understand and read the publication date correctly.
<section> with headings: Enables keyboard and screen reader users to navigate through the content via heading levels.
<aside>: Declares non-primary but related content. Screen readers may describe it as “complementary.”

4.3 Anti-Pattern: The “Div Soup” Trap 🔍

Here’s an example of what not to do:

<div class="blog-post">
  <div class="title">Understanding Semantic HTML</div>
  <div class="date">May 10, 2025</div>
  <div class="content">...</div>
</div>

🔴 Problem: No landmarks, no headings, no semantic context.

📉 Results: Poor screen reader navigation, missed SEO opportunities, accessibility audit failures.

4.4 Pro Tips for 2025 and Beyond ✅

Use heading levels correctly: Only one <h1> per page view; nest <h2>–<h6> logically to represent the document structure.
Avoid unnecessary ARIA: If a semantic element exists, use it instead of assigning roles (e.g., <nav> > <div role="navigation">).
Leverage audit tools:

When used correctly, semantic HTML is the most powerful accessibility tool in your toolkit—without writing a single ARIA attribute. It creates a structured, meaningful experience for all users, regardless of ability or device. In 2025, semantic HTML isn't just a best practice—it's an ethical responsibility and a competitive advantage.

5. SEO and Structured Data: How Semantics Power Rich Results

In 2025, search engines no longer just crawl content—they understand it. Semantic HTML, paired with structured data, provides the foundation for this understanding, powering everything from featured snippets to AI-generated content summaries and voice assistant answers.

“Search engines use semantic structure and metadata to identify important content and generate rich results in search.”

— Google Search Central

5.1 The Role of Semantic HTML in Modern SEO 🔎

Semantic tags give search engines clear, contextual cues about what your content is and how it should be treated. For instance:

Tag	Search Engine Benefit
`<article>`	Defines independent content for indexing (e.g., news, blog posts)
`<header>`, `<footer>`	Helps bots understand content boundaries
`<h1>`–`<h6>`	Establish content hierarchy and relevance
`<time>`	Enables correct date parsing in snippets
`<figure>`, `<figcaption>`	Associates media with descriptive context
`<nav>`	Identifies important internal links and page structure

When used properly, these elements reduce ambiguity, leading to better crawlability, indexing accuracy, and SERP enhancements.

5.2 Semantic Structure Powers AI Summarization 🧠

With tools like Google’s Search Generative Experience (SGE) and Bing’s AI summaries, pages with strong semantic scaffolding are more likely to be:

Chosen as AI summary sources
Parsed accurately by NLP models
Served in rich result blocks, featured snippets, or People Also Ask sections

AI-first indexing prefers clean, hierarchical markup over nested, non-semantic div trees.

5.3 Enhancing Semantics with Structured Data (JSON-LD) 🧩

Structured data complements semantic HTML by making content relationships machine-readable using schema.org vocabulary. The most SEO-friendly method is JSON-LD, recommended by Google.

Here’s a blog post example combining semantic HTML with structured data:

<article class="prose">
  <header>
    <h1>Semantic HTML in 2025</h1>
    <time datetime="2025-05-13">May 13, 2025</time>
    <p class="author">By Gerry Leo Nugroho</p>
  </header>
  <section>
    <p>Semantic HTML empowers accessible, SEO-ready websites...</p>
  </section>
</article>

<!-- Structured Data block -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Semantic HTML in 2025",
  "author": {
    "@type": "Person",
    "name": "Gerry Leo Nugroho"
  },
  "datePublished": "2025-05-13",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://yourdomain.com/semantic-html-2025"
  },
  "publisher": {
    "@type": "Organization",
    "name": "All Things Digital"
  }
}
</script>

📈 Result: This markup enables search engines to:

Display the author and date
Recognize the type of content (blog post)
Link content to your site and brand

5.4 Common Pitfalls to Avoid (2025 Edition) 🧭

Mistake	Why It Hurts Your SEO
Using `<div>` instead of `<article>` or `<section>`	Missed content recognition
Multiple `<h1>` tags on a single page view	Confuses content hierarchy
Missing `datetime` attribute on `<time>`	Prevents accurate snippet generation
ARIA-only markup without real structure	Insufficient for rich results
Inline microdata (`itemprop`, etc.)	Deprecated in favor of JSON-LD (Google docs)

5.5 Tools to Validate and Optimize 🔧

Use these tools to test your markup and structured data in real time. Semantic HTML is more than just a content strategy—it’s a visibility strategy in the AI-driven search landscape of 2025. When paired with structured data, semantic markup improves:

How your content appears in search
How it's interpreted by AI
How it’s ranked and recommended

6. Semantic HTML in a Component-Based World

In 2025, most front-end projects are built using component-based frameworks. React, Vue, Svelte, Astro, Solid, and others empower developers to encapsulate functionality—but this abstraction often leads to a disconnect from HTML semantics.

“Frameworks give us power. Semantic HTML keeps us grounded.”

— Every Accessibility Engineer in 2025

Let’s explore how to reconcile reusable components with meaningful markup—and avoid the trap of div-driven design.

6.1 Why Semantics Often Get Lost in Components 🔄

Here’s a typical pattern seen in many teams:

// ❌ Anti-pattern: loses semantic meaning
export default function PostCard({ title, date }) {
  return (
    <div className="card">
      <div className="title">{title}</div>
      <div className="meta">{date}</div>
    </div>
  );
}

🛑 Problem: This uses generic <div>s without structure. Assistive tech won’t know this is a preview of an article or how to prioritize its information.

6.2 Semantically Correct Component (React Example) ✅

// ✅ Better: semantic tags + CSS utility classes
export default function PostCard({ title, date }) {
  return (
    <article className="p-4 border rounded-lg shadow-sm">
      <header>
        <h2 className="text-xl font-semibold">{title}</h2>
        <time dateTime={date} className="text-sm text-gray-500">
          {new Date(date).toLocaleDateString()}
        </time>
      </header>
    </article>
  );
}

💡 Commentary:

<article> signals a self-contained piece of content.
<header> scopes metadata and title.
<time> improves accessibility and enables SEO bots to extract the date.

6.3 Prop-Driven Semantics: Avoid Overgeneralization 🔄

Sometimes developers create over-abstracted components like this:

<Component as="div" role="button" onClick={...}>
  Click me!
</Component>

🛑 This is problematic because:

<div> isn’t focusable by default
role="button" doesn’t automatically handle keyboard events
Screen readers require extra ARIA support

✅ Instead, use:

<Component as="button" onClick={...}>
  Click me!
</Component>

And if using utility frameworks like Tailwind CSS, ensure default HTML elements are styled semantically, not replaced for convenience.

6.4 Semantics in Astro, Svelte, Vue, and JSX 🧠

Framework	Semantic Practice
Astro	Use `.mdx` or `.astro` with native tags. Emphasize content-first markup.
Svelte	Encourages minimal abstraction. Use `<svelte:element>` cautiously.
Vue	Template system promotes semantic structure, but avoid `<template>`-only nesting.
React/JSX	Mind the temptation to use fragments and `<div>`s everywhere. Use semantic elements when rendering layout wrappers.

📦 Bonus Tip: In React, wrap semantic tags in layout components:

export const Section = ({ title, children }) => (
  <section aria-labelledby="section-title">
    <h2 id="section-title">{title}</h2>
    {children}
  </section>
);

6.5 Testing Component Semantics 🧩

In 2025, tooling makes it easier to validate semantic integrity inside your component library.

Recommended tools:

axe-core React integration
eslint-plugin-jsx-a11y
Testing Library – Enforce querying by role to surface semantic flaws

// Example: React Testing Library
render(<PostCard title="Hello World" date="2025-05-10" />);
expect(screen.getByRole('heading', { level: 2 })).toBeInTheDocument();
expect(screen.getByText(/2025/)).toBeInTheDocument();

Frameworks shouldn’t cost you semantics. In 2025, the best developers bake accessibility and SEO into their components by default. Semantic HTML:

Clarifies purpose for screen readers and bots
Prevents accessibility regressions at scale
Future-proofs your UI for generative search and AI

Use semantic wrappers, meaningful tags, and lint/test tools to ensure your component-based code stays human and machine-friendly.

7. Future Trends & Evolving Standards in Semantic HTML (2025 and Beyond)

While the core principles of semantic HTML have remained stable for over a decade, 2025 is ushering in a new era of semantic intelligence, inclusive web standards, and performance-aware markup. The future is not about reinventing HTML—but about elevating its role in a world dominated by AI, headless CMSs, and universal accessibility.

7.1 AI-Native Indexing Requires Richer Semantics 📈

Search engines and platforms are increasingly using LLMs to index and surface content contextually. HTML structure informs this process:

Well-structured documents with <section>, <header>, <article>, and <h1>–<h6> are more likely to be parsed accurately by AI summarization tools.
Ambiguous or div-heavy documents risk being ignored or misrepresented by AI-powered search engines like Google's SGE or Bing's AI Answers.

🔮 Trend: Semantics will be foundational for machine-readable meaning, not just human readability.

7.2 Accessibility-First Standards Are Tightening 📈

Governments and organizations worldwide are tightening accessibility laws. The European Accessibility Act (2025) and upcoming WCAG 3.0 emphasize:

Semantic navigation landmarks
Proper heading structures
Native form controls
Reduced reliance on ARIA for basic structure

💡 By 2026, many jurisdictions will require WCAG 2.2+ compliance for public-facing services.

🔮 Trend: Developers who “code semantically by default” will future-proof their work against regulatory change.

7.3 Component Standards Are Going Semantic 🧩

Frameworks are adopting and encouraging semantic-first APIs:

Framework	Semantic Shift in 2025
React	Encourages accessible patterns and semantic wrappers
Vue 3	Guides use of semantic templates over functional abstractions
SvelteKit	Promotes minimal abstraction with real HTML
Astro	Prioritizes content-first, semantic markdown and MDX
Web Components	Shadow DOM increasingly paired with meaningful structure and ARIA only when needed

🔮 Trend: Frameworks will ship semantic defaults and warn against misuse.

7.4 HTML Proposals & Spec Evolution 🌍

While HTML5 remains stable, here are new draft proposals and active discussions shaping future HTML use:

Proposal	Description	Status
`popovers` API	Native way to build dropdowns, tooltips, modals with semantics	Supported in Chromium, spec maturing (MDN)
Declarative Shadow DOM	Better integration for semantic Web Components	Adopted by Chrome, spec in progress
`autocomplete="webauthn"`	Biometric/secure form semantics	Draft under WHATWG review
Native role-based autowiring	Framework-neutral a11y enforcement tools	Exploratory phase

🔮 Trend: HTML will get smarter—fewer hacks, more native power.

7.5 Multimodal UIs and Semantic Context 📱

In a world with voice UIs, screenless devices, and AR/XR apps:

Semantic HTML helps render content without rendering visuals
Landmarks like <main> and <article> give structure to voice output
Structured content enables reusability across platforms (chatbots, mobile readers, screen readers, headless apps)

🔮 Trend: Semantics will power headless, screenless, and assistive UIs more than ever before.

7.6 Key Takeaways for Future-Proof Developers 🚨

Code for meaning – every element should reflect purpose.
Avoid unnecessary div or span nesting – it's obsolete in most design systems.
Master JSON-LD and semantic SEO – essential for discoverability in AI-first ecosystems.
Build with accessibility in mind from day one – retrofitting later is costly.
Adopt semantic linting and automated testing tools – they’re becoming the baseline for QA.

The future of semantic HTML isn’t in changing what it is—it’s in fully realizing its potential.

In 2025 and beyond, semantics will drive:

How machines interpret content
How people of all abilities access content
How search and AI tools rank and reuse content

Your markup is no longer just for browsers—it’s for humans, bots, and beyond.

8. What’s on the Horizon?

As we stand at the crossroads of AI-native search, global accessibility mandates, and immersive digital experiences, semantic HTML is no longer a nice-to-have — it’s the lingua franca of the future web. Semantic syntax in 2025 has proven itself foundational — not just for screen readers or search engines, but for any machine or modality that must interpret, prioritize, or relay human content. What lies ahead will demand even more from the way we structure our HTML.

8.1 AI-Native Content Prioritization 🔭

Search engines powered by large language models (LLMs) — like Google’s SGE (Search Generative Experience) and Bing’s AI Answers — will increasingly rely on structural cues to determine what content matters most.

Future-ready markup will:

Leverage semantically scoped components to highlight the primary message.
Provide clear hierarchical flow (headings, articles, summaries) for summarization algorithms.
Be optimized not just for crawling, but for reasoning.

Forecast: Semantics will become part of SEO/AI optimization playbooks — a new genre of "Content Intelligence Engineering."

8.2 WCAG 3.0 and Regulatory Convergence 🌐

As accessibility standards consolidate globally under more enforceable legislation, semantic markup will:

Become a legal baseline — non-semantic sites will fail compliance checks.
Be mandated across industries — especially in healthcare, finance, and education.
Influence funding and partnership eligibility in public-private projects.

Forecast: Semantic HTML will be a procurement requirement, not just a dev choice.

8.3 Declarative Semantics for Components & Design Systems 🧠

Design systems will start enforcing semantics at the component level, treating it like color or typography.

Examples include:

Design tokens for role, heading level, and landmark type
IDEs that lint components for missing semantic roles (e.g. <Dialog> without role="dialog")
Component libraries that refuse to compile without accessible semantics (like TypeScript for accessibility)

Forecast: Semantic HTML will be “typed” and validated like any other critical UI logic.

8.4 Declarative Accessibility APIs and Spec Evolution 🧪

We can expect:

Broader adoption of the Popover API and Declarative Shadow DOM
Enhanced support for native form patterns with clearer semantics
Introduction of semantic-first layout primitives in future CSS specs

Forecast: Modern browsers will prioritize shipping accessibility-first APIs over visual sugar.

8.5 Semantics in Headless and Post-HTML Architectures 🤖

As we move into:

Headless CMSs
Edge-rendered content
AR/VR interfaces
Multimodal (voice, text, touch) systems

the value of portable, machine-readable, semantically correct HTML will increase.

Forecast: Semantic structures will be transformed into multiple formats: JSON, voice scripts, even 3D layouts.

8.6 The Big Picture: A New Semantic Renaissance ✨

We’re entering a time where:

Meaning matters more than markup for markup’s sake
Inclusive design is non-negotiable
Search is conversational and generative
Components are expected to be self-explanatory — to humans and machines

To thrive, developers and designers must treat semantic HTML as a discipline, not just a tool.

Semantic HTML is not outdated — it’s outpacing expectations.

Whether you're building the next billion-user app or a blog read by a few hundred, your HTML is your message. And in a future shaped by AI, accessibility, and intent-driven UIs, semantics will be your clearest, most trusted signal.

9. Conclusion: Semantics Are the Future’s Native Language

In an era where machines don’t just read the web — they understand and summarize it — semantic HTML is no longer optional. It’s the fundamental syntax of meaning, discoverability, and inclusion.

From search engines to screen readers, from lightweight UI frameworks to generative AI systems, the structure you choose dictates who can access your content and how well it's interpreted.

“Proper use of semantic HTML ensures that your website is accessible to the widest possible audience, including people who rely on assistive technologies.”

— WebAIM: Semantic Structure

“Google uses page structure and content hierarchy to determine the importance of elements. Semantic HTML helps improve this understanding.”

— Google Search Central, SEO Starter Guide

9.1 What This Means for Developers in 2025 🔑

You don’t need a new library, framework, or toolchain to improve your HTML. You simply need to use the right element for the right job, and let native semantics do the heavy lifting.

Embracing semantic HTML:

Future-proofs your web projects against AI-driven changes in search and accessibility standards.
Improves performance, readability, and maintainability.
Respects your users—especially those using assistive technology or alternative modalities.

9.2 Final Recommendations 💡

Audit your components regularly for semantic correctness and accessibility.
Use semantic markup validators and a11y testing tools as part of your CI workflow.
Stay informed on W3C HTML spec updates and accessibility laws such as WCAG.
Apply structured data using JSON-LD for richer visibility in search engines.

9.3 The Web Is a Universal Interface — Build It That Way 🌍

The best web experiences of the future will be those built with purposeful, inclusive, and intelligent structure. Semantic HTML isn't just for the browser—it's for every human and every machine that needs to understand your content in context.

So as the web evolves, let’s make sure our markup evolves too—not by becoming more complex, but by becoming more meaningful.

Because when every tag tells the truth, everyone wins.

10. Bonus: Semantic HTML Cheatsheet — 2025 Edition

Looking to quickly validate your HTML structure? Want your component markup to be SEO-friendly, screen reader accessible, and AI-readable? This compact cheatsheet provides a 2025-ready reference for semantic-first development.

10.1 Core Semantic Tags 🧱

Tag	When to Use
`<main>`	Primary content unique to the page
`<section>`	Thematic grouping with heading (e.g., features, FAQs)
`<article>`	Independent content unit (blog post, news, review)
`<header>`	Introductory content (inside page or section)
`<footer>`	Closing content (e.g., links, metadata)
`<nav>`	Navigation links (main menu, breadcrumbs)
`<aside>`	Supplementary content (tips, ads, sidebars)
`<figure>`	Self-contained media unit (image, chart, etc.)
`<figcaption>`	Describes a `<figure>`
`<time>`	Machine-readable date/time (`datetime="YYYY-MM-DD"`)

📘 Reference: MDN HTML element reference

🧠 Semantic vs Non-Semantic Tags

Semantic	❌ Non-Semantic Equivalent
`<article>`	`<div class="post">`
`<header>`	`<div class="header">`
`<nav>`	`<ul class="nav">`
`<time>`	`<span>` with text only
`<figure>`	`<div>` with image
`<button>`	`<div role="button">`

Rule of thumb: If an HTML5 semantic tag exists for your use case, use it.

10.2 SEO & Structured Data Integration 🔎

Embed JSON-LD to complement your semantic structure for search engine visibility:

<article>
  <h1>Semantic HTML in 2025</h1>
  <time datetime="2025-05-13">May 13, 2025</time>
</article>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Semantic HTML in 2025",
  "author": {
    "@type": "Person",
    "name": "Gerry Leo Nugroho"
  },
  "datePublished": "2025-05-13"
}
</script>

📌 Validate your markup using:

10.3 Accessibility-First Patterns ♿

HTML Pattern	Why It Matters
Use `<button>` instead of `<div>`	Keyboard and ARIA support built-in
Use `<label for="...">` for inputs	Links label text to form controls
Use heading levels `<h1>`–`<h6>`	Defines screen reader content structure
Use `<fieldset>` + `<legend>`	Group form elements accessibly
Use `aria-labelledby`, `aria-describedby` only when needed	Supplements—not replaces—semantic tags

📘 Accessibility Docs: WebAIM Techniques, WCAG 2.2 Overview

10.4 Lint & Test Tools (2025-Ready) ⚙️

Tool	Purpose
`eslint-plugin-jsx-a11y`	React/JSX semantic linting
axe DevTools	Accessibility testing in browser
Testing Library	Test semantics via roles
Lighthouse	Audits SEO & a11y

10.5 Component Framework Tips ✅

Use real semantic tags in React, Vue, Svelte, Astro components.
Prefer aria-* as enhancements, not replacements.
Wrap reusable content in components like <Article>, <Section>, <Nav>, etc.
Lint your JSX templates and MDX with custom rules.

📘 Example: React Accessibility Docs

10.6 Key Do's and Don'ts 📌

✅ Do This	❌ Avoid This
Use `<h1>` only once per page	Multiple `<h1>` tags in unrelated sections
Use `<time datetime="...">`	Just text like “May 13, 2025”
Structure with `<article>` + `<header>` + `<footer>`	`div` soup
Use native form controls (`<button>`, `<select>`)	Faux buttons made with `<div>`
Use JSON-LD in `<script>` for structured data	Inline microdata (`itemprop`, etc.)

From Tailwind CLI to Vite: A Developer’s Journey to Better Performance (2025 Edition)

gerry leo nugroho — Tue, 13 May 2025 09:15:11 +0000

I’m always on the lookout for tools that can make my workflow faster, more efficient, and enjoyable. Recently, I decided to integrate Vite into my existing TailwindCSS CLI project, all-things-digital. My goal was to modernize my build process while keeping the simplicity of my current setup intact. In this blog post, I’ll walk you through the entire process—from creating a backup branch, integrating Vite into my current codebase and modularizing my code to take advantage of what Vite has to offer. By the end of this journey, you’ll have a clear understanding of how to upgrade your own project with Vite while maintaining modularity and performance.

1. Create a New Branch for Backup

Before diving into any major changes, it’s essential to create a backup branch. This ensures that your current setup remains untouched in case something goes wrong during the upgrade process. Here’s how I did it:

Step 1.1: Open Your Terminal

I opened my terminal and navigated to the root directory of my project. If you’re using a Mac or Linux, you’ll use Bash, while Windows users can use the command prompt .

Step 1.2: Create the Backup Branch

To create a new branch named latest-vite-integration, I ran the following command:

git checkout -b latest-vite-integration

This command creates a new branch and switches to it in one step . It’s a quick and efficient way to ensure I have a safe starting point.

Step 1.3: Push the Branch to GitHub

After creating the branch locally, I pushed it to GitHub to back it up remotely:

git push origin latest-vite-integration

This step ensures that the branch is stored securely in the cloud, making it accessible from anywhere .

Why This Step Matters

Creating a backup branch is a best practice I’ve learned over time. It gives me peace of mind knowing that I can always revert to my original setup if needed. Plus, it allows me to experiment freely without worrying about breaking anything .

2. Vite Best Practices in 2025

Before integrating Vite into my project, I wanted to ensure I understood its best practices and how it could improve my workflow. This step was crucial for making informed decisions and avoiding common pitfalls. Here’s what I learned:

What is Vite?

Vite is a modern build tool that leverages native ES modules (ESM) to provide a lightning-fast development experience . Unlike traditional bundlers like Webpack, Vite serves files on demand during development, eliminating the need for a full rebuild every time you make a change. This makes it particularly well-suited for static HTML/CSS/JS projects like mine.

Key Features of Vite

Hot Module Replacement (HMR):

One of Vite’s standout features is its HMR capability. When you edit a file, only the changed module is updated in the browser, without reloading the entire page. This makes development faster and more enjoyable .
Optimized Production Builds:

While Vite uses native ESM during development, it bundles your code into optimized assets for production. This ensures your site remains performant when deployed .
Seamless Integration with Modern Tools:

Vite works well with frameworks like React and libraries like TailwindCSS. It also supports TypeScript out of the box, making it future-proof for potential upgrades .
Minimal Configuration:

Vite is designed to require minimal setup. For most projects, the default configuration is sufficient, but it’s also highly customizable if needed .

How Vite Differs from My Current Setup

Currently, I’m using the Tailwind CLI with NPM scripts to process my CSS. While this setup works, it lacks the speed and modularity that Vite offers. Here’s a comparison:

Feature	Current Setup (Tailwind CLI + NPM Scripts)	Vite
Development Server	No built-in server	Built-in, fast, and feature-rich
Hot Module Replacement (HMR)	Manual refresh required	Instant updates without full reload
Production Optimization	Manual minification	Automatic optimization and bundling
Modularity	Limited	Encourages modular components via ES modules

Folder Structure Recommendations

Vite encourages a modular folder structure to keep your project organized. Based on my research, here’s how I plan to restructure my project:

src/
├── components/
│   ├── header.html
│   ├── footer.html
│   └── content.html
├── layout/
│   └── base.html
├── main.css
└── index.html

This structure allows me to break my code into smaller, reusable components. For example, instead of writing all my HTML in a single file, I can split it into logical pieces like header, footer, and content.

Resources I Found Helpful

The Vite documentation provided clear guidance on setting up and configuring the tool .
Articles like “Why Vite is the best?” highlighted its advanced features, such as seamless form handling and built-in state management .
Comparisons between Vite and traditional build tools like Webpack helped me understand its advantages in terms of speed and ease of use .

Why This Step Matters

Researching Vite’s best practices gave me confidence in my decision to adopt it. By understanding its strengths and how it differs from my current setup, I was able to plan a smooth transition. Plus, learning about its modular architecture inspired me to rethink how I organize my code.

3. Install Vite and Set Up the Development Environment

With a solid understanding of Vite’s best practices, I was ready to install it and configure my development environment. This step involved setting up Vite, configuring it to work with my existing TailwindCSS setup, and ensuring everything worked seamlessly. Here’s how I did it:

Step 3.1: Install Vite & Autoprefixer

To integrate Vite into my project, I started by installing it as a development dependency. In my terminal, I ran the following command:

npm install vite --save-dev

This command added Vite to my devDependencies in package.json, making it available for use during development .

Though my current project setup with comes with a Tailwind CSS CLI already included, but there is one more dependencies that Vite may need additionally, the autoprefixer library.

npm install -D autoprefixer --save-dev

By invoking the previous command in your terminal, it would add "autoprefixer": "^10.4.21", to my package.json at the same time.

Step 3.2: Add a Vite Configuration File

Next, I created a vite.config.mjs file in the root directory of my project. This file allows me to customize Vite’s behavior while keeping things simple. Here’s the configuration I used:

// Import required modules for Vite configuration
import { defineConfig } from 'vite';
import tailwindcss from '@tailwindcss/postcss';
import autoprefixer from 'autoprefixer';

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [
        // Add Tailwind CSS as a PostCSS plugin
        tailwindcss(),
        // Add Autoprefixer for vendor prefixing
        autoprefixer()
      ]
    }
  }
});

Why This Configuration?

The root option specifies that Vite should look for my source files in the src folder.
The build.outDir option ensures that production builds are placed in the dist folder, matching my current workflow.
The css.postcss option integrates my existing PostCSS setup, ensuring TailwindCSS continues to work without issues .

"scripts": {
        "dev": "vite", // Start the Vite development server
        "build": "vite build", // Build for production
        "preview": "vite preview", // Preview the production build locally
        "watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch",
        "compress": "npx tailwindcss -i ./src/main.css -o ./dist/style.css --minify",
        "start": "live-server ./dist"
    }

Step 3.3: Update NPM Scripts

To make Vite part of my workflow, I updated the scripts section in my package.json. Here’s what I changed:

What Do These Scripts Do?

npm run dev: Starts the Vite development server, enabling hot module replacement (HMR) for a faster development experience.
npm run build: Creates an optimized production build in the dist folder.
npm run preview: Lets me preview the production build locally before deploying it.
npm run watch: Keeps my existing TailwindCSS workflow intact by watching for changes and rebuilding styles as needed .

4. Update Folder Structure for Modularity Using `vite-plugin-ejs`

To achieve modularity in my project, I decided to use the vite-plugin-ejs plugin . This plugin allows me to break my HTML into smaller, reusable components and assemble them dynamically using EJS templates. Below, I’ll walk you through the entire process—from installing the plugin to restructuring the folder and file structure, and finally modularizing the code.

Step 4.1: Install `vite-plugin-ejs`

The first step was to install the vite-plugin-ejs plugin as a development dependency. In my terminal, I ran the following command:

npm install vite-plugin-ejs --save-dev

This added the plugin to my devDependencies in package.json, making it available for use in my Vite configuration .

Step 4.2: Update `vite.config.js`

Next, I updated my vite.config.js file to include the vite-plugin-ejs plugin. Here’s the updated configuration:

// Import required modules for Vite configuration
import { defineConfig } from 'vite'
import tailwindcss from 'tailwindcss'
import autoprefixer from 'autoprefixer'
import imagemin from 'vite-plugin-imagemin'
import htmlMinifier from 'vite-plugin-html-minifier'
import { ViteEjsPlugin } from 'vite-plugin-ejs'
import { resolve } from 'path'

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 * - Images, HTML, CSS, and JavaScript compressions using Vite plugins
 * - EJS templating for HTML modularity
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/index.html'),
        about: resolve(__dirname, 'src/about.html'),
        contact: resolve(__dirname, 'src/contact.html'),
        blog: resolve(__dirname, 'src/blog.html'),
        category: resolve(__dirname, 'src/category.html'),
      },
    },
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [tailwindcss, autoprefixer],
    },
  },

  // Plugins configuration
  plugins: [
    // Image minification
    imagemin({
      pngquant: {
        quality: [0.7, 0.9],
        speed: 4,
      },
    }),
    // HTML minification
    htmlMinifier({
      minify: true,
      collapseWhitespace: true,
      keepClosingSlash: true,
      removeComments: true,
      removeRedundantAttributes: true,
      removeScriptTypeAttributes: true,
      removeStyleLinkTypeAttributes: true,
      useShortDoctype: true,
    }),
    // EJS templating for HTML
    ViteEjsPlugin(),
  ],

  server: {
    watch: {
      usePolling: true,
    },
  },
})

Why Use `vite-plugin-ejs`?

This plugin enables me to use EJS templates in my HTML files, allowing me to modularize my code into reusable components like header.html, navigation.html, and more .

Step 4.3: Restructure the Folder and File Structure

To modularize my code, I reorganized my project folder structure. Here’s the updated structure:

src/
├── components/
│   ├── Footer.html
│   ├── Header.html
│   ├── Navigation.html
│   ├── nav-desktop.html
│   └── nav-mobile.html
├── layouts/
│   └── base.html
├── content/
│   └── content-about.html
│   └── content-blog-grid.html
│   └── content-blog.html
│   └── content-category.html
│   └── content-home.html
├── main.css
└── index.html

What Changed?

I moved all reusable components (e.g., header, footer) into the components folder.
I created a layouts folder to house the base.html layout file, which serves as the template for assembling components.
I renamed index.html to index.html to leverage EJS templating .

Step 4.4: Modularize the Code

Base Layout (`base.html`)

The base.html file acts as the skeleton of my HTML structure. It includes placeholders for injecting components like header, navigation, content, and footer. Here’s the full code:

<!DOCTYPE html>
<html lang="en">
  <%- include('components/header.html') %>
  <body class="antialiased bg-white dark:bg-main scroll-smooth">
    <%- include('components/navigation.html') %>
    <%- include(typeof content !== 'undefined' ? content : 'content/content-home.html') %>
    <%- include('components/footer.html') %>
    <script type="module" src="./js/app.js"></script>
    <script type="module" src="./js/script.js"></script>
  </body>
</html>

How Does It Work?

The <%- include(...) %> syntax dynamically injects the specified EJS component into the layout. This approach keeps the code modular and reusable .

Header Component (`header.html`)

<head>
  <link rel="manifest" href="./manifest.json">
  <meta name="msapplication-TileColor" content="#ffffff">
  <meta name="msapplication-TileImage" content="./ms-icon-144x144.png">
  <meta name="theme-color" content="#ffffff">
  <link rel="shortcut icon" href="./favicon.ico" type="image/x-icon">
  <link rel="stylesheet" href="./main.css">
  <title></title>
</head>

The header.html file contains the HTML for the site’s header. Here’s the full code:

Navigation Component (`navigation.html`)

The navigation.html file contains the site’s navigation menu. Here’s the full code:

<!-- start the logo, desktop-nav, darkmode button, contact button, nav-icon & mobile-nav  -->
<header id="wrapperNavBar"
  class="sticky top-0 z-10 bg-white p-[25px] drop-shadow-xl blurGrad backdrop-blur-lg dark:bg-main dark:drop-shadow-2xl dark:border-b dark:border-slate-900/20">
  <div id="NavBar" class="flex justify-between max-w-4xl mx-auto">
    <!-- start the logo -->
    <div id="logo" class="z-40 drop-shadow-md">
      <a href="index.html">
        <img src="./img/icons/icon-dgpondcom.png" alt="Logo" id="DGPond" class="w-auto h-auto max-w-full">
      </a>
    </div>
    <%- include('components/nav-desktop.html') %>
    <%- include('components/nav-mobile.html') %>
  </div>
</header>

Footer Component (`footer.html`)

The footer.ejs file contains the site’s footer. Here’s the full code:

<!-- src/components/footer.html -->
<footer class="bg-main text-white py-6">
  <div class="container mx-auto text-center">
    <p>&copy; 2025 All Things Digital. All rights reserved.</p>
  </div>
</footer>

Main Entry Point (`index.html`)

Finally, the index.ejs file serves as the entry point for the application. It simply includes the base.ejs layout:

<!-- src/index.ejs -->
<%- include('layouts/base.html') %>

Step 4.5: Test the Setup

After modularizing the code, I tested the setup by running the development server:

npm run dev

Vite launched the server at http://localhost:5173, and I verified that:

The Tailwind styles were applied correctly.
All components rendered as expected.
Hot module replacement (HMR) worked when editing files .

What Have We Achieved So Far?

Modularizing my code using vite-plugin-ejs made my project easier to maintain and scale. By breaking the HTML into reusable components, I reduced duplication and improved readability. Plus, the use of EJS templates ensured that changes to shared components (like the header or footer) were reflected across all pages automatically .

5. Update NPM Scripts

With my project now modularized and Vite fully integrated, it was time to update my package.json scripts to align with the new workflow. This step ensures that I can efficiently run, build, and preview my project using Vite’s powerful features. Here’s how I approached it:

Step 5.1: Analyze My Current Scripts

Before making changes, I reviewed my existing scripts section in package.json. Here’s what I had:

"scripts": {
  "dev": "tailwindcss -i ./src/main.css -o ./dist/style.css",
  "build": "tailwindcss -i ./src/main.css -o ./dist/style.css",
  "watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch",
  "compress": "npx tailwindcss -o ./dist/style.css --minify",
  "start": "live-server ./dist"
}

While these scripts worked fine for my TailwindCSS setup, they didn’t leverage Vite’s capabilities. For example, the live-server command was unnecessary since Vite includes a built-in development server .

Step 5.2: Update Scripts for Vite

I updated my scripts section to incorporate Vite’s commands while keeping some of my existing workflows intact. Here’s the revised version:

"scripts": {
  "dev": "vite", // Start the Vite development server with hot module replacement (HMR)
  "build": "vite build", // Build the project for production
  "preview": "vite preview", // Preview the production build locally
  "tailwind:watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch", // Watch and rebuild Tailwind styles during development
  "start": "npm run dev" // Alias for starting the development server
}

What Do These Scripts Do?

npm run dev: Starts the Vite development server, enabling HMR for a faster and more interactive development experience .
npm run build: Creates an optimized production build in the dist folder, ready for deployment.
npm run preview: Allows me to preview the production build locally before deploying it. This is particularly useful for testing performance and functionality .
npm run tailwind:watch: Keeps my existing TailwindCSS workflow intact by watching for changes and rebuilding styles as needed.
npm run start: Acts as a convenient alias for starting the development server.

Step 5.3: Test the Updated Scripts

To ensure everything worked as expected, I tested each script:

Start the Development Server

I ran the following command:
```
npm run dev
```
Vite launched the development server at http://localhost:5173, and my modular components rendered perfectly. Hot module replacement (HMR) worked seamlessly, updating the browser instantly when I made changes .
Build for Production

Next, I built the project for production:
```
npm run build
```
Vite generated an optimized build in the dist folder. The output included minified CSS and JavaScript files, ensuring high performance .
Preview the Production Build

To verify the production build, I ran:
```
npm run preview
```
Vite served the production build locally, allowing me to test its functionality and performance before deploying it.
Watch Tailwind Styles

Finally, I tested the tailwind:watch script:
```
npm run tailwind:watch
```
This ensured that my Tailwind styles were rebuilt automatically whenever I made changes to my CSS or HTML files .

Why This Step Matters

Updating my NPM scripts streamlined my workflow and aligned it with Vite’s best practices. By replacing live-server with Vite’s built-in development server, I eliminated redundancy and improved performance. Additionally, the preview script gave me confidence in my production builds before deploying them. For further reading on Vite’s capabilities, I recommend checking out the official Vite documentation .

6. Adjust TailwindCSS Setup

With Vite and vite-plugin-ejs now fully integrated into my project, it was time to adjust my TailwindCSS setup to ensure it worked seamlessly with the new modular structure. This step involved updating the tailwind.config.js file, ensuring proper content scanning, and optimizing the workflow for both development and production environments.

Step 6.1: Update `tailwind.config.mjs`

The first thing I did was update the content property in my tailwind.config.js file. Since I had modularized my HTML into .ejs files, I needed to ensure Tailwind scanned these files for class names .

Here’s the updated configuration:

const colors = require("tailwindcss/colors");

/** @type {import('tailwindcss').Config} */
module.exports = {
  // Scan for Tailwind classes in .ejs files
  content: [
    "./src/**/*.{html,ejs,js,ts}", // Include all HTML, EJS, and JS files in the src folder
  ],
  darkMode: "class",
  theme: {
    screens: {
      sm: "480px",
      md: "768px",
      lg: "976px",
      xl: "1440px",
    },
    extend: {
      animation: {
        blob: "blob 7s infinite",
      },
      colors: {
        savoryWhite: "hsl(0, 36%, 95%)",
        mutedWhite: "hsl(224, 16%, 54%)",
        whiteHover: "hsl(0, 36%, 95%)",
        pinkHeading: "hsl(279, 48%, 54%)",
        pinkSubHeading: "hsl(293, 43%, 55%)",
        blackSubHeading: "hsl(221, 39%, 11%)",
        deepBlueSubHeading: "hsl(229, 38%, 40%)",
        fuchsia: colors.fuchsia,
      },
      keyframes: {
        blob: {
          "0%": {
            transform: "translate(0px, 0px) scale(1)",
          },
          "33%": {
            transform: "translate(30px, -50px) scale(1.1)",
          },
          "66%": {
            transform: "translate(-20px, 20px) scale(0.9)",
          },
          "100%": {
            transform: "translate(0px, 0px) scale(1)",
          },
        },
      },
      backgroundColor: {
        main: "hsl(215, 45%, 14%)",
      },
    },
    fontFamily: {
      navigation: ["Poppins", "sans-serif"],
    },
  },
  plugins: [
    require("@tailwindcss/typography"),
    require("@tailwindcss/forms"),
    require("@tailwindcss/line-clamp"),
  ],
};

Why This Change?

By including .html & .ejs files in the content array, I ensured that Tailwind scanned my modular components for class names. This prevents unused styles from being purged during production builds .

Step 6.2: Optimize TailwindCSS Workflow

To make my TailwindCSS workflow more efficient, I kept the tailwind:watch script in my package.json. This script watches for changes in my CSS and rebuilds styles automatically during development:

"scripts": {
  "dev": "vite",
  "build": "vite build",
  "preview": "vite preview",
  "tailwind:watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch", // Watch and rebuild Tailwind styles
  "start": "npm run dev"
}

This ensures that my styles are always up-to-date, even when working with modular both .html & .ejs files.

Step 6.3: Test the TailwindCSS Integration

To verify that TailwindCSS was working correctly, I performed the following tests:

Development Environment

I ran the tailwind:watch script alongside the Vite development server:
```
npm run tailwind:watch & npm run dev
```
This allowed me to see real-time updates to my styles as I edited my .html components .
Production Build

Next, I built the project for production:
```
npm run build
```
Vite generated an optimized build in the dist folder, including minified CSS and JavaScript files. I verified that all Tailwind classes were included and applied correctly .
Preview the Production Build

Finally, I previewed the production build locally:
```
npm run preview
```
The site rendered perfectly, with all styles intact and no missing classes.

Why This Step Matters

Adjusting my TailwindCSS setup ensured that it worked seamlessly with my new modular structure. By updating the content property in tailwind.config.js, I avoided issues with purging unused styles during production builds. Additionally, the tailwind:watch script streamlined my development workflow, making it easier to iterate on designs .

For further reading on integrating TailwindCSS with Vite, I recommend checking out this GitHub repository .

7. Test the Development Workflow

With my project now fully integrated with Vite, vite-plugin-ejs, and TailwindCSS, it was time to test the development workflow. This step ensured that everything worked as expected—both in development and production environments. Here’s how I approached it:

Step 7.1: Start the Development Server

I began by starting the Vite development server using the dev script:

npm run dev

Vite launched the server at http://localhost:5173, and my modular components rendered perfectly . The hot module replacement (HMR) feature worked seamlessly, updating the browser instantly whenever I made changes to my .html files or CSS.

What Did I Test?

HTML Components: I verified that all modular components (header.html, navigation.html, content.html, and footer.html) were rendered correctly within the base.html layout.
Tailwind Styles: I checked that all Tailwind classes were applied as expected, ensuring no styles were missing or broken.
Dynamic Updates: I edited one of my .html files (e.g., header.html) and confirmed that the changes appeared immediately in the browser without requiring a full reload .

Step 7.2: Test TailwindCSS Watch Mode

To ensure my styles were always up-to-date during development, I ran the tailwind:watch script alongside the Vite server:

npm run tailwind:watch & npm run dev

This combination allowed me to see real-time updates to my styles as I edited my .html components or main.css file . For example, when I added a new Tailwind class like text-pinkHeading to the header.html file, the change was reflected instantly in the browser.

Step 7.3: Build for Production

Next, I tested the production build process by running:

npm run build

Vite generated an optimized build in the dist folder, including minified CSS and JavaScript files. To verify the output, I inspected the dist folder and confirmed that:

All .html components were compiled into static HTML files.
TailwindCSS purged unused styles, resulting in a smaller CSS file size .
The production build included all necessary assets (e.g., images, fonts).

Here’s an example of the optimized index.html file generated in the dist folder:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>All Things Digital</title>
  <link rel="stylesheet" href="/style.css">
</head>
<body>
  <!-- Header Component -->
  <header class="bg-savoryWhite text-blackSubHeading py-4">
    <div class="container mx-auto flex justify-between items-center">
      <h1 class="text-pinkHeading font-bold text-2xl">All Things Digital</h1>
      <button id="menu-toggle" class="hamburger">
        <span class="hamburger-top"></span>
        <span class="hamburger-middle"></span>
        <span class="hamburger-bottom"></span>
      </button>
    </div>
  </header>

  <!-- Navigation Component -->
  <nav class="hidden md:flex space-x-6 text-mutedWhite">
    <a href="/" class="hover:text-whiteHover">Home</a>
    <a href="/about.html" class="hover:text-whiteHover">About</a>
    <a href="/blog.html" class="hover:text-whiteHover">Blog</a>
    <a href="/contact.html" class="hover:text-whiteHover">Contact</a>
  </nav>

  <!-- Content Component -->
  <main>
    <section class="py-8">
      <div class="container mx-auto">
        <h2 class="text-pinkSubHeading text-3xl font-bold mb-4">Welcome to All Things Digital</h2>
        <p class="text-mutedWhite">
          Explore the latest trends, tips, and insights in the digital world.
        </p>
      </div>
    </section>
  </main>

  <!-- Footer Component -->
  <footer class="bg-main text-white py-6">
    <div class="container mx-auto text-center">
      <p>&copy; 2025 All Things Digital. All rights reserved.</p>
    </div>
  </footer>
</body>
</html>

Why Is This Important?

The production build ensures that my site is optimized for performance, with minimal file sizes and no unnecessary code. This is critical for delivering a fast and responsive user experience .

Step 7.4: Preview the Production Build

To test the production build locally, I ran:

npm run preview

Vite served the production build at http://localhost:4173, allowing me to verify its functionality and performance. I performed the following checks:

Rendering: Ensured all components and styles rendered correctly.
Performance: Verified that the site loaded quickly, thanks to Vite’s optimized build process.
Responsiveness: Tested the site on different screen sizes to confirm that Tailwind’s responsive utilities worked as expected .

Step 7.5: Document Observations

Throughout the testing process, I documented my observations and added comments to relevant files. For example, here’s a comment I added to my vite.config.js file:

// Import required modules for Vite configuration
import { defineConfig } from 'vite'
import tailwindcss from 'tailwindcss'
import autoprefixer from 'autoprefixer'
import imagemin from 'vite-plugin-imagemin'
import htmlMinifier from 'vite-plugin-html-minifier'
import { ViteEjsPlugin } from 'vite-plugin-ejs'
import { resolve } from 'path'

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 * - Images, HTML, CSS, and JavaScript compressions using Vite plugins
 * - EJS templating for HTML modularity
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/index.html'),
        about: resolve(__dirname, 'src/about.html'),
        contact: resolve(__dirname, 'src/contact.html'),
        blog: resolve(__dirname, 'src/blog.html'),
        category: resolve(__dirname, 'src/category.html'),
      },
    },
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [tailwindcss, autoprefixer],
    },
  },

  // Plugins configuration
  plugins: [
    // Image minification
    imagemin({
      pngquant: {
        quality: [0.7, 0.9],
        speed: 4,
      },
    }),
    // HTML minification
    htmlMinifier({
      minify: true,
      collapseWhitespace: true,
      keepClosingSlash: true,
      removeComments: true,
      removeRedundantAttributes: true,
      removeScriptTypeAttributes: true,
      removeStyleLinkTypeAttributes: true,
      useShortDoctype: true,
    }),
    // EJS templating for HTML
    ViteEjsPlugin(),
  ],

  server: {
    watch: {
      usePolling: true,
    },
  },
})

Why Add Comments?

Comments make the code easier to understand for future me—or anyone else who might work on the project. They also serve as a reminder of why certain decisions were made .

Why This Step Matters

Testing the development workflow ensured that my project was ready for both development and production environments. By verifying that Vite, vite-plugin-ejs, and TailwindCSS worked seamlessly together, I gained confidence in the stability and performance of my site . For further reading on conducting effective tests, I recommend this step-by-step guide for knowledge checks .

8. Build for Production

With my development workflow thoroughly tested, it was time to focus on building the project for production. This step ensures that my site is optimized for performance, with minimal file sizes and no unnecessary code. Here’s how I approached it:

Step 8.1: Run the Production Build Command

I started by running the build script, which generates an optimized production build in the dist folder:

npm run build

Vite processed my modular .html & .ejs components, TailwindCSS styles, and JavaScript files, bundling them into a clean and efficient structure . The output included:

Minified CSS and JavaScript files.
Static HTML files compiled from my .html & .ejs templates.
All necessary assets (e.g., images, fonts) copied to the dist folder.

Here’s an example of the optimized index.html file generated in the dist folder:

<!-- dist/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>All Things Digital</title>
  <link rel="stylesheet" href="/style.css">
</head>
<body>
  <!-- Header Component -->
  <header class="bg-savoryWhite text-blackSubHeading py-4">
    <div class="container mx-auto flex justify-between items-center">
      <h1 class="text-pinkHeading font-bold text-2xl">All Things Digital</h1>
      <button id="menu-toggle" class="hamburger">
        <span class="hamburger-top"></span>
        <span class="hamburger-middle"></span>
        <span class="hamburger-bottom"></span>
      </button>
    </div>
  </header>

  <!-- Navigation Component -->
  <nav class="hidden md:flex space-x-6 text-mutedWhite">
    <a href="/" class="hover:text-whiteHover">Home</a>
    <a href="/about.html" class="hover:text-whiteHover">About</a>
    <a href="/blog.html" class="hover:text-whiteHover">Blog</a>
    <a href="/contact.html" class="hover:text-whiteHover">Contact</a>
  </nav>

  <!-- Content Component -->
  <main>
    <section class="py-8">
      <div class="container mx-auto">
        <h2 class="text-pinkSubHeading text-3xl font-bold mb-4">Welcome to All Things Digital</h2>
        <p class="text-mutedWhite">
          Explore the latest trends, tips, and insights in the digital world.
        </p>
      </div>
    </section>
  </main>

  <!-- Footer Component -->
  <footer class="bg-main text-white py-6">
    <div class="container mx-auto text-center">
      <p>&copy; 2025 All Things Digital. All rights reserved.</p>
    </div>
  </footer>
</body>
</html>

Why Is This Important?

The production build ensures that my site is ready for deployment, with all assets optimized for speed and efficiency. This is critical for delivering a fast and responsive user experience .

Step 8.2: Inspect the Output Folder

After the build process completed, I inspected the dist folder to verify its contents:

CSS: The style.css file was minified, ensuring faster load times.
HTML: My modular .ejs components were compiled into static HTML files, making them easy to serve.
Assets: Images, fonts, and other assets were copied to the dist folder, ensuring they were available for use.

Here’s a snapshot of the dist folder structure:

dist/
├── assets/
├── index.html
├── about.html
├── blog.html
├── style.css
└── script.js

What Did I Learn?

Inspecting the dist folder gave me confidence that everything was in place for deployment. Vite’s build process handled all optimizations automatically, saving me time and effort .

Step 8.3: Preview the Production Build

To test the production build locally, I ran the preview script:

npm run preview

Vite served the production build at http://localhost:4173, allowing me to verify its functionality and performance . I performed the following checks:

Rendering: Ensured all components and styles rendered correctly.
Performance: Verified that the site loaded quickly, thanks to Vite’s optimized build process.
Responsiveness: Tested the site on different screen sizes to confirm that Tailwind’s responsive utilities worked as expected.

Why Use the preview Script?

The preview script lets me test the production build locally before deploying it, reducing the risk of errors or broken functionality in the live environment .

Step 8.4: Add Comments to Key Files

To make my production setup easier to understand, I added comments to key files like vite.config.js and tailwind.config.js. For example, here’s a comment I added to my vite.config.js file:

// Vite configuration for All Things Digital
import { defineConfig } from 'vite';
import postcss from './postcss.config.js'; // Reuse my existing PostCSS setup
import ejs from 'vite-plugin-ejs';

export default defineConfig({
  root: './src', // Set the root directory for my source files
  plugins: [ejs()], // Add the EJS plugin for modular components
  build: {
    outDir: '../dist', // Output directory for production builds
    emptyOutDir: true, // Clear the output directory before building
  },
  css: {
    postcss, // Use my existing PostCSS setup
  },
});

Why Add Comments?

Comments make the code easier to understand for future me—or anyone else who might work on the project. They also serve as a reminder of why certain decisions were made .

Step 8.5: Prepare for Deployment

Finally, I prepared the dist folder for deployment. Since the production build includes all necessary assets, I simply uploaded the contents of the dist folder to my hosting provider. Tools like Netlify, Vercel, or GitHub Pages make this process seamless .

Why This Step Matters

Building for production ensures that my site is optimized for performance, with minimal file sizes and no unnecessary code. By verifying the output and testing the production build locally, I gained confidence in the stability and performance of my site .

For further reading on optimizing production builds, I recommend checking out this guide on Tyk Self-Managed .

In conclusion, integrating Vite into my project has been a transformative experience, streamlining my workflow and enhancing both development and production processes . By modularizing my code and leveraging tools like vite-plugin-ejs, I’ve created a scalable, maintainable, and efficient setup that aligns with modern best practices. This journey not only improved my site’s performance but also deepened my understanding of how cutting-edge tools like Vite can elevate web development . With this solid foundation in place, I’m excited to explore even more possibilities in the future .

Final Wrap-up

Why Upgrading to Tailwind CSS 4.1.4 Might Be the Best Decision You Make This Year

gerry leo nugroho — Wed, 30 Apr 2025 07:57:11 +0000

1. The Quick Intro

When I first set up my project, I chose TailwindCSS 3.4.17 because it was stable, reliable, and packed with all the utilities I needed to build a sleek, responsive design. Paired with Vite 6.3.2 for its blazing-fast development server and autoprefixer 10.4.21 to handle browser compatibility, my workflow felt smooth and efficient. However, as the web development landscape evolves, so do the tools we rely on. Recently, TailwindCSS 4.1.4 was released, and after reading through the official announcement , I realized it’s time to take my project to the next level.

The motivation for this upgrade is simple: TailwindCSS 4.1.4 promises significant performance improvements, modern CSS feature support, and new utilities that could enhance my current design. For example, the improved dark mode utilities and better customization options caught my attention immediately. But beyond just upgrading, I wanted to document the entire process—warts and all—as a learning experience. Not only will this help me understand the changes better, but it might also assist others who are considering making the leap.

By the end of this journey, I expect to have a fully upgraded project running on TailwindCSS 4.1.4, with all potential issues resolved and a cleaner, more optimized codebase. I’ll also be taking full advantage of the new features introduced in this version, ensuring my project stays cutting-edge. To top it off, I’ll be documenting every step of the way, turning this technical upgrade into a blog post that’s both professional and approachable.

If you’re curious about what TailwindCSS 4.1.4 offers, check out the official release notes from the TailwindCSS team. It’s packed with insights into why this version is such a game-changer for modern web development. So, let’s dive in and see how we can make this upgrade seamless—and maybe even fun! And as usual, for the impatience folks, here's the Github repo URL.

2. Preparing for the Upgrade

Before jumping into the upgrade process, I knew it was crucial to prepare thoroughly. Upgrading a major dependency like TailwindCSS can sometimes lead to unexpected issues, so having a backup plan and understanding the scope of the changes is essential. Here’s how I got started.

Step 2.1: Create a Backup Branch

The first thing I did was create a new branch in my repository to serve as a safety net. This way, if anything went wrong during the upgrade, I could easily revert to the previous state without losing any work. I opened my terminal and ran the following commands:

# Create a new branch named "upgraded-tailwindcss-4.1"
git checkout -b upgraded-tailwindcss-4.1

# Push the branch to the remote repository
git push origin upgraded-tailwindcss-4.1

This step ensures that I have a clean slate to experiment with TailwindCSS 4.1.4 while keeping my main branch untouched. It’s always better to be safe than sorry, especially when dealing with breaking changes .

Step 2.2: Review Current Dependencies

Next, I reviewed my current dependencies in the package.json file to ensure compatibility with TailwindCSS 4.1.4. My setup includes Vite 6.3.2 and autoprefixer 10.4.21, both of which are relatively recent versions. However, since TailwindCSS 4.1.4 is a major release, I wanted to double-check that these tools wouldn’t cause conflicts. Here’s what my package.json looked like before the upgrade:

{
  "dependencies": {
    "autoprefixer": "^10.4.21", // Handles browser-specific prefixes
    "postcss": "^8.4.31",       // Processes CSS with plugins
    "tailwindcss": "^3.4.17",   // The current version of TailwindCSS
    "vite": "^6.3.2"            // Fast development server
  }
}

After reviewing the TailwindCSS upgrade guide, I confirmed that Vite and autoprefixer were compatible with TailwindCSS 4.1.4. However, I noted that some older browsers might no longer be supported due to the framework’s modern CSS features . Since my project doesn’t target legacy browsers, this wasn’t a concern for me.

Step 2.3: Review TailwindCSS 4.1.4 Features

To make the most of the upgrade, I spent some time reading about the new features introduced in TailwindCSS 4.1.4. According to a recent article, this version offers exciting utilities like colored drop shadows, text shadows, masking utilities, and improved dark mode support . These enhancements sounded perfect for refining my design system.

For example, the improved dark mode utilities caught my attention because they simplify toggling between light and dark themes. Instead of manually overriding styles, I could now rely on Tailwind’s intuitive class names to handle the heavy lifting. Similarly, the new masking utilities could help me create more creative layouts without writing custom CSS.

By taking these preparatory steps, I felt confident moving forward with the upgrade. Creating a backup branch ensured I had a fallback option, reviewing dependencies helped me identify potential conflicts, and familiarizing myself with TailwindCSS 4.1.4’s features allowed me to plan how to incorporate them into my project. With everything in place, I was ready to dive into the actual upgrade process.

3. Upgrading TailwindCSS

With the preparation complete, it was time to dive into the actual upgrade process. I wanted to ensure that everything went smoothly, so I followed a methodical approach. Here’s how I upgraded TailwindCSS from version 3.4.17 to 4.1.4 in my Vite-powered project.

Step 3.1: Update Dependencies

The first step was updating the dependencies in my project. Since TailwindCSS 4.1.4 is a major release, I knew I had to update not only Tailwind itself but also its peer dependencies, such as postcss and autoprefixer, to ensure compatibility .

I opened my terminal and ran the following command:

# Install the latest versions of TailwindCSS, PostCSS, and Autoprefixer
npm install -D tailwindcss@latest postcss autoprefixer

This command updated all three packages to their latest versions. After the installation completed, I checked my package.json file to confirm the new versions:

{
  "dependencies": {
    "autoprefixer": "^10.4.21", // Updated to work with TailwindCSS 4.1.4
    "postcss": "^8.5.3",       // Ensures compatibility with modern CSS features
    "tailwindcss": "^4.1.4"     // The shiny new version of TailwindCSS
  }
}

At this point, I felt confident that my dependencies were aligned with TailwindCSS 4.1.4’s requirements.

Step 3.2: Update Tailwind Configuration

Next, I needed to update my tailwind.config.js file to reflect any changes introduced in TailwindCSS 4.1.4. To start fresh, I generated a new configuration file using the Tailwind CLI:

# Generate a new TailwindCSS configuration file
npx tailwindcss init

This created a default tailwind.config.js file. However, since my project already had customizations (e.g., theme extensions, plugins), I compared the new file with my old one and merged the necessary changes.

Here’s what my updated tailwind.config.js looked like after merging:

const colors = require("tailwindcss/colors");

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,js}"],
  darkMode: "class",
  theme: {
    screens: {
      sm: "480px",
      md: "768px",
      lg: "976px",
      xl: "1440px",
    },
    extend: {
      animation: {
        blob: "blob 7s infinite",
      },
      colors: {
        savoryWhite: "hsl(0, 36%, 95%)",
        mutedWhite: "hsl(224, 16%, 54%)",
        whiteHover: "hsl(0, 36%, 95%)",
        pinkHeading: "hsl(279, 48%, 54%)",
        pinkSubHeading: "hsl(293, 43%, 55%)",
        blackSubHeading: "hsl(221, 39%, 11%)",
        deepBlueSubHeading: "hsl(229, 38%, 40%)",
        fuchsia: colors.fuchsia,
      },
      keyframes: {
        blob: {
          "0%": {
            transform: "translate(0px, 0px) scale(1)",
          },
          "33%": {
            transform: "translate(30px, -50px) scale(1.1)",
          },
          "66%": {
            transform: "translate(-20px, 20px) scale(0.9)",
          },
          "100%": {
            transform: "tranlate(0px, 0px) scale(1)",
          },
        },
      },
      backgroundColor: {
        main: "hsl(215, 45%, 14%)",
      },
    },
    fontFamily: {
      navigation: ["Poppins", "sans-serif"],
    },
  },
  plugins: [require("@tailwindcss/typography"), require("@tailwindcss/forms")],
};

Each section of the configuration file is commented to explain its purpose, making it easier for future me (or anyone else) to understand.

Step 3.3: Update PostCSS Configuration

Since TailwindCSS relies on PostCSS for processing, I ensured my postcss.config.js file was correctly configured to use the updated version of TailwindCSS. Here’s what my postcss.config.js looked like:

module.exports = {
  plugins: {
    tailwindcss: {}, // Use the new @tailwindcss/postcss plugin
    autoprefixer: {}, // Ensure browser-specific prefixes are added
  },
};

This configuration ensures that TailwindCSS 4.1.4 works seamlessly with PostCSS and autoprefixer, enabling features like colored drop shadows and text shadows introduced in this version .

Step 3.4: Test the Build Process

With the configuration files updated, it was time to test whether everything worked as expected. I started by running the build process:

# Run the build process to generate CSS
npm run build

After the build completed successfully, I launched the development server to verify that my styles rendered correctly:

# Start the Vite development server
npm run dev

To my relief, everything loaded without errors, and my design looked consistent with the previous version. This gave me confidence that the upgrade was successful.

3. Upgrading TailwindCSS 3.4.17 to 4.1.4

Upgrading to TailwindCSS 4.1.4 was a bit of a rollercoaster, but thanks to the official upgrade tool, the process turned out to be smoother than I initially anticipated. Here’s how I navigated the upgrade and adapted my project to the new structure introduced in this version.

Step 3.1: Running the Upgrade Tool

To kick things off, I used the official TailwindCSS upgrade tool, which automates much of the migration process . Running the command $ npx @tailwindcss/upgrade in my terminal produced the following output:

npx @tailwindcss/upgrade
≈ tailwindcss v4.1.4
│ Searching for CSS files in the current directory and its subdirectories…
│ ↳ Linked `./tailwind.config.js` to `./src/main.css`
│ Migrating JavaScript configuration files…
│ ↳ Migrated configuration file: `./tailwind.config.js`
│ Migrating templates…
│ ↳ Migrated templates for configuration file: `./tailwind.config.js`
│ Migrating stylesheets…
│ ↳ Migrated stylesheet: `./src/main.css`
│ Migrating PostCSS configuration…
│ ↳ Installed package: `@tailwindcss/postcss`
│ ↳ Removed package: `autoprefixer`
│ ↳ Migrated PostCSS configuration: `./postcss.config.js`
│ Updating dependencies…
│ ↳ Updated package: `prettier-plugin-tailwindcss`
│ ↳ Updated package: `tailwindcss`
│ Verify the changes and commit them to your repository.

This tool did most of the heavy lifting for me. It consolidated my TailwindCSS configuration into my main CSS file (./src/main.css) and removed the need for a separate tailwind.config.js file. This change aligns with TailwindCSS 4.1.4’s streamlined approach to configuration .

Step 3.2: Simplifying the CSS Setup

One of the biggest changes in TailwindCSS 4.1.4 is the elimination of the classic @tailwind directives in CSS files. Instead of manually including the following lines:

/* Old approach */
@tailwind base;
@tailwind components;
@tailwind utilities;

The new setup requires just a single line, in your main CSS file:

/* New approach */
import "tailwindcss";

This simplification reduces boilerplate code and makes the setup more intuitive. I updated my main.css file accordingly, and everything worked seamlessly.

Step 3.3: Automatically Updated HTML Classes

The upgrade tool also automatically rewrote some of my HTML classes to reflect changes in TailwindCSS 4.1.4 For example, the drop-shadow-sm utility was replaced with drop-shadow-xs, and custom breakpoints like max-w-screen-md were updated to use CSS variables (max-w-(--breakpoint-md)). These updates ensure compatibility with the latest version while improving consistency across projects. Here’s an example of the transformation:

Before:

<footer class="flex flex-col items-center max-w-3xl mx-auto my-10 border-t dark:border-slate-800/60">
  <div class="flex max-w-xs pt-5 mx-auto -mt-10 overflow-hidden drop-shadow-sm grayscale opacity-80">
    <img src="./img/icons/logo-footer.png" width="35" height="35" alt="bottom-logo" class="">
  </div>
  <div class="mt-5">
    <ul class="flex flex-wrap justify-between max-w-screen-md mx-auto text-sm font-navigation text-slate-400">
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">

After:

<footer class="flex flex-col items-center max-w-3xl mx-auto my-10 border-t dark:border-slate-800/60">
  <div class="flex max-w-xs pt-5 mx-auto -mt-10 overflow-hidden drop-shadow-xs grayscale opacity-80">
    <img src="./img/icons/logo-footer.png" width="35" height="35" alt="bottom-logo" class="">
  </div>
  <div class="mt-5">
    <ul class="flex flex-wrap justify-between max-w-(--breakpoint-md) mx-auto text-sm font-navigation text-slate-400">
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">

These changes not only modernized my code but also ensured it adheres to TailwindCSS 4.1.4’s best practices.

Step 3.4: Integrating with Vite

Since my project uses Vite, I needed to install the @tailwindcss/vite plugin to ensure compatibility. I ran the following command:

npm install @tailwindcss/vite

Next, I updated my vite.config.mjs file to include the plugin:

import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";

// Define Vite configuration
export default defineConfig({
  plugins: [
    tailwindcss(), // Add the TailwindCSS Vite plugin
  ],
});

This step ensures that Vite processes TailwindCSS correctly during development and production builds.

Step 3.5: Updating PostCSS Configuration

Finally, I updated my postcss.config.js file to use the @tailwindcss/postcss plugin, which replaces the older autoprefixer dependency. Here’s the updated configuration:

module.exports = {
  plugins: {
    '@tailwindcss/postcss': {}, // Use the new TailwindCSS PostCSS plugin
  },
};

This change simplifies the PostCSS setup and ensures that all TailwindCSS features are processed efficiently .

Step 3.6: Testing the Build Process

After completing these steps, I tested the build process to ensure everything worked as expected. I ran the following commands:

# Build the project
npm run build

# Start the development server
npm run dev

Both commands executed without errors, and my project compiled successfully. The new performance optimizations in TailwindCSS 4.1.4, such as faster incremental builds and path exclusion during scanning, were immediately noticeable .

By leveraging the official upgrade tool and carefully following the migration steps, I was able to upgrade to TailwindCSS 4.1.4 with minimal friction. The new single-line CSS import, simplified configuration, and automatic class updates made the process feel less daunting than I initially expected. With everything now running smoothly, I’m excited to explore the new features and optimizations this version has to offer.

4. Addressing Potential Issues

Even with the best preparation, upgrading to a major version of TailwindCSS can sometimes introduce unexpected challenges. During my upgrade process, I encountered a few issues that required troubleshooting. Here’s how I addressed them and ensured everything worked smoothly.

Step 4.1.4: Browser Compatibility

One of the first things I checked after upgrading was browser compatibility. TailwindCSS 4.1.4 introduced features like oklab color spaces and modern CSS utilities, which might not work perfectly in older browsers . While my project doesn’t target legacy browsers, I wanted to confirm that everything would render correctly for users on the latest versions of Chrome, Firefox, and Safari.

To test this, I opened my project in multiple browsers and inspected elements using their developer tools. Thankfully, everything looked as expected, and the new utilities like colored drop shadows rendered beautifully. However, if you’re supporting older browsers, you might need to stick with TailwindCSS 3.4.17 or use polyfills to bridge the gap .

Step 4.2: Deprecated Features and Utilities

TailwindCSS 4.1.4 removed some deprecated utilities and configuration patterns that were present in earlier versions. For example, the @theme directive and certain PostCSS plugins are no longer supported . This change could break custom configurations or plugins that rely on these features.

In my case, the upgrade tool handled most of these changes automatically, but I did notice that some custom utility classes I had defined in my old tailwind.config.js file were no longer recognized. To fix this, I redefined them in the new configuration format:

// Updated custom utilities in tailwind.config.js
/** @type {import('tailwindcss').Config} */
export default {
  theme: {
    extend: {
      boxShadow: {
        'custom': '0 4px 6px rgba(0, 0, 0, 0.1), 0 1px 3px rgba(0, 0, 0, 0.06)', // Custom shadow utility
      },
    },
  },
};

By redefining these utilities, I ensured they were compatible with TailwindCSS 4.1.4 while maintaining the same functionality.

Step 4.3: Debugging Drop-Shadow Issues

While testing my updated project, I noticed that some of my drop-shadow effects weren’t rendering correctly. After digging into the issue, I discovered that multiple drop-shadows were still broken in TailwindCSS 4.1.4 due to a bug in the default drop-shadow utility . Fortunately, this was a known issue, and the TailwindCSS team provided a workaround by defining custom drop-shadow values in the configuration file.

Here’s how I fixed the issue:

// Add custom drop-shadow utilities in tailwind.config.js
/** @type {import('tailwindcss').Config} */
export default {
  theme: {
    extend: {
      dropShadow: {
        'custom-lg': [
          '0 10px 8px rgba(0, 0, 0, 0.1)',
          '0 4px 3px rgba(0, 0, 0, 0.06)', // Layered shadows for depth
        ],
      },
    },
  },
};

With this adjustment, my drop-shadow effects worked as intended, and I was able to take full advantage of the new colored drop-shadow utilities introduced in TailwindCSS 4.1.4 .

Step 4.4: Handling Performance Optimizations

TailwindCSS 4.1.4 includes several performance optimizations, such as path exclusion during scanning and a source-inline option for large-scale projects . While these improvements are automatic, I wanted to ensure they were working effectively in my setup.

To verify this, I ran a production build (npm run build) and analyzed the output. The generated CSS file was significantly smaller than before, thanks to the new optimizations. Additionally, the development server (npm run dev) felt faster, especially when making incremental changes to my styles.

Step 4.5: Resolving Plugin Conflicts

Since I’m using Vite, I initially encountered a conflict between the @tailwindcss/vite plugin and my existing PostCSS configuration. Specifically, the @tailwindcss/postcss plugin wasn’t being applied correctly, leading to missing styles in my build.

To resolve this, I double-checked my vite.config.mjs and postcss.config.js files to ensure they were properly configured. Here’s the final setup that worked for me:

`vite.config.mjs`:

import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";

// Define Vite configuration
export default defineConfig({
  plugins: [
    tailwindcss(), // Ensure the TailwindCSS Vite plugin is included
  ],
});

`postcss.config.js`:

module.exports = {
  plugins: {
    '@tailwindcss/postcss': {}, // Use the new TailwindCSS PostCSS plugin
  },
};

With these adjustments, the conflict was resolved, and all styles were applied correctly.

By addressing these potential issues, I was able to ensure a smooth transition to TailwindCSS 4.1.4. Whether it was debugging drop-shadow problems, redefining deprecated utilities, or resolving plugin conflicts, each challenge taught me something new about the framework. With these fixes in place, I felt confident moving forward and exploring the exciting new features this version has to offer.

Step 4.6: TailwindCSS 4.1.4 and Configuration Files

TailwindCSS 4.1.4 introduced a CSS-first configuration approach, which means you can now configure many aspects of Tailwind directly in your CSS files instead of relying solely on a tailwind.config.js or tailwind.config.ts file . This shift simplifies setup by reducing the need for separate JavaScript/TypeScript configuration files. However, config files (tailwind.config.js) are not fully deprecated. They are still used for:

Advanced customizations (e.g., plugins, theme extensions).
Backward compatibility during the transition phase .

Step 4.7: Why We Still Used `tailwind.config.js` in the Upgrade

In our case, the upgrade tool migrated your existing configuration to the new CSS-first approach but retained a minimal tailwind.config.js file for two reasons:

Legacy Support: Some plugins or custom utilities (e.g., drop-shadow fixes) still require a config file .
Gradual Migration: The tool avoids breaking your workflow by keeping a config file for any pre-existing customizations .

Example of CSS-First Configuration

Instead of defining everything in tailwind.config.js, you can now configure Tailwind directly in your CSS:

/* main.css */
@config {
  theme: {
    extend: {
      colors: { /* Custom colors */ },
      spacing: { /* Custom spacing */ },
    }
  },
  plugins: [ /* Plugins */ ],
}

@tailwind base;
@tailwind components;
@tailwind utilities;

When to Use `tailwind.config.js`

You’ll still need the config file if you:

Use plugins (e.g., @tailwindcss/typography).
Define complex theme extensions that are easier to manage in JavaScript.
Need backward compatibility with older project setups .

Key Takeaways

CSS-first configuration is the new default in TailwindCSS 4.1.4, reducing reliance on JS/TS files .
Config files (tailwind.config.js) are retained for advanced use cases and backward compatibility .
The upgrade tool balances modern practices with practicality, ensuring your project works during the transition .

If you want to dive deeper, the official upgrade guide explains this shift in detail .

5. Leveraging New Features

Now that my project is fully upgraded to TailwindCSS 4.1.4, it’s time to take advantage of the exciting new features this version has to offer. From enhanced dark mode utilities to creative masking tools and colored drop shadows, I was eager to see how these additions could elevate my design system. Here’s how I incorporated some of these features into my project.

Step 5.1: Enhanced Dark Mode Utilities

One of the standout improvements in TailwindCSS 4.1.4 is the refined dark mode support . The new utilities make it easier than ever to toggle between light and dark themes without writing custom CSS. For example, instead of manually overriding styles, I can now use intuitive class names like dark:bg-slate-900 or dark:text-white.

Here’s how I updated my footer section to take full advantage of the improved dark mode:

<!-- Footer with enhanced dark mode -->
<footer class="flex flex-col items-center max-w-3xl mx-auto my-10 border-t dark:border-slate-800/60">
  <div class="flex max-w-xs pt-5 mx-auto -mt-10 overflow-hidden drop-shadow-xs grayscale opacity-80">
    <img src="./img/icons/logo-footer.png" width="35" height="35" alt="bottom-logo" class="dark:opacity-70">
  </div>
  <div class="mt-5">
    <ul class="flex flex-wrap justify-between max-w-(--breakpoint-md) mx-auto text-sm font-navigation text-slate-400">
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">
          Privacy Policy
        </a>
      </li>
    </ul>
  </div>
</footer>

The dark:opacity-70 utility ensures the logo becomes slightly transparent in dark mode, creating a more cohesive look. These small tweaks make a big difference in user experience .

Step 5.2: Colored Drop Shadows

TailwindCSS 4.1.4 introduces colored drop shadows, which allow for more creative and visually appealing designs . I decided to experiment with this feature by adding a subtle shadow effect to my buttons. Instead of using a generic black shadow, I opted for a soft blue tint to match my brand colors.

Here’s an example:

<!-- Button with colored drop shadow -->
<button class="px-4 py-2 bg-blue-600 text-white rounded-lg shadow-[0_4px_6px_rgba(0,102,255,0.3)] hover:shadow-lg transition-shadow">
  Click Me
</button>

// Custom colored drop-shadow in tailwind.config.js (if needed)
/** @type {import('tailwindcss').Config} */
export default {
  theme: {
    extend: {
      boxShadow: {
        'colored-blue': '0 4px 6px rgba(0, 102, 255, 0.3)', // Custom blue shadow
      },
    },
  },
};

This small enhancement adds depth and personality to my buttons, making them stand out without being overwhelming .

Step 5.3: Masking Utilities

Another powerful addition in TailwindCSS 4.1.4 is the masking utilities. These allow you to clip elements into various shapes, such as circles, ellipses, or custom SVG paths . I used this feature to create a circular avatar image for my project’s author profile section.

Here’s how I implemented it:

<!-- Circular avatar using masking utilities -->
<div class="w-24 h-24 rounded-full overflow-hidden mask mask-circle">
  <img src="./img/author-avatar.jpg" alt="Author Avatar" class="object-cover w-full h-full">
</div>

The mask-circle utility clips the image into a perfect circle, while object-cover ensures the image scales proportionally within the container. This approach eliminates the need for custom CSS or additional libraries .

Step 5.4: Text Shadows

TailwindCSS 4.1.4 also introduces text shadows, which are perfect for adding emphasis to headings or important text . I applied this utility to my hero section title to make it pop against the background image.

Here’s an example:

<!-- Hero section with text shadow -->
<h1 class="text-4xl font-bold text-white text-shadow-[0_2px_4px_rgba(0,0,0,0.5)]">
  Welcome to My Project
</h1>

// Custom text-shadow in tailwind.config.js (if needed)
/** @type {import('tailwindcss').Config} */
export default {
  theme: {
    extend: {
      textShadow: {
        'custom': '0 2px 4px rgba(0, 0, 0, 0.5)', // Custom text shadow
      },
    },
  },
};

This subtle shadow effect ensures the text remains legible while adding a touch of elegance .

Step 5.5: Fine-Grained Text Wrapping

Finally, I explored the new fine-grained text wrapping utilities, which provide greater control over how text behaves in constrained spaces . For instance, I used the whitespace-break-spaces utility to ensure long words in my blog post excerpts wouldn’t overflow their containers.

Here’s how I applied it:

<!-- Blog excerpt with fine-grained text wrapping -->
<p class="text-sm text-gray-600 whitespace-break-spaces">
  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Thisisaverylongwordthatshouldbreakproperly.
</p>

This utility ensures readability, even when dealing with irregular text lengths .

By leveraging these new features, I was able to enhance both the functionality and aesthetics of my project. The improved dark mode utilities streamlined my theming process, while colored drop shadows and masking tools added creative flair. Text shadows and fine-grained text wrapping further refined the details, ensuring a polished final product.

With these updates in place, I’m thrilled with how much cleaner and modern my design feels. TailwindCSS 4.1.4 truly lives up to its reputation as a game-changer for developers .

7. Conclusion

Upgrading to TailwindCSS 4.1.4 has been a rewarding experience, and I’m thrilled with the results. From the initial preparation to addressing potential issues and finally leveraging the new features, this process not only modernized my project but also deepened my understanding of the framework. The improvements in performance, dark mode utilities, and creative tools like colored drop shadows and masking have already made a noticeable difference in my workflow .

Why This Upgrade Matters

TailwindCSS 4.1.4 isn’t just about shiny new features—it’s about empowering developers to build faster, cleaner, and more efficient projects. For instance, the enhanced text wrapping utilities and streamlined CSS-first configuration approach make it easier than ever to create responsive designs without writing custom CSS . These updates align perfectly with the evolving needs of modern web development, especially as we move into 2025 and beyond.

Key Takeaways

Here’s what I learned during this upgrade journey:

Preparation is Key: Creating a backup branch and reviewing dependencies ensured I had a safety net if anything went wrong.
Embrace Change: While some deprecated utilities required rework, the long-term benefits of adopting TailwindCSS 4.1.4 far outweigh the temporary effort.
Explore New Features: Experimenting with colored drop shadows, masking, and text shadows opened up creative possibilities I hadn’t considered before .

Looking Ahead

As I continue working on my project, I’m excited to see how these enhancements will scale with larger, more complex designs. The performance optimizations introduced in TailwindCSS 4.1.4, such as improved path exclusion during scanning, are particularly promising for large-scale projects . Additionally, the framework’s focus on developer experience ensures that even beginners can adopt it with minimal friction .

Final Thoughts

If you’re still on an older version of TailwindCSS, I highly recommend upgrading to 4.1.4. The official upgrade tool makes the process straightforward, and the benefits—ranging from better performance to innovative utilities—are well worth the effort. Plus, documenting your journey, as I’ve done here, can serve as a valuable resource for both yourself and others in the community.

To wrap things up, here’s a quick snippet of how I applied one of my favorite new features, the mask-circle utility, to my project:

<!-- Circular avatar using masking utilities -->
<div class="w-24 h-24 rounded-full overflow-hidden mask mask-circle">
  <img src="./img/author-avatar.jpg" alt="Author Avatar" class="object-cover w-full h-full">
</div>

This small change adds a polished, professional touch to my design while staying true to TailwindCSS’s utility-first philosophy. I hope this blog post inspires you to take the leap and upgrade your own projects. If you have questions or want to share your experiences, feel free to leave a comment—I’d love to hear from you!

From Tailwind CLI to Vite: A Developer’s Journey to Better Performance (2025 Edition)

gerry leo nugroho — Sun, 27 Apr 2025 14:50:30 +0000

leonism / all-things-digital

Experience the innovation of a mobile-first theme, harnessing the power of Vue, Vite, Markdown & Tailwind's cutting-edge technology (upgraded to 4.1.11) and complemented by Typography and various other indispensable plugins.

All Things Digital

A modern, sleek and responsive, TailwindCSS, Vue.js & Vite.js Based Theme

✅ Quick Deploy

🎥 Video

DGPond.COM.mp4

🎊 Descriptions

Elevate Your Digital Presence with All Things Digital

Introducing All Things Digital, a cutting-edge, minimalistic, and responsive multi-page layout theme, engineered for the modern web. Built atop the blazing-fast Vue.js framework, and powered by Vite.js for an unparalleled development experience, this theme is more than just a fresh coat of paint. It's a complete ecosystem designed for peak performance and effortless content management. We've embraced a mobile-first philosophy and integrated a stunning Dark Mode to ensure a comfortable and visually appealing experience for all your users, day or night.

Streamlined Content and Powerful Search

All Things Digital goes beyond aesthetics, offering a robust foundation for your content strategy. We've integrated Decap…

View on GitHub

1. Create a New Branch for Backup

Step 1.1: Open Your Terminal

I opened my terminal and navigated to the root directory of my project. If you’re using a Mac or Linux, you’ll use Bash, while Windows users can use the command prompt .

Step 1.2: Create the Backup Branch

To create a new branch named latest-vite-integration, I ran the following command:

git checkout -b latest-vite-integration

This command creates a new branch and switches to it in one step . It’s a quick and efficient way to ensure I have a safe starting point.

Step 1.3: Push the Branch to GitHub

After creating the branch locally, I pushed it to GitHub to back it up remotely:

git push origin latest-vite-integration

This step ensures that the branch is stored securely in the cloud, making it accessible from anywhere .

Why This Step Matters

2. Vite Best Practices in 2025

What is Vite?

Key Features of Vite

Hot Module Replacement (HMR):

One of Vite’s standout features is its HMR capability. When you edit a file, only the changed module is updated in the browser, without reloading the entire page. This makes development faster and more enjoyable .
Optimized Production Builds:

While Vite uses native ESM during development, it bundles your code into optimized assets for production. This ensures your site remains performant when deployed .
Seamless Integration with Modern Tools:

Vite works well with frameworks like React and libraries like TailwindCSS. It also supports TypeScript out of the box, making it future-proof for potential upgrades .
Minimal Configuration:

Vite is designed to require minimal setup. For most projects, the default configuration is sufficient, but it’s also highly customizable if needed .

How Vite Differs from My Current Setup

Currently, I’m using the Tailwind CLI with NPM scripts to process my CSS. While this setup works, it lacks the speed and modularity that Vite offers. Here’s a comparison:

Feature	Current Setup (Tailwind CLI + NPM Scripts)	Vite
Development Server	No built-in server	Built-in, fast, and feature-rich
Hot Module Replacement (HMR)	Manual refresh required	Instant updates without full reload
Production Optimization	Manual minification	Automatic optimization and bundling
Modularity	Limited	Encourages modular components via ES modules

Folder Structure Recommendations

Vite encourages a modular folder structure to keep your project organized. Based on my research, here’s how I plan to restructure my project:

src/
├── components/
│   ├── header.html
│   ├── footer.html
│   └── content.html
├── layout/
│   └── base.html
├── main.css
└── index.html

Resources I Found Helpful

The Vite documentation provided clear guidance on setting up and configuring the tool .
Articles like “Why Vite is the best?” highlighted its advanced features, such as seamless form handling and built-in state management .
Comparisons between Vite and traditional build tools like Webpack helped me understand its advantages in terms of speed and ease of use .

Why This Step Matters

3. Install Vite and Set Up the Development Environment

Step 3.1: Install Vite & Autoprefixer

To integrate Vite into my project, I started by installing it as a development dependency. In my terminal, I ran the following command:

npm install vite --save-dev

This command added Vite to my devDependencies in package.json, making it available for use during development .

Though my current project setup with comes with a Tailwind CSS CLI already included, but there is one more dependencies that Vite may need additionally, the autoprefixer library.

npm install -D autoprefixer --save-dev

By invoking the previous command in your terminal, it would add "autoprefixer": "^10.4.21", to my package.json at the same time.

Step 3.2: Add a Vite Configuration File

Next, I created a vite.config.mjs file in the root directory of my project. This file allows me to customize Vite’s behavior while keeping things simple. Here’s the configuration I used:

// Import required modules for Vite configuration
import { defineConfig } from 'vite';
import tailwindcss from '@tailwindcss/postcss';
import autoprefixer from 'autoprefixer';

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [
        // Add Tailwind CSS as a PostCSS plugin
        tailwindcss(),
        // Add Autoprefixer for vendor prefixing
        autoprefixer()
      ]
    }
  }
});

Why This Configuration?

The root option specifies that Vite should look for my source files in the src folder.
The build.outDir option ensures that production builds are placed in the dist folder, matching my current workflow.
The css.postcss option integrates my existing PostCSS setup, ensuring TailwindCSS continues to work without issues .

"scripts": {
        "dev": "vite", // Start the Vite development server
        "build": "vite build", // Build for production
        "preview": "vite preview", // Preview the production build locally
        "watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch",
        "compress": "npx tailwindcss -i ./src/main.css -o ./dist/style.css --minify",
        "start": "live-server ./dist"
    }

Step 3.3: Update NPM Scripts

To make Vite part of my workflow, I updated the scripts section in my package.json. Here’s what I changed:

What Do These Scripts Do?

npm run dev: Starts the Vite development server, enabling hot module replacement (HMR) for a faster development experience.
npm run build: Creates an optimized production build in the dist folder.
npm run preview: Lets me preview the production build locally before deploying it.
npm run watch: Keeps my existing TailwindCSS workflow intact by watching for changes and rebuilding styles as needed .

4. Update Folder Structure for Modularity Using `vite-plugin-ejs`

Step 4.1: Install `vite-plugin-ejs`

The first step was to install the vite-plugin-ejs plugin as a development dependency. In my terminal, I ran the following command:

npm install vite-plugin-ejs --save-dev

This added the plugin to my devDependencies in package.json, making it available for use in my Vite configuration .

Step 4.2: Update `vite.config.js`

Next, I updated my vite.config.js file to include the vite-plugin-ejs plugin. Here’s the updated configuration:

// Import required modules for Vite configuration
import { defineConfig } from 'vite'
import tailwindcss from 'tailwindcss'
import autoprefixer from 'autoprefixer'
import imagemin from 'vite-plugin-imagemin'
import htmlMinifier from 'vite-plugin-html-minifier'
import { ViteEjsPlugin } from 'vite-plugin-ejs'
import { resolve } from 'path'

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 * - Images, HTML, CSS, and JavaScript compressions using Vite plugins
 * - EJS templating for HTML modularity
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/index.html'),
        about: resolve(__dirname, 'src/about.html'),
        contact: resolve(__dirname, 'src/contact.html'),
        blog: resolve(__dirname, 'src/blog.html'),
        category: resolve(__dirname, 'src/category.html'),
      },
    },
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [tailwindcss, autoprefixer],
    },
  },

  // Plugins configuration
  plugins: [
    // Image minification
    imagemin({
      pngquant: {
        quality: [0.7, 0.9],
        speed: 4,
      },
    }),
    // HTML minification
    htmlMinifier({
      minify: true,
      collapseWhitespace: true,
      keepClosingSlash: true,
      removeComments: true,
      removeRedundantAttributes: true,
      removeScriptTypeAttributes: true,
      removeStyleLinkTypeAttributes: true,
      useShortDoctype: true,
    }),
    // EJS templating for HTML
    ViteEjsPlugin(),
  ],

  server: {
    watch: {
      usePolling: true,
    },
  },
})

Why Use `vite-plugin-ejs`?

This plugin enables me to use EJS templates in my HTML files, allowing me to modularize my code into reusable components like header.html, navigation.html, and more .

Step 4.3: Restructure the Folder and File Structure

To modularize my code, I reorganized my project folder structure. Here’s the updated structure:

src/
├── components/
│   ├── Footer.html
│   ├── Header.html
│   ├── Navigation.html
│   ├── nav-desktop.html
│   └── nav-mobile.html
├── layouts/
│   └── base.html
├── content/
│   └── content-about.html
│   └── content-blog-grid.html
│   └── content-blog.html
│   └── content-category.html
│   └── content-home.html
├── main.css
└── index.html

What Changed?

I moved all reusable components (e.g., header, footer) into the components folder.
I created a layouts folder to house the base.html layout file, which serves as the template for assembling components.
I renamed index.html to index.html to leverage EJS templating .

Step 4.4: Modularize the Code

Base Layout (`base.html`)

The base.html file acts as the skeleton of my HTML structure. It includes placeholders for injecting components like header, navigation, content, and footer. Here’s the full code:

<!DOCTYPE html>
<html lang="en">
  <%- include('components/Header.html') %>
  <body class="antialiased bg-white dark:bg-main scroll-smooth">
    <%- include('components/Navigation.html') %>
    <%- include(typeof content !== 'undefined' ? content : 'content/content-home.html') %>
    <%- include('components/Footer.html') %>
    <script type="module" src="./js/app.js"></script>
    <script type="module" src="./js/script.js"></script>
  </body>
</html>

How Does It Work?

The <%- include(...) %> syntax dynamically injects the specified EJS component into the layout. This approach keeps the code modular and reusable .

Header Component (`header.html`)

<head>
  <link rel="manifest" href="./manifest.json">
  <meta name="msapplication-TileColor" content="#ffffff">
  <meta name="msapplication-TileImage" content="./ms-icon-144x144.png">
  <meta name="theme-color" content="#ffffff">
  <link rel="shortcut icon" href="./favicon.ico" type="image/x-icon">
  <link rel="stylesheet" href="./main.css">
  <title></title>
</head>

The header.html file contains the HTML for the site’s header. Here’s the full code:

Navigation Component (`navigation.html`)

The navigation.html file contains the site’s navigation menu. Here’s the full code:

<!-- start the logo, desktop-nav, darkmode button, contact button, nav-icon & mobile-nav  -->
<header id="wrapperNavBar"
  class="sticky top-0 z-10 bg-white p-[25px] drop-shadow-xl blurGrad backdrop-blur-lg dark:bg-main dark:drop-shadow-2xl dark:border-b dark:border-slate-900/20">
  <div id="NavBar" class="flex justify-between max-w-4xl mx-auto">
    <!-- start the logo -->
    <div id="logo" class="z-40 drop-shadow-md">
      <a href="index.html">
        <img src="./img/icons/icon-dgpondcom.png" alt="Logo" id="DGPond" class="w-auto h-auto max-w-full">
      </a>
    </div>
    <%- include('components/nav-desktop.html') %>
    <%- include('components/nav-mobile.html') %>
  </div>
</header>

Footer Component (`footer.html`)

The footer.html file contains the site’s footer. Here’s the full code:

<!-- start the footer section -->
<footer class="flex flex-col items-center max-w-3xl mx-auto my-10 border-t dark:border-slate-800/60">
  <div class="flex max-w-xs pt-5 mx-auto -mt-10 overflow-hidden drop-shadow-sm grayscale opacity-80">
    <img src="./img/icons/logo-footer.png" width="35" height="35" alt="bottom-logo" class="">
  </div>
  <div class="mt-5">
    <ul class="flex flex-wrap justify-between max-w-screen-md mx-auto text-sm font-navigation text-slate-400">
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">
          Home
        </a>
      </li>
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">
          About
        </a>
      </li>
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">
          Blog
        </a>
      </li>
      <li class="mx-2">
        <a class="text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:text-gray-300 dark:hover:text-white"
          href="#">
          Credits
        </a>
      </li>
    </ul>
  </div>
  <div class="flex items-center justify-between max-w-xs pt-8 mx-auto">
    <a href="#" class="ml-4 text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:hover:text-white">
      <svg width="20" height="20" fill="currentColor"
        class="text-xl transition-colors duration-200 hover:text-gray-800 dark:hover:text-white" viewBox="0 0 1792 1792"
        xmlns="http://www.w3.org/2000/svg">
        <path
          d="M1684 408q-67 98-162 167 1 14 1 42 0 130-38 259.5t-115.5 248.5-184.5 210.5-258 146-323 54.5q-271 0-496-145 35 4 78 4 225 0 401-138-105-2-188-64.5t-114-159.5q33 5 61 5 43 0 85-11-112-23-185.5-111.5t-73.5-205.5v-4q68 38 146 41-66-44-105-115t-39-154q0-88 44-163 121 149 294.5 238.5t371.5 99.5q-8-38-8-74 0-134 94.5-228.5t228.5-94.5q140 0 236 102 109-21 205-78-37 115-142 178 93-10 186-50z">
        </path>
      </svg>
    </a>
    <a href="#" class="ml-4 text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:hover:text-white">
      <svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" fill="currentColor"
        class="text-xl transition-colors duration-200 hover:text-gray-800 dark:hover:text-white"
        viewBox="0 0 1792 1792">
        <path
          d="M896 128q209 0 385.5 103t279.5 279.5 103 385.5q0 251-146.5 451.5t-378.5 277.5q-27 5-40-7t-13-30q0-3 .5-76.5t.5-134.5q0-97-52-142 57-6 102.5-18t94-39 81-66.5 53-105 20.5-150.5q0-119-79-206 37-91-8-204-28-9-81 11t-92 44l-38 24q-93-26-192-26t-192 26q-16-11-42.5-27t-83.5-38.5-85-13.5q-45 113-8 204-79 87-79 206 0 85 20.5 150t52.5 105 80.5 67 94 39 102.5 18q-39 36-49 103-21 10-45 15t-57 5-65.5-21.5-55.5-62.5q-19-32-48.5-52t-49.5-24l-20-3q-21 0-29 4.5t-5 11.5 9 14 13 12l7 5q22 10 43.5 38t31.5 51l10 23q13 38 44 61.5t67 30 69.5 7 55.5-3.5l23-4q0 38 .5 88.5t.5 54.5q0 18-13 30t-40 7q-232-77-378.5-277.5t-146.5-451.5q0-209 103-385.5t279.5-279.5 385.5-103zm-477 1103q3-7-7-12-10-3-13 2-3 7 7 12 9 6 13-2zm31 34q7-5-2-16-10-9-16-3-7 5 2 16 10 10 16 3zm30 45q9-7 0-19-8-13-17-6-9 5 0 18t17 7zm42 42q8-8-4-19-12-12-20-3-9 8 4 19 12 12 20 3zm57 25q3-11-13-16-15-4-19 7t13 15q15 6 19-6zm63 5q0-13-17-11-16 0-16 11 0 13 17 11 16 0 16-11zm58-10q-2-11-18-9-16 3-14 15t18 8 14-14z">
        </path>
      </svg>
    </a>
    <a href="#" class="ml-4 text-gray-400 transition-colors duration-200 hover:text-gray-800 dark:hover:text-white">
      <svg width="20" height="20" fill="currentColor"
        class="text-xl transition-colors duration-200 hover:text-gray-800 dark:hover:text-white" viewBox="0 0 1792 1792"
        xmlns="http://www.w3.org/2000/svg">
        <path
          d="M477 625v991h-330v-991h330zm21-306q1 73-50.5 122t-135.5 49h-2q-82 0-132-49t-50-122q0-74 51.5-122.5t134.5-48.5 133 48.5 51 122.5zm1166 729v568h-329v-530q0-105-40.5-164.5t-126.5-59.5q-63 0-105.5 34.5t-63.5 85.5q-11 30-11 81v553h-329q2-399 2-647t-1-296l-1-48h329v144h-2q20-32 41-56t56.5-52 87-43.5 114.5-15.5q171 0 275 113.5t104 332.5z">
        </path>
      </svg>
    </a>
  </div>
</footer>

Main Entry Point (`index.html`)

Finally, the index.html file serves as the entry point for the application. It simply includes the base.html layout:

<!-- src/index.html -->
<%- include('layouts/base.html') %>

Step 4.5: Test the Setup

After modularizing the code, I tested the setup by running the development server:

npm run dev

Vite launched the server at http://localhost:5173, and I verified that:

The Tailwind styles were applied correctly.
All components rendered as expected.
Hot module replacement (HMR) worked when editing files .

What Have We Achieved So Far?

5. Update NPM Scripts

Step 5.1: Analyze My Current Scripts

Before making changes, I reviewed my existing scripts section in package.json. Here’s what I had:

"scripts": {
  "dev": "tailwindcss -i ./src/main.css -o ./dist/style.css",
  "build": "tailwindcss -i ./src/main.css -o ./dist/style.css",
  "watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch",
  "compress": "npx tailwindcss -o ./dist/style.css --minify",
  "start": "live-server ./dist"
}

Step 5.2: Update Scripts for Vite

I updated my scripts section to incorporate Vite’s commands while keeping some of my existing workflows intact. Here’s the revised version:

"scripts": {
  "dev": "vite", // Start the Vite development server with hot module replacement (HMR)
  "build": "vite build", // Build the project for production
  "preview": "vite preview", // Preview the production build locally
  "tailwind:watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch", // Watch and rebuild Tailwind styles during development
  "start": "npm run dev" // Alias for starting the development server
}

What Do These Scripts Do?

npm run dev: Starts the Vite development server, enabling HMR for a faster and more interactive development experience .
npm run build: Creates an optimized production build in the dist folder, ready for deployment.
npm run preview: Allows me to preview the production build locally before deploying it. This is particularly useful for testing performance and functionality .
npm run tailwind:watch: Keeps my existing TailwindCSS workflow intact by watching for changes and rebuilding styles as needed.
npm run start: Acts as a convenient alias for starting the development server.

Step 5.3: Test the Updated Scripts

To ensure everything worked as expected, I tested each script:

Start the Development Server

I ran the following command:
```
npm run dev
```
Vite launched the development server at http://localhost:5173, and my modular components rendered perfectly. Hot module replacement (HMR) worked seamlessly, updating the browser instantly when I made changes .
Build for Production

Next, I built the project for production:
```
npm run build
```
Vite generated an optimized build in the dist folder. The output included minified CSS and JavaScript files, ensuring high performance .
Preview the Production Build

To verify the production build, I ran:
```
npm run preview
```
Vite served the production build locally, allowing me to test its functionality and performance before deploying it.
Watch Tailwind Styles

Finally, I tested the tailwind:watch script:
```
npm run tailwind:watch
```
This ensured that my Tailwind styles were rebuilt automatically whenever I made changes to my CSS or HTML files .

Why This Step Matters

6. Adjust TailwindCSS Setup

Step 6.1: Update `tailwind.config.mjs`

The first thing I did was update the content property in my tailwind.config.js file. Since I had modularized my HTML into .html files, I needed to ensure Tailwind scanned these files for class names .

Here’s the updated configuration:

const colors = require("tailwindcss/colors");

/** @type {import('tailwindcss').Config} */
module.exports = {
  // Scan for Tailwind classes in .html files
  content: [
    "./src/**/*.{html,ejs,js,ts}", // Include all HTML, EJS, and JS files in the src folder
  ],
  darkMode: "class",
  theme: {
    screens: {
      sm: "480px",
      md: "768px",
      lg: "976px",
      xl: "1440px",
    },
    extend: {
      animation: {
        blob: "blob 7s infinite",
      },
      colors: {
        savoryWhite: "hsl(0, 36%, 95%)",
        mutedWhite: "hsl(224, 16%, 54%)",
        whiteHover: "hsl(0, 36%, 95%)",
        pinkHeading: "hsl(279, 48%, 54%)",
        pinkSubHeading: "hsl(293, 43%, 55%)",
        blackSubHeading: "hsl(221, 39%, 11%)",
        deepBlueSubHeading: "hsl(229, 38%, 40%)",
        fuchsia: colors.fuchsia,
      },
      keyframes: {
        blob: {
          "0%": {
            transform: "translate(0px, 0px) scale(1)",
          },
          "33%": {
            transform: "translate(30px, -50px) scale(1.1)",
          },
          "66%": {
            transform: "translate(-20px, 20px) scale(0.9)",
          },
          "100%": {
            transform: "translate(0px, 0px) scale(1)",
          },
        },
      },
      backgroundColor: {
        main: "hsl(215, 45%, 14%)",
      },
    },
    fontFamily: {
      navigation: ["Poppins", "sans-serif"],
    },
  },
  plugins: [
    require("@tailwindcss/typography"),
    require("@tailwindcss/forms"),
    require("@tailwindcss/line-clamp"),
  ],
};

Why This Change?

Step 6.2: Optimize TailwindCSS Workflow

"scripts": {
  "dev": "vite",
  "build": "vite build",
  "preview": "vite preview",
  "tailwind:watch": "tailwindcss -i ./src/main.css -o ./dist/style.css --watch", // Watch and rebuild Tailwind styles
  "start": "npm run dev"
}

This ensures that my styles are always up-to-date, even when working with modular both .html & .ejs files.

Step 6.3: Test the TailwindCSS Integration

To verify that TailwindCSS was working correctly, I performed the following tests:

Development Environment

I ran the tailwind:watch script alongside the Vite development server:
```
npm run tailwind:watch & npm run dev
```
This allowed me to see real-time updates to my styles as I edited my .html components .
Production Build

Next, I built the project for production:
```
npm run build
```
Vite generated an optimized build in the dist folder, including minified CSS and JavaScript files. I verified that all Tailwind classes were included and applied correctly .
Preview the Production Build

Finally, I previewed the production build locally:
```
npm run preview
```
The site rendered perfectly, with all styles intact and no missing classes.

Why This Step Matters

For further reading on integrating TailwindCSS with Vite, I recommend checking out this GitHub repository .

7. Test the Development Workflow

Step 7.1: Start the Development Server

I began by starting the Vite development server using the dev script:

npm run dev

What Did I Test?

HTML Components: I verified that all modular components (header.html, navigation.html, content.html, and footer.html) were rendered correctly within the base.html layout.
Tailwind Styles: I checked that all Tailwind classes were applied as expected, ensuring no styles were missing or broken.
Dynamic Updates: I edited one of my .html files (e.g., header.html) and confirmed that the changes appeared immediately in the browser without requiring a full reload .

Step 7.2: Test TailwindCSS Watch Mode

To ensure my styles were always up-to-date during development, I ran the tailwind:watch script alongside the Vite server:

npm run tailwind:watch & npm run dev

Step 7.3: Build for Production

Next, I tested the production build process by running:

npm run build

Vite generated an optimized build in the dist folder, including minified CSS and JavaScript files. To verify the output, I inspected the dist folder and confirmed that:

All .html components were compiled into static HTML files.
TailwindCSS purged unused styles, resulting in a smaller CSS file size .
The production build included all necessary assets (e.g., images, fonts).

Here’s an example of the optimized index.html file generated in the dist folder:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>All Things Digital</title>
  <link rel="stylesheet" href="/style.css">
</head>
<body>
  <!-- Header Component -->
  <header class="bg-savoryWhite text-blackSubHeading py-4">
    <div class="container mx-auto flex justify-between items-center">
      <h1 class="text-pinkHeading font-bold text-2xl">All Things Digital</h1>
      <button id="menu-toggle" class="hamburger">
        <span class="hamburger-top"></span>
        <span class="hamburger-middle"></span>
        <span class="hamburger-bottom"></span>
      </button>
    </div>
  </header>

  <!-- Navigation Component -->
  <nav class="hidden md:flex space-x-6 text-mutedWhite">
    <a href="/" class="hover:text-whiteHover">Home</a>
    <a href="/about.html" class="hover:text-whiteHover">About</a>
    <a href="/blog.html" class="hover:text-whiteHover">Blog</a>
    <a href="/contact.html" class="hover:text-whiteHover">Contact</a>
  </nav>

  <!-- Content Component -->
  <main>
    <section class="py-8">
      <div class="container mx-auto">
        <h2 class="text-pinkSubHeading text-3xl font-bold mb-4">Welcome to All Things Digital</h2>
        <p class="text-mutedWhite">
          Explore the latest trends, tips, and insights in the digital world.
        </p>
      </div>
    </section>
  </main>

  <!-- Footer Component -->
  <footer class="bg-main text-white py-6">
    <div class="container mx-auto text-center">
      <p>&copy; 2025 All Things Digital. All rights reserved.</p>
    </div>
  </footer>
</body>
</html>

Why Is This Important?

The production build ensures that my site is optimized for performance, with minimal file sizes and no unnecessary code. This is critical for delivering a fast and responsive user experience .

Step 7.4: Preview the Production Build

To test the production build locally, I ran:

npm run preview

Vite served the production build at http://localhost:4173, allowing me to verify its functionality and performance. I performed the following checks:

Rendering: Ensured all components and styles rendered correctly.
Performance: Verified that the site loaded quickly, thanks to Vite’s optimized build process.
Responsiveness: Tested the site on different screen sizes to confirm that Tailwind’s responsive utilities worked as expected .

Step 7.5: Document Observations

Throughout the testing process, I documented my observations and added comments to relevant files. For example, here’s a comment I added to my vite.config.js file:

// Import required modules for Vite configuration
import { defineConfig } from 'vite'
import tailwindcss from 'tailwindcss'
import autoprefixer from 'autoprefixer'
import imagemin from 'vite-plugin-imagemin'
import htmlMinifier from 'vite-plugin-html-minifier'
import { ViteEjsPlugin } from 'vite-plugin-ejs'
import { resolve } from 'path'

/**
 * Vite configuration for the project.
 *
 * This config sets up:
 * - Project root directory
 * - Build output settings
 * - PostCSS plugins (Tailwind CSS and Autoprefixer)
 * - Images, HTML, CSS, and JavaScript compressions using Vite plugins
 * - EJS templating for HTML modularity
 */
export default defineConfig({
  // Set the project root directory to './src'
  root: './src',

  // Build configuration
  build: {
    // Output directory for built files (relative to project root)
    outDir: '../dist',
    // Clear the output directory before each build
    emptyOutDir: true,
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/index.html'),
        about: resolve(__dirname, 'src/about.html'),
        contact: resolve(__dirname, 'src/contact.html'),
        blog: resolve(__dirname, 'src/blog.html'),
        category: resolve(__dirname, 'src/category.html'),
      },
    },
  },

  // CSS processing configuration
  css: {
    // PostCSS configuration
    postcss: {
      plugins: [tailwindcss, autoprefixer],
    },
  },

  // Plugins configuration
  plugins: [
    // Image minification
    imagemin({
      pngquant: {
        quality: [0.7, 0.9],
        speed: 4,
      },
    }),
    // HTML minification
    htmlMinifier({
      minify: true,
      collapseWhitespace: true,
      keepClosingSlash: true,
      removeComments: true,
      removeRedundantAttributes: true,
      removeScriptTypeAttributes: true,
      removeStyleLinkTypeAttributes: true,
      useShortDoctype: true,
    }),
    // EJS templating for HTML
    ViteEjsPlugin(),
  ],

  server: {
    watch: {
      usePolling: true,
    },
  },
})

Why Add Comments?

Comments make the code easier to understand for future me—or anyone else who might work on the project. They also serve as a reminder of why certain decisions were made .

Why This Step Matters

8. Build for Production

Step 8.1: Run the Production Build Command

I started by running the build script, which generates an optimized production build in the dist folder:

npm run build

Vite processed my modular .html & .ejs components, TailwindCSS styles, and JavaScript files, bundling them into a clean and efficient structure . The output included:

Minified CSS and JavaScript files.
Static HTML files compiled from my .html & .ejs templates.
All necessary assets (e.g., images, fonts) copied to the dist folder.

Here’s an example of the optimized index.html file generated in the dist folder:

<!-- dist/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>All Things Digital</title>
  <link rel="stylesheet" href="/style.css">
</head>
<body>
  <!-- Header Component -->
  <header class="bg-savoryWhite text-blackSubHeading py-4">
    <div class="container mx-auto flex justify-between items-center">
      <h1 class="text-pinkHeading font-bold text-2xl">All Things Digital</h1>
      <button id="menu-toggle" class="hamburger">
        <span class="hamburger-top"></span>
        <span class="hamburger-middle"></span>
        <span class="hamburger-bottom"></span>
      </button>
    </div>
  </header>

  <!-- Navigation Component -->
  <nav class="hidden md:flex space-x-6 text-mutedWhite">
    <a href="/" class="hover:text-whiteHover">Home</a>
    <a href="/about.html" class="hover:text-whiteHover">About</a>
    <a href="/blog.html" class="hover:text-whiteHover">Blog</a>
    <a href="/contact.html" class="hover:text-whiteHover">Contact</a>
  </nav>

  <!-- Content Component -->
  <main>
    <section class="py-8">
      <div class="container mx-auto">
        <h2 class="text-pinkSubHeading text-3xl font-bold mb-4">Welcome to All Things Digital</h2>
        <p class="text-mutedWhite">
          Explore the latest trends, tips, and insights in the digital world.
        </p>
      </div>
    </section>
  </main>

  <!-- Footer Component -->
  <footer class="bg-main text-white py-6">
    <div class="container mx-auto text-center">
      <p>&copy; 2025 All Things Digital. All rights reserved.</p>
    </div>
  </footer>
</body>
</html>

Why Is This Important?

The production build ensures that my site is ready for deployment, with all assets optimized for speed and efficiency. This is critical for delivering a fast and responsive user experience .

Step 8.2: Inspect the Output Folder

After the build process completed, I inspected the dist folder to verify its contents:

CSS: The style.css file was minified, ensuring faster load times.
HTML: My modular .html components were compiled into static HTML files, making them easy to serve.
Assets: Images, fonts, and other assets were copied to the dist folder, ensuring they were available for use.

Here’s a snapshot of the dist folder structure:

dist/
├── assets/
├── index.html
├── about.html
├── blog.html
├── style.css
└── script.js

What Did I Learn?

Inspecting the dist folder gave me confidence that everything was in place for deployment. Vite’s build process handled all optimizations automatically, saving me time and effort .

Step 8.3: Preview the Production Build

To test the production build locally, I ran the preview script:

npm run preview

Vite served the production build at http://localhost:4173, allowing me to verify its functionality and performance . I performed the following checks:

Rendering: Ensured all components and styles rendered correctly.
Performance: Verified that the site loaded quickly, thanks to Vite’s optimized build process.
Responsiveness: Tested the site on different screen sizes to confirm that Tailwind’s responsive utilities worked as expected.

Why Use the `preview` Script?

The preview script lets me test the production build locally before deploying it, reducing the risk of errors or broken functionality in the live environment .

Step 8.4: Add Comments to Key Files

To make my production setup easier to understand, I added comments to key files like vite.config.js and tailwind.config.js. For example, here’s a comment I added to my vite.config.js file:

// Vite configuration for All Things Digital
import { defineConfig } from 'vite';
import postcss from './postcss.config.js'; // Reuse my existing PostCSS setup
import ejs from 'vite-plugin-ejs';

export default defineConfig({
  root: './src', // Set the root directory for my source files
  plugins: [ejs()], // Add the EJS plugin for modular components
  build: {
    outDir: '../dist', // Output directory for production builds
    emptyOutDir: true, // Clear the output directory before building
  },
  css: {
    postcss, // Use my existing PostCSS setup
  },
});

Why Add Comments?

Comments make the code easier to understand for future me—or anyone else who might work on the project. They also serve as a reminder of why certain decisions were made .

Step 8.5: Prepare for Deployment

Why This Step Matters

For further reading on optimizing production builds, I recommend checking out this guide on Tyk Self-Managed .

Lessons Learnt

Integrating Vite into my project has been a transformative experience, streamlining my workflow and enhancing both development and production processes. By modularizing my code and leveraging tools like vite-plugin-ejs, I’ve created a scalable, maintainable, and efficient setup that aligns with modern best practices. This journey not only improved my site’s performance but also deepened my understanding of how cutting-edge tools like Vite can elevate web development.

DEV Community: gerry leo nugroho

No More Messy Code: How to Master HTML, CSS, and JS Linting in VS Code Like a Pro

1. Let’s face it: bugs aren’t always born from bad logic.

1.1 What is Linting?

1.2 Why It Matters in Front-End Development

1.3 How Linting Works in VS Code

1.4 A Quick Real-Life Example

2. Real Scenario: A Team Working on a Marketing Landing Page

2.1 The Challenge: A Disjointed Development Effort

2.2 The Solution: Implementing Linting Tools in VS Code

2.3 The Outcome: A Cohesive and Efficient Development Process

3. Setting Up Your Environment

3.1 Essential VS Code Extensions

3.2 Installation Steps

3.3 Configuring Each Tool

3.3.1 HTMLHint

3.3.2 Stylelint

3.3.3 ESLint

3.3.4 Prettier

3.3.5 EditorConfig

3.4 Enabling Format on Save

3.5 Integrating Linting with Version Control

4. Configuring Each Linter from Scratch

4.1 HTMLHint – Enforcing HTML Best Practices

4.2 Stylelint – Maintaining Consistent CSS

4.3 ESLint – Ensuring JavaScript Code Quality

4.4 Prettier – Automated Code Formatting

4.5 Integrating with VS Code:

5. Integrating Linting into Your Workflow

5.1 Automate Linting with npm Scripts

5.2 Enable Format on Save in VS Code

5.3 Implement Pre-Commit Hooks with Husky and lint-staged

4. Integrate Linting into Continuous Integration (CI) Pipelines

5. Customize VS Code Settings for Enhanced Linting

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #5)

Navigation: Guiding Users with Style

src/components/DesktopMenu.tsx – Horizontal Menu with Dropdowns

Why It’s Awesome

src/components/MobileMenu.tsx – Off-Canvas with Animations

src/components/Breadcrumbs.tsx – SEO-Friendly Navigation

Usage Example

Why It Shines

src/components/Pagination.tsx – Dynamic Pagination

Usage Example

Why It’s Great

Cards & Grids: Visual Storytelling

src/components/PostCard.tsx – Enhanced from Last Section

What’s New?

src/components/CategoryCard.tsx – Category Highlights

Usage Example

Why It Pops

src/components/AuthorCard.tsx – Author Spotlight

Why It Works

Interactive Elements: Engaging Users

src/components/HoverImage.tsx – Image with Zoom

Why It’s Engaging

src/components/Tooltip.tsx – Contextual Info

Usage Example

Why It’s Handy

To Be Continued

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #4)

Step 1: App Shell, The Blog’s Structural Backbone

- BlurNavbar: A Stunning, Scroll-Aware Navbar with Blur Effect

Why It’s Awesome

- Footer: A Multi-Column Masterpiece

Highlights

- Layout: The Universal Wrapper

Key Features

- Container: Responsive Content Wrapper

Why It Works

- SkipNav: Accessibility First

Accessibility Win

Step 2: Tying It Together

TLDR, Core Layout Components

Creating Blog Tutorial Using Next.JS 15 & TailwindCSS 4.0 (Part #3)

Step 1: Why Structure Matters

Step 2: The Full Project Folder Structure

Step 3: Diving Into Each Directory

3.1: src/app/ – The Heart of Our Pages

3.2 src/components/ – Reusable Building Blocks

`src/components/DesktopMenu.tsx` – Horizontal Menu with Dropdowns

`src/components/MobileMenu.tsx` – Off-Canvas with Animations

`src/components/Breadcrumbs.tsx` – SEO-Friendly Navigation

`src/components/Pagination.tsx` – Dynamic Pagination

`src/components/PostCard.tsx` – Enhanced from Last Section

`src/components/CategoryCard.tsx` – Category Highlights

`src/components/AuthorCard.tsx` – Author Spotlight

`src/components/HoverImage.tsx` – Image with Zoom

`src/components/Tooltip.tsx` – Contextual Info

- `BlurNavbar`: A Stunning, Scroll-Aware Navbar with Blur Effect

3.1: `src/app/` – The Heart of Our Pages

3.2 `src/components/` – Reusable Building Blocks

3.3 `src/content/` – Where Blog Posts Live

3.4 `src/lib/` – Utility Functions for Logic

3.5 `src/styles/` – Styling Headquarters

3.6 `public/` – Static Assets Depot

Step 1: Next.js Configuration with `next.config.ts`

Step 2: PostCSS Configuration with `postcss.config.mjs`