سجل قرار البنية المعمارية: إطار CSS
المحتويات:
الملخص
المسألة
نريد استخدام إطار CSS لإنشاء تطبيقات الويب الخاصة بنا:
نريد أن تكون تجربة المستخدم سريعة وموثوقة على جميع المتصفحات وأحجام الشاشات الشائعة.
نريد تكرارًا سريعًا في التصميم والتخطيط وواجهة/تجربة المستخدم (UI/UX) وغيرها.
نريد تطبيقات متجاوبة، خصوصًا للشاشات الأصغر مثل أجهزة الجوّال، والشاشات الأكبر مثل الشاشات العريضة 4K، والشاشات الديناميكية مثل الشاشات القابلة للتدوير.
القرار
تقرر اعتماد Bulma.
الحالة
تقرر اعتماد Bulma. ونحن منفتحون على خيارات أطر CSS الجديدة كلما ظهرت.
التفاصيل
الافتراضات
نريد إنشاء تطبيقات ويب حديثة وسريعة وموثوقة ومتجاوبة وما إلى ذلك.
تقلل تطبيقات الويب الحديثة النموذجية من استخدام jQuery أو تلغيه لأسباب متعددة:
تُدخل JavaScript الحديثة تدريجيًا كثيرًا من القدرات التي كانت jQuery توفرها، فتقل الحاجة إلى jQuery، وتوجد وحدات أفضل وأسرع وأصغر توفر تنفيذات محددة
نهج jQuery العام هو التلاعب المباشر بـDOM، وهو نمط مضاد (anti-pattern) لأطر JavaScript الحديثة (مثل React وVue وSvelte)
تتداخل jQuery مع نفسها إذا حُمِّلت مرتين، وهكذا
القيود
إذا اخترنا إطار CSS يستخدم jQuery، فسنضطر إلى استيراد jQuery. فمثلًا، يستخدم Semantic UI مكتبة jQuery بينما لا يستخدمها Tachyons.
وإذا اخترنا إطار CSS مصغّرًا، فإننا نتخلى عن مكونات الإطار التي قد نريدها الآن أو قريبًا. فمثلًا، يوفر Semantic UI شريط صور دوّارًا، بينما لا يوفره Tachyons.
المواقف
نظرنا في عدم استخدام أي إطار. ولا يزال هذا يبدو قابلًا للتطبيق، خصوصًا لأن شبكة CSS (CSS grid) توفر معظم ما يحتاجه مشروعنا.
ونظرنا في أطر CSS كثيرة عبر فرز سريع لقائمة مختصرة: Bootstrap وBulma وFoundation وMaterialize وSemantic UI وTachyons وغيرها. واختيارانا لمراجعة أعمق هما Semantic UI (لأنه الأكثر دلالية في نهجه) وBulma (لأنه الأخف وزنًا ويوفر المكونات التي نريدها الآن).
نظرنا في Semantic UI. فهو يوفر مكونات كثيرة، منها ما نريده لمشروعنا: علامات التبويب والشبكات والأزرار وغيرها. وأجرينا تجربة مع Semantic UI بطريقتين: باستخدام ملفات CDN المعتادة، وباستخدام مستودعات NPM. ونجحنا مع Semantic UI في صفحة HTML ساكنة، لكننا لم ننجح ضمن المهلة المحددة في بناء تطبيق صفحة واحدة بـJavaScript (يعود ذلك أساسًا إلى مشكلات تحميل jQuery). واكتشفنا أن مبرمجين آخرين يطلبون من مطوري Semantic UI إنشاء نسخة بلا jQuery، للأسباب نفسها التي لدينا. ويطلب مبرمجون آخرون نسخة بلا jQuery منذ سنوات طويلة، ومع ذلك رفض المطورون، وقالوا إن أي نسخة بلا jQuery ستكون أصعب من أن تُكتب، مثل ~«يحتوي مشروع Semantic UI على أكثر من 22,000 نقطة تماس تستخدم jQuery».
مثال بـSemantic:
<div class="ui top attached tabular menu">
<a class="item">Alpha</a>
<a class="item">Bravo</a>
</div>
ونظرنا في Bulma. لدى Bulma قدرات كثيرة مشابهة لقدرات Semantic UI، وإن لم تكن مكوناته المتطورة بالكثرة نفسها. وقد بُني Bulma بتقنيات حديثة، مثل عدم استخدام jQuery. ولدى Bulma بعض المكونات التابعة لأطراف ثالثة، وقد نرغب في استخدام بعضها.
مثال بـBulma:
<div class="tabs">
<ul>
<li><a>Alpha</a></li>
<li><a>Bravo</a></li>
</ul>
</div>
الحجة
كما سبق.
وعلى وجه التحديد، يبدو أن Semantic UI يحمل علم تحذير سواء من حيث التقنية (أي كثرة نقاط التماس مع jQuery) أو من حيث القيادة (أي أن الرفض القاطع لنسخة بلا jQuery جاء بدلًا من محاولة وضع خارطة طريق أو التحسين المستمر أو جمع التبرعات وما إلى ذلك).
التبعات
إذا وجدنا إطار CSS جيدًا بلا jQuery، فهذا مفيد وجيد عمومًا.
ذو صلة
قرارات ذات صلة
قد يؤثر إطار CSS الذي نختاره في قابلية الاختبار.
متطلبات ذات صلة
نريد إطلاق تطبيق حديث تمامًا بسرعة.
لا نريد قضاء وقت في العمل على أطر أقدم (خصوصًا Semantic UI) تستخدم اعتماديات أقدم (خصوصًا jQuery).
نواتج ذات صلة
يؤثر في كل HTML النموذجي الذي سيستخدم CSS.
مبادئ ذات صلة
سهل التراجع عنه.
الحاجة إلى السرعة.
ملاحظات
أي ملاحظات هنا.