عبدالله عبدالرحيم سنكر: ليش صار Tailwind CSS خيار المواقع الحديثة؟
عبدالله عبدالرحيم سنكر يشرح ليش صار Tailwind CSS الخيار الافتراضي للمواقع الحديثة: اتساق التصميم، وصغر ملفات CSS، ودعم RTL المنطقي، مع الرد على أشهر الاعتراضات عليه.

تيلويند
عبدالله عبدالرحيم سنكر
إذا فتحت كود موقع حديث مبني بـ React أو Next.js، احتمال كبير تشوف عناصر عليها سطر طويل من الكلاسات مثل flex items-center gap-4 px-6 rounded-xl. أول مرة يبدو المنظر فوضوياً، وكثير من المطوّرين القدامى ينفرون منه. عبدالله عبدالرحيم سنكر يشرح هنا ليش هذا الأسلوب انتشر لين صار البداية المعتادة لمشاريع الويب الجديدة، ووش يكسب صاحب المشروع منه فعلاً، ووين حدوده.
المشكلة اللي جا يحلها
في CSS التقليدي تكتب كلاساً باسم مثل product-card وتعرّف شكله في ملف منفصل. مع الوقت يتضخم الملف، والكل يخاف يحذف أي قاعدة لأنه ما يعرف وين ثاني مستخدمة. مطوّر جديد يحتاج زراً بلون مختلف شوي، فيكتب كلاساً جديداً بدل ما يلمس القديم. وبعد سنة عندك عشرات الدرجات من الرمادي، وقيم متفرقة للمسافات، وملف CSS ما أحد يفهمه كاملاً.
Tailwind قلب الطريقة. بدل ما تخترع اسماً لكل عنصر، تستخدم كلاسات صغيرة جاهزة لكل خاصية وتركّبها مباشرة على العنصر. الكلاس p-4 يعني مسافة داخلية من سلّم مسافات محدد، و text-lg حجم خط من سلّم أحجام محدد. يعني أنت تقريباً ما تكتب CSS جديداً، أنت تختار من نظام.
ثلاث فوائد تحس فيها داخل المشروع
- اتساق إجباري: المسافات والألوان والأحجام تجي من ملف إعدادات واحد. المطوّر ما يكتب «١٣ بكسل» من رأسه بسهولة، فيلتزم بالسلّم، ويطلع التصميم متناسقاً بدون ما يراقب أحد كل سطر.
- حجم CSS صغير: أداة البناء تفحص ملفات المشروع وتولّد فقط الكلاسات المستخدمة فعلاً. ما فيه ملف يتضخم مع السنين بقواعد ميتة.
- تعديل بدون خوف: الشكل مكتوب على العنصر نفسه، فلما تعدّل زراً تعرف إنك ما تكسر صفحة ثانية في مكان ما تتوقعه.
وفيه فائدة رابعة أقل وضوحاً: سرعة التنفيذ. المطوّر ما يتنقل بين ملف المكوّن وملف التنسيق، ولا يضيع وقته في تسمية الأشياء. والتجاوب مع الشاشات مكتوب في نفس المكان: md:grid-cols-2 تعني عمودين من الشاشة المتوسطة وفوق، و dark: للوضع الليلي، و hover: لحالة التمرير.
والأهم لصاحب المشروع: هوية العلامة تعيش في ملف الإعدادات. تعرّف لون علامتك مرة باسم مثل brand، والخطوط والزوايا والظلال كذلك، وبعدها كل الموقع يستخدم الأسماء مو القيم. يوم تقرر تعدّل درجة اللون الأساسي، تغيّرها في مكان واحد وتتغير في كل صفحة. وهذا اللي خلّى مكتبات مكوّنات معروفة مثل shadcn/ui تُبنى عليه: تنسخ كود المكوّن لمشروعك، وتلبّسه هويتك من نفس الملف.
وحتى إمكانية الوصول صارت أسهل: متغير focus-visible: يرسم إطار التركيز لمستخدمي لوحة المفاتيح بدون ما يزعج مستخدمي اللمس، وكلاس sr-only يخفي نصاً عن العين ويبقيه مقروءاً لقارئ الشاشة، مثل وصف لزر عليه أيقونة فقط.
للمواقع العربية تحديداً
هنا Tailwind يوفّر وقتاً حقيقياً. الكلاسات المنطقية مثل ms-4 و pe-2 و text-start تعني «بداية السطر» و«نهايته» بدل «يسار» و«يمين»، فتنعكس تلقائياً لما تكون الصفحة باتجاه rtl. وفيه متغيرات rtl: و ltr: للحالات الخاصة، مثل سهم «التالي» اللي لازم ينقلب في العربي. والنتيجة إن موقعاً ثنائي اللغة يُكتب بكود تنسيق واحد بدل نسختين، وما تحتاج ملف «إصلاحات العربي» اللي يكبر مع كل صفحة.
الاعتراضات، وكيف ترد عليها
الانتقاد الأشهر إن الكود يصير طويلاً وقبيحاً. وهذا صحيح لو كررت نفس السطر في عشرين مكان. الحل مو في Tailwind، في المكوّنات: تكتب الزر مرة كمكوّن React، وتستخدمه في كل مكان. التكرار يختفي لأنه انتقل لمكان واحد. وبقية الاعتراضات لها ردود عملية:
- «هذا رجوع للتنسيق المباشر داخل style»: لا، لأن الكلاسات محصورة في نظام تصميم، وتدعم حالات مثل hover والتجاوب والوضع الليلي، وهذا ما تقدر عليه الخاصية style.
- «الكلاسات المتعارضة تلخبط»: مكوّن عليه p-4 وتمرر له p-6 من الخارج، والأولوية ما تتحدد بترتيب كتابتك. مكتبة مثل tailwind-merge تحل هذا بدمج الكلاسات وإبقاء الأخير.
- «الأسماء الديناميكية ما تشتغل»: صحيح. لو ركّبت اسم الكلاس من متغير مثل text-${color}-500، أداة البناء ما تشوف الاسم الكامل وما تولّده. اكتب أسماء الكلاسات كاملة في الكود.
- «يحتاج تعلّم»: أيام قليلة لمطوّر يعرف CSS، لأن أغلب الأسماء اختصارات مباشرة للخصائص نفسها.
متى ما يكون الخيار الصح؟
لو مشروعك صفحة وحدة بسيطة بدون أداة بناء، إضافة Tailwind ممكن تكون أثقل من الحاجة. ولو فريقك عنده نظام تصميم ناضج مبني على CSS Modules أو مكتبة مكوّنات بتنسيقها الخاص، ما فيه سبب تعيد كتابة كل شي عشان الموضة. وفي تطبيقات Flutter السؤال كله ما ينطبق، لأن التنسيق هناك مكتوب بـ Dart داخل الـ widgets.
وفيه سبب تقني زاد انتشاره في مشاريع Next.js تحديداً: مكوّنات السيرفر. مكتبات التنسيق اللي تولّد CSS داخل المتصفح وقت التشغيل تحتاج تحويل المكوّن لمكوّن عميل أو إعدادات إضافية. أما Tailwind فناتجه ملف CSS ثابت ينبني مرة وحدة، فيشتغل مع مكوّنات السيرفر والعميل بنفس الطريقة، وبدون أي كود تنسيق يُحمَّل للمتصفح.
عبدالله عبدالرحيم بن سنكر الكندي يبني مواقع الويب في منصة أزهل الرقمية بـ Next.js و TypeScript، ويشوف إن قيمة Tailwind الحقيقية لصاحب المشروع تظهر بعد التسليم مو قبله: مطوّر ثاني يستلم الكود فيلاقي نظاماً واحداً واضحاً، مو ملف CSS بآلاف الأسطر مكتوب بأسلوب كل شخص مرّ على المشروع.
الخلاصة: Tailwind ما صار افتراضياً لأنه موضة، صار لأنه يحل مشكلة قديمة في الصيانة والاتساق بطريقة بسيطة. واللي يكرهه في أول ساعة، غالباً شاف كلاسات طويلة ولا جرّب يصون مشروعاً بعد سنة.
عندك فكرة؟ الاستشارة الأولى علينا
كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.
مقالات ذات صلة
كل المقالات
إدارة مشروع برمجي
عبدالله الكندي
عبدالله الكندي: إدارة مشروعك البرمجي من جهة العميل مرحلة مرحلة
خريطة مراحل يشرحها عبدالله الكندي لصاحب المشروع: دورك في كل مرحلة من الاكتشاف إلى ما بعد الإطلاق، ووش تراجع، ووش تستلم، ومتى توقّع على الاعتماد قبل ما تنتقل للي بعدها.
اقرأ المقال
التحول الرقمي للمنشآت الصغيرة
عبدالله بن سنكر
عبدالله بن سنكر: التحوّل الرقمي للمنشآت الصغيرة، من وين تبدأ؟
إطار قرار من أربعة أسئلة يقدّمه عبدالله بن سنكر لصاحب المنشأة الصغيرة: كيف تحدد أول خطوة رقمية، ومتى يكفيك حل جاهز، ومتى تبني نظاماً خاصاً، ومتى تحل الأتمتة المشكلة.
اقرأ المقال
توظيف مبرمج
عبدالله بن سنكر
عبدالله بن سنكر: توظّف مبرمج ولا تستعين بجهة خارجية؟ إطار قرار
إطار قرار من عبدالله بن سنكر لصاحب المشروع المحتار بين توظيف مبرمج داخلي والاستعانة بجهة خارجية: طبيعة الشغل، والتكلفة الحقيقية للموظف، وقدرتك على الإدارة، والحل المختلط.
اقرأ المقال