دلیل واقعی اینکه همه بر سر Tailwind CSS v4 بحث می‌کنند

بحث درباره Tailwind CSS v4 همه‌جا هست. بیشتر مردم دارند درباره موضوع اشتباهی بحث می‌کنند.

سوال اصلی درباره کلاس‌های کاربردی (utility classes) در مقابل استایل‌های درون‌خطی (inline styles) نیست. سوال اصلی این است که استایل‌های شما کجا قرار می‌گیرند و چه کسی هزینه ذهنی آن را پرداخت می‌کند.

Tailwind v4 پیکربندی را به فایل CSS شما منتقل می‌کند. شما به جای یک فایل تنظیمات JavaScript، از @theme استفاده می‌کنید. این کار جریان کاری (workflow) را تمیزتر می‌کند.

اما این دلیل اصلی جنجال نیست. جنجال از این ناشی می‌شود که نسخه v4 استفاده از دو الگوی متفاوت را آسان‌تر کرده است.

الگوی ۱: کلاس‌های کاربردی در کامپوننت‌های شما. شما کلاس‌ها را مستقیماً در HTML یا JSX می‌نویسید. این کار دقیقاً به شما می‌گوید که یک المان چگونه به نظر می‌رسد.

الگوی ۲: رویکرد @apply. شما کلاس‌های معنایی (semantic) مانند .alert یا .alert--error را در یک فایل CSS ایجاد می‌کنید. این کار به شما می‌گوید که یک المان چیست.

هر دو روش کار می‌کنند. هیچ‌کدام اشتباه نیستند. آن‌ها از فلسفه‌های متفاوتی پیروی می‌کنند.

گروه A به هم‌مکانی (co-location) اعتقاد دارد. همه چیز در یک جا باقی می‌ماند. گروه B به نام‌های معنایی اعتقاد دارد. آن‌ها نام‌هایی می‌خواهند که هدف را توصیف کنند.

وقتی یک طراح رنگ خطا را از قرمز به نارنجی تغییر می‌دهد، گروه A در فایل‌های کد جستجو می‌کند. گروه B فقط یک خط را در یک فایل CSS تغییر می‌دهد.

Tailwind v4 باعث می‌شود استفاده از @apply طبیعی‌تر به نظر برسد. این موضوع تنش را بیشتر می‌کند.

در اینجا نحوه انتخاب بر اساس اندازه تیم شما آمده است:

  • تیم‌های کوچک: از کلاس‌های کاربردی استفاده کنید. نیازی نیست وقت خود را صرف نام‌گذاری کلاس‌ها کنید. وقتی همه روی فایل‌های یکسانی کار می‌کنند، سرعت بیشتری خواهید داشت.

  • کتابخانه‌های کامپوننت: از @apply یا متغیرهای CSS استفاده کنید. کاربران شما نباید نیازی به دانستن توکن‌های طراحی (design tokens) داخلی شما داشته باشند.

  • شرکت‌های بزرگ: از یک مدل ترکیبی (hybrid) استفاده کنید. اجازه دهید تیم سیستم طراحی، مالک کلاس‌های معنایی باشد. اجازه دهید توسعه‌دهندگان اپلیکیشن از کلاس‌های کاربردی برای چیدمان‌های سریع استفاده کنند.

از @apply فقط برای فرار از خواندن رشته‌های طولانی کلاس‌ها استفاده نکنید. این یک استراتژی نیست؛ بلکه فرار کردن است.

پرسر‌وصداترین منتقدان اغلب به جای فریم‌ورک، با ابزارهای خود می‌جنگند. اگر ویرایشگر شما فاقد IntelliSense باشد یا تیم شما سیستم توکن طراحی نداشته باشد، جریان کاری شما ناقص به نظر خواهد رسید.

قبل از اینکه فریم‌ورک را سرزنش کنید، جریان کاری خود را اصلاح کنید.

Tailwind v4 یک نسخه قدرتمند است. پیکربندی مبتنی بر CSS بهتر است. این بحث‌ها صرفاً نشانه‌ای است از اینکه تیم‌ها نیاز دارند تصمیمات شفافی بگیرند.

یک انتخاب کنید. آن را مستند کنید. و به کارتان ادامه دهید.

رویکرد تیم شما چیست؟ آیا از کلاس‌های کاربردی استفاده می‌کنید یا @apply؟

منبع: https://dev.to/enjoy_kumawat/the-real-reason-everyones-fighting-about-tailwind-css-v4-4o0g