چرا باید از Tailwind استفاده نکنیم؟

اگر چندسالی در دنیای Front-end فعالیت داشتید حتما متوجه شدید که روند تغییرات چقدر در این حوزه سریعه. وقتی شروع کردم به یادگیری فرانت‌-اند همچنان از بعضی‌تگ‌های HTML استفاده میشد برای استایل‌دهی مثل table (هنوز فلکس پشتیبانی نمیشد) بعد کم‌کم JQuery ترند شد و چقدر با ذوق و اشتیاق ازش تعریف میکردیم که آی چقدر traverse کردن بین المنتا راحته و سلکت کردنشون فلانه و بهمان. اونم کم کم رفت و جاشو داد دوباره به pure JS. باز بعدش فرانت‌-اند فریمورک‌‌هایی مثل Angular, React, Vue اومدند و الانم که دارم این مقاله رو مینویسم این فریمورک‌ها هم کم کم دارن جایگاهشونو از دست میدن و Web Assembly و Web Components دارن جاشونو میگیرن. این مقدمه طولانی رو نوشتم که بگم آقا دنیای فرانت‌، دنیایی هستش که یکچیزی ترند میشه و میره، دل‌نبندین که تهش تلخیه. حالا چه ربطی به Tailwind داشت؟؟ اینقدر که تو کامیونیتی‌‌ بیخود از این فریمورک‌ تعریف میشه (ترند شده) و بزرگش میکنن برای هر چیزی ازش استفاده میکنن بدون اینکه بدونن use case اش چیه.

*اگه میخوای بری سراغ اصل مطلب این تاریخچه و معرفی Tailwind رو نخون

Atomic CSS
پایه اساس همه این Utility-first CSS frameworks مثل Tailwind یک پردایم جدید در css بعنوان Atomic هست. کلیتش چی میگه این پردایم؟ همه چی از یک مقاله ساده که آقای Koblentz نوشت شروع شد که اومده بود best practice ‌های CSS رو به چالش کشیده بود و رویکرد functional رو ارائه کرد که بعد‌ها به Atomic معروف شد. این رویکرد میگه بجای استفاده از کلاس‌های کلی برای یک کامپوننت از کلاس‌های کوچک که فقط یک وظیفه دارند استفاده کنیم. برای مثال:

در قطعه کد بالا ما به روش قدیمی semantic کد CSS رو زدیم که یک باکس محصولات هست و اگر داخلش المنتی به نام title هم باشه اونم استایل میده. آقای Koblentz این روشو دیس کرده (منطقی هم هست حرفاش) و رویکرد Atomic رو معرفی کرد که همون دیزاین بالا رو به شکلی دیگه پیاده‌سازی کرده:

همونطور که میبینید ما کلی Utility Class داریم که یکبار تعریف کردیم و چندجا استفاده میکنیم. در واقع ذره ذره شکل میدیم المنت رو (atomic).

اصل مطلب

تو این لیست تجربیات استفاده از Tailwind رو بازگو میکنم :

• این فریمورک DRY رو عملی کرده:

فریمورک Tailwind ادعا میکنه که رویکرد DRY مخفف (don't repeat yourself) رو در CSS پیاده سازی کرده و باعث شده که برای مثال بجای اینکه تو ده‌تا کمپوننت display:flex رو تعریف کنی یکبار اونو تعریف کنی و تو چند کمپوننت استفاده کنی. ولی اینو نمیگه که بجای تکرار شدن تو CSS توی HTML اسم کلاسش چندبار باید مصرف شه :))

• زیر پا گذاشتن اصل Separation of Concerns:

تو این عکس، نویسنده، یک سایت قدیمی رو مثال زده که برای استایل دادن وبسایت مجبور شده از المنت‌های HTML استفاده کنه (مثل استفاده از تگ‌‌های <table> و <font> و <b>). نویسنده در ادامه اشاره میکنه هدف از ایجاد شدن CSS، جدا کردن محتوا و ساختار از مبانی بصری و نمایشی است.

To separate content and presentation

فریمورک Tailwind دقیقا داره خلاف این اصل عمل میکنه. شما وقتی کلی کلاس داری توی HTML ات دیگه عملا اومدی presentation هارو ریختی تو contentها. در بهترین حالت میشه اینلاین استایل درنظرش گرفت.

• سند HTML به‌شدت ناخوانا

یک‌وقت فکر نکنین این کدو یکی از شاگردایِ خبرهِ محسن مدحج زده‌ها. نه!! این کد رو از صفحه Home وبسایت رسمی Tailwind برداشتم. یک کد خیلی تیپیکال از نظر تیل وایندی‌ها :) حالا فرض کنید سورس کدی بهتون میدن که کلی از این المنت‌ها داره. دیگه فایل CSS رو نمیخونین. باید بری تک تک کلاسای HTML اش رو بخونی تا متوجه شی این المنت چیه؟، چه شکلیه؟، چیکار میکنه؟، با hover شدن روش چی‌کار میشه؟، تو حالت ریپانسیو چی‌کار میشه؟ و...

• ناسازگار با JavaScript

بزرگترین موردی که بهش برخوردم، وقتی بود که میخواستم با کلیک روی یک المنت یک وضعیتی بهش بدم. مثلا کلاس active بدم به اون المنت. در حالت معمولی یک کلاس active مینوشتم که توش برای مثال
1- قطر border المنت رو 2 پیکسل بیشتر میکردم
2- رنگ border المنت رو عوض میکردم
3- یک transform: translateY(2px) به المنت میدادم
4- بک گراند المنت رو سبز میکردم
5- color المنت از مشکی به سفید تغییر میدادم
6- یک box-shadow هم روش اعمال میکردم

بعد با کلیک روی المنت، کلاس active بهش اینجکت میشد. حالا تو Tailwind شما نابود میشی اینو پیاده‌سازی کنی. یک همچین چیزی در میاد اگه Tailwind رو کاستومایز کرده باشید.

همونطور که مشاهده میکنید Tailwind نه تنها کد HTML شما رو ناخوانا میکنه، کد JS تون هم خیلی بزرگ میکنه. در آینده هم بخواد حالت active کدمون عوض شه باید بریم سراغ کد JS و اونو تغییر بدیم. ولی در حالت اول فقط لازمه فایل CSS عوض شه. البته Tailwind حالتی داره که بشه یک custom class بنویسی با استفاده از @apply ولی توی محیط توسعه ما ممکن بود ما بخوایم بعدا سوییچ کنیم روی فریمورک دیگه‌ای و اگه Tailwind حذف میشد دیگه نمیشد از apply استفاده کنیم. به شما هم پیشنهاد میکنم تاجایی که امکان داره ازش استفاده نکنین حتی خود داکیومنت Tailwind اونو old school حسابش میکنه.

• امکان استفاده از ارث بری در CSS نیست!!

چون داریم همه چیزو به Tailwind میسپاریم توی تعریف کلاس‌ها دیگه نمیتونیم یکی از ابزار قدرتمند CSS یعنی ارث بری استفاده کنیم که خودش باعث ایجاد duplication در کد میشه. برای مثال:

تو اینجا همه title های درون card ، یک استایل دارند و ما یکبار براش کلاس تعریف کردیم و تو چند المنت استفاده میکنیم. title هایی که بیرون از card استفاده شدن استایل متفاوتی دارند. پیاده‌سازی همین کد رو میریم در Tailwind داشته باشیم. ببینید که چقدر باعث داپلیکیشن میشه و چقدر ارث بری css مفیده.

نتیجه‌گیری:
فریمورک Tailwind علارغم تمام امکانات دوست‌ ‌داشتنی که ارائه میده، اونقدر کارو برای من سخت کرد که فکر نکنم دیگه برای هیچ پروژه بزرگ یا در حال توسعه‌ای بخوام استفادش کنم.خیلی‌‌هارو میبینم بدون اینکه حتی یکبار ازش استفاده کرده باشن دارن صرفا با ارجاع به داکیمونتش پروموت میکنن (از حق نگذریم واقعا وب‌سایت و داکیومنت زیبایی داره). خلاصه که در به‌کار بردن Tailwind محتاط باشید.