DEV Community: Enjoy Kumawat

The Real Reason Everyone's Fighting About Tailwind CSS v4

Enjoy Kumawat — Sun, 21 Jun 2026 09:36:34 +0000

The Tailwind CSS4 debate is everywhere right now. And honestly? Most people are arguing about the wrong thing.

The real question isn't "inline styles vs. utility classes" — it's about where your styling decisions live and who pays the cognitive cost.

Let me break down what's actually happening, with real code, real trade-offs, and a clear take at the end.

What Changed in Tailwind CSS v4

Tailwind CSS v4 introduced a major shift: CSS-first configuration. Instead of a tailwind.config.js, you define everything in your CSS file using @theme:

/* Before (v3) - tailwind.config.js */
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: '#6366f1',
      },
      spacing: {
        18: '4.5rem',
      }
    }
  }
}

/* After (v4) - main.css */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
  --spacing-18: 4.5rem;
}

This is cleaner for many workflows. But it's not what's causing the drama.

The Real Flashpoint: Utility Density in JSX

What's actually triggering the discourse is how v4 accelerates a pattern that was already polarizing — components that look like this:

// The "inline styles but make it Tailwind" pattern
function AlertBanner({ type, message }) {
  return (
    <div className={`
      flex items-center gap-3 px-4 py-3 rounded-lg border
      ${type === 'error' 
        ? 'bg-red-50 border-red-200 text-red-800' 
        : 'bg-blue-50 border-blue-200 text-blue-800'}
    `}>
      <span className="text-sm font-medium">{message}</span>
    </div>
  );
}

vs. the @apply approach many teams prefer:

/* alert.css */
.alert {
  @apply flex items-center gap-3 px-4 py-3 rounded-lg border;
}
.alert--error {
  @apply bg-red-50 border-red-200 text-red-800;
}
.alert--info {
  @apply bg-blue-50 border-blue-200 text-blue-800;
}

// Cleaner component
function AlertBanner({ type, message }) {
  return (
    <div className={`alert alert--${type}`}>
      <span className="text-sm font-medium">{message}</span>
    </div>
  );
}

Both work. Neither is objectively wrong. But they encode very different philosophies.

The Philosophical Split (This Is the Real Debate)

Camp A: Co-location is king.
Styling logic belongs next to component logic. When you read the JSX, you see exactly how it looks. No context switching between files. No dead CSS accumulating over time. Deleting a component deletes its styles. This is why Tailwind exists.

Camp B: Semantic names have value.
alert--error tells you what something is. bg-red-50 border-red-200 text-red-800 tells you how it looks right now. When a designer changes your error color to orange, Camp A needs to hunt through JSX. Camp B changes one CSS rule.

Tailwind v4 doesn't resolve this tension — it sharpens it, because the new config system makes it even easier to stay in CSS-land, which makes @apply feel more natural, which reignites the debate.

The Scalability Question

Here's my honest take after working with both approaches on teams of different sizes:

Tailwind utility classes scale better on small-to-medium teams where everyone touches everything. Co-location wins because there's no coordination cost — you're not hunting for the right CSS class name someone else wrote three months ago.

@apply / semantic classes scale better on larger teams with clear design system ownership. When a dedicated design-systems team owns the CSS layer, semantic class names become a stable API. Components consume that API and don't care about the implementation.

The mistake is treating this as a universal answer. It's an organizational question dressed up as a technical one.

What I'd Actually Recommend

For solo projects or small teams: Go full utility classes. Embrace the v4 improvements. The productivity gain is real.
For component libraries you publish: Use @apply or CSS custom properties. Your consumers shouldn't need to know your design tokens.
For large apps with a design system team: Hybrid. Design system owns semantic classes. Application layer uses utilities for one-off layouts.
Don't @apply to avoid reading utility classes. That's not a scalability pattern, it's avoidance. Learn the utilities; they're worth the initial friction.

The Hot Take

The people most loudly against Tailwind utility classes are usually fighting their tooling, not Tailwind itself. If your editor doesn't have Tailwind IntelliSense, if your team hasn't agreed on line-length limits for className strings, if you're writing utilities without a design token system underneath — of course it feels unscalable.

Fix your workflow before blaming the framework.

Tailwind v4 is a solid release. The CSS-first config is genuinely better. The debate around it is mostly teams realizing they need to make explicit decisions they've been avoiding.

Make the decision. Document it. Move on.

What's your team's approach? Are you all-in on utility classes, leaning on @apply, or somewhere in the middle? Drop it in the comments — I'm genuinely curious where the dev.to crowd lands on this.

I Fixed the "AI Commit Messages" Problem in 20 Lines of Python

Enjoy Kumawat — Sun, 21 Jun 2026 09:14:30 +0000

You've probably seen that trending post — "I Asked AI to Write My Commit Messages and It Was Embarrassing."

Same. But instead of accepting embarrassing output, I fixed it.

Here's the thing: the problem isn't AI writing commit messages. The problem is how you ask it. One clear system prompt + the actual diff = surprisingly good results.

The Setup

No new packages. No API key. If you have Claude Code, you're already set.

#!/usr/bin/env python3
import subprocess

SYSTEM = (
    "You are a git commit message generator. "
    "Output ONLY the commit message — no explanation, no markdown, no quotes. "
    "Follow Conventional Commits: type(scope): subject. "
    "Types: feat, fix, docs, style, refactor, test, chore. "
    "Subject: imperative, lowercase, max 72 chars."
)

diff = subprocess.check_output(["git", "diff", "--staged"], text=True)
if not diff.strip():
    print("Nothing staged. Run `git add` first.")
    raise SystemExit(1)

msg = subprocess.check_output(
    ["claude", "-p", SYSTEM + "\n\n" + diff],
    text=True,
).strip()
print(msg)

That's it. 20 lines. Uses the claude CLI under the hood — no API key, no config, just your existing Claude Code OAuth session.

Why It Works

The system prompt does the heavy lifting. Three constraints:

Output ONLY the commit message — no preamble, no explanation
Follow Conventional Commits — feat, fix, chore, etc.
max 72 chars — keeps it readable in git log

The diff is the context. You're not asking "write a commit message". You're asking "given these exact changes, what happened?" That's a much more answerable question.

Usage

# No setup needed if you have Claude Code. Just:
git add .
python /path/to/git_commit.py
# → feat(server): add AI commit message generator via Claude CLI

Or wire it into a git alias:

git config --global alias.ai '!python /path/to/git_commit.py'
# git ai

The Results

Before:

update stuff
fix bug
WIP
added the thing

After:

feat(api): add generate_commit_message tool to MCP server
fix(auth): handle expired token on refresh
refactor(db): extract query builder into separate module

As an MCP Tool Too

I also wrapped it as an MCP tool so Claude Code can call it directly from any conversation:

@mcp.tool()
def generate_commit_message(diff: str) -> str:
    """Generate a Conventional Commits message from a git diff string."""
    full = SYSTEM + "\n\n" + diff
    return subprocess.check_output(["claude", "-p", full], text=True).strip()

Full project: github.com/enjoy-kumawat/my-git-manager

20 lines. No new dependencies. No API key. Conventional Commits every time.

The embarrassing part was waiting this long to build it.

I built an MCP server that lets Claude manage my GitHub profile and DEV.to articles — here's how

Enjoy Kumawat — Sun, 21 Jun 2026 08:53:50 +0000

I wanted Claude to know about my developer presence — my repos, my articles, my stats — without me having to paste links every time. So I built a small MCP server that connects both GitHub and DEV.to directly to Claude.

Now I can just say: "What's my most starred repo?" or "Draft a DEV.to article about my latest project" — and Claude actually does it.

Here's how I built it in under 100 lines of Python.

What is MCP?

Model Context Protocol is an open standard that lets you connect external tools and APIs to Claude (and other LLMs). You define tools with a decorator, run a server, and Claude can call those tools during a conversation.

I'm a contributor to the MCP Python SDK, so naturally I wanted to build something real with it.

What it does

The server exposes 7 tools across two APIs:

GitHub:

get_github_profile — followers, repos, bio
list_repos — sort by stars/forks/updated
get_repo_stats — stars, forks, issues for any repo

DEV.to:

list_articles — all your articles with reaction/view counts
create_article — draft or publish a new article
update_article — edit title, body, or publish state
get_article_stats — reactions, comments, page views

The code

Install the only dependency:

pip install mcp[cli]

Create a .env file:

GITHUB_TOKEN=your_github_token
GITHUB_USERNAME=your_github_username
DEV_TO_API=your_devto_api_key
DEV_USERNAME=your_devto_username

Here's the full server (server.py):

import os, json, urllib.request
from mcp.server.fastmcp import FastMCP

GITHUB_USERNAME = os.environ.get("GITHUB_USERNAME", "")
DEV_USERNAME = os.environ.get("DEV_USERNAME", "")

mcp = FastMCP("developer-presence")

def _gh(path, method="GET", data=None):
    req = urllib.request.Request(f"https://api.github.com{path}", method=method)
    req.add_header("Authorization", f"token {os.environ['GITHUB_TOKEN']}")
    req.add_header("Accept", "application/vnd.github.v3+json")
    if data:
        req.add_header("Content-Type", "application/json")
        req.data = json.dumps(data).encode()
    with urllib.request.urlopen(req) as r:
        return json.loads(r.read())

def _dev(path, method="GET", data=None):
    req = urllib.request.Request(f"https://dev.to/api{path}", method=method)
    req.add_header("api-key", os.environ["DEV_TO_API"])
    req.add_header("Content-Type", "application/json")
    if data:
        req.data = json.dumps(data).encode()
    with urllib.request.urlopen(req) as r:
        return json.loads(r.read())

@mcp.tool()
def get_github_profile() -> dict:
    """Fetch public GitHub profile stats."""
    u = _gh(f"/users/{GITHUB_USERNAME}")
    return {"login": u["login"], "name": u.get("name"), "bio": u.get("bio"),
            "public_repos": u["public_repos"], "followers": u["followers"]}

@mcp.tool()
def list_repos(sort: str = "updated", limit: int = 10) -> list:
    """List public repos sorted by updated/stars/forks."""
    repos = _gh(f"/users/{GITHUB_USERNAME}/repos?sort={sort}&per_page={min(limit,100)}")
    return [{"name": r["name"], "stars": r["stargazers_count"],
             "language": r.get("language"), "url": r["html_url"]} for r in repos]

@mcp.tool()
def list_articles(per_page: int = 10) -> list:
    """List your DEV.to articles with stats."""
    articles = _dev(f"/articles/me?per_page={min(per_page,30)}")
    return [{"id": a["id"], "title": a["title"],
             "reactions": a.get("positive_reactions_count", 0),
             "page_views": a.get("page_views_count", 0)} for a in articles]

@mcp.tool()
def create_article(title: str, body_markdown: str,
                   tags: list[str] = None, published: bool = False) -> dict:
    """Create a new DEV.to article."""
    payload = {"article": {"title": title, "body_markdown": body_markdown, "published": published}}
    if tags:
        payload["article"]["tags"] = tags
    result = _dev("/articles", method="POST", data=payload)
    return {"id": result["id"], "url": result.get("url")}

if __name__ == "__main__":
    mcp.run()

(Full version with all 7 tools on GitHub)

Run it

# Dev mode — opens MCP Inspector in browser
mcp dev server.py

# Or wire into Claude Desktop

For Claude Desktop, add this to claude_desktop_config.json:

{
  "mcpServers": {
    "developer-presence": {
      "command": "python",
      "args": ["/path/to/server.py"],
      "env": {
        "GITHUB_TOKEN": "...",
        "GITHUB_USERNAME": "...",
        "DEV_TO_API": "...",
        "DEV_USERNAME": "..."
      }
    }
  }
}

What I can do now

Once connected, I can ask Claude things like:

"List my top 5 repos by stars"
"What are the stats on my last DEV.to article?"
"Write and publish a draft article about X"
"How many followers do I have on GitHub?"

It sounds simple, but having your developer presence queryable from a conversation is surprisingly useful — especially when you're writing content and want to reference your own work.

Get the code

Everything is on GitHub: enjoykumawat/developer-presence-mcp

If you want to adapt it for your own username, just update the .env file — no other changes needed.

I'm a contributor to the MCP Python SDK. If you're interested in building MCP servers, feel free to reach out or check out the official SDK — it's a great place to start.

Follow me here on DEV.to @enjoy_kumawat for more AI tooling content.