مقدمة: بين حماس الـ React وبساطة سطرين جافاسكربت
أتذكّر أول مرة كتبت فيها سطر useState في React.
كان عندي إحساس أني انتقلت فجأة من مرحلة «أكتب سكربتات بسيطة» إلى مرحلة «أبني تطبيقات جدّية».
وبصراحة، هذا الإحساس خلّاني أرتكب واحد من أكبر أخطائي في بدايات الويب:
كنت أستخدم Framework في كل شيء.
- صفحة هبوط بسيطة؟ React.
- فورم واحد؟ React.
- ويدجت صغير داخل صفحة جاهزة؟ React.
- حتى مشروع شخصي صغير جدًا كان ممكن يخلص في يوم بـ Vanilla… كنت أجرّه جرًا إلى عالم الـ Components والـ Hooks.
في المقابل، في فترة لاحقة تأثرت بخطاب معاكس:
«أنت مش محتاج أي Framework، كل شيء تقدر تعمله بـ Vanilla لو كنت شاطر.»
فقررت أجرّب أبني Dashboard معقّد كامل بـ Vanilla:
- جداول ديناميكية.
- فلاتر متعددة.
- Pagination.
- Routing داخلي.
- State كبيرة للمستخدم، الفلاتر، الإعدادات.
وبعد شهرين، اكتشفت أني بنيت وحش يصعب السيطرة عليه:
- Events موزعة في كل مكان.
- DOM يتغيّر من أكثر من نقطة.
- كل تعديل بسيط يعرّي Bug في مكان آخر.
من هنا بدأ يتشكّل عندي سؤال مهم:
متى فعلاً تحتاج Framework؟ ومتى Vanilla هي الحل الأنظف والأذكى لمشروعك؟
وخليني أشاركك التجربة بتفاصيل أكثر، بدون تنظير، وبشكل يناسب مطوّر عنده احتكاك حقيقي بالمشاريع، مش مجرد «Hello World».
المشكلة الحقيقية: خلط بين «أداة التعلم» و«أداة الإنتاج»
قبل ما نجاوب «متى؟»، نحتاج نرتّب مفاهيم بسيطة:
ما هو Vanilla بالضبط؟
لما نقول «Vanilla JavaScript» فنحن نقصد:
- استخدام جافاسكربت كـ Language مباشرة في المتصفح.
- بدون React أو Vue أو Angular.
- بدون مكتبات كبيرة تنظّم لك بنية التطبيق.
- وصول مباشر للـ DOM، وإدارة الأحداث، والـ state بيدك أنت.
Vanilla يعني:
- تحكم كامل في كل سطر.
- خفة في الكود.
- فهم حقيقي لسلوك المتصفح.
وفي موقع مثل كود التطور راح تلاحظ أن التركيز دائمًا على فهم الأساسيات قبل الانتقال لأي إطار عمل؛ لأن بدون أساس قوي، أي Framework راح يتحول معك لأداة نسخ/لصق لا أكثر.
ما هو Framework؟
Framework (أو Library كبيرة) مثل React / Vue / Next / Laravel، هو:
- هيكل جاهز + مجموعة مفاهيم + أدوات.
- يحاول يحل مشاكل معيّنة تعاني منها المشاريع متوسطة وكبيرة:
- تنظيم الكود.
- إدارة الحالة (State Management).
- التعامل مع Routing.
- التعامل مع Side Effects.
- تسهيل إعادة استخدام العناصر (Components).
إطار العمل لا يأتي من فراغ؛ هو نتيجة مشاكل حقيقية واجهت آلاف المطورين على مدار سنوات.
لكن استخدامه في مشروع لا يحتاج كل هذا، يشبه استخدام شاحنة لنقل كرسي واحد.
مشروع اختنق بـ Framework، ومشروع انهار بـ Vanilla
مشروع صغير تم قتله بـ Over-Engineering
كان عندي مشروع:
- صفحة هبوط لخدمة واحدة.
- جملة تعريفية، فورم صغير، وزر «اشترك الآن».
- بعض الأنيميشن الخفيفة عند السكورول.
في هذه الحالة:
- كان يكفي HTML + CSS + ملف JS صغير للتعامل مع الفورم.
لكن حماسي وقتها كان أكبر من حجم المشروع، فقررت:
- أستخدم React.
- أضيف Router (رغم أن عندي صفحة واحدة).
- أتعامل مع الفورم بالـ
useState. - وأبني Components لكل جزء من الصفحة.
ما الذي حدث؟
- حجم مشروع أكبر من اللازم.
- وقت إعداد البيئة صار أطول من وقت بناء الصفحة نفسها.
- حاسّ أني كتبت كود «منظم»… لكنه غير عملي لحجم المهمة.
مشروع كبير تم قتله بـ Vanilla فقط
في مشروع آخر، كان المطلوب:
- لوحة تحكم لموقع.
- جداول، فلاتر، Charts.
- أدوار وصلاحيات (Admin, Editor…).
- حالة متداخلة بين أجزاء كثيرة.
تأثّرت وقتها بفكرة «استخدم Vanilla قدر الإمكان»، وقررت أكتب كل شيء بدون أي Framework:
- ملفات JS كثيرة.
- State على شكل كائنات ضخمة يتم تعديلها من أكثر من مكان.
- Events في كل زاوية، من جداول لفلاتر لأزرار.
بعد مدة:
- الكود صار ثقيل على الدماغ.
- إضافة Feature جديدة تلمس ٥ ملفات.
- Bugs تظهر في أماكن بعيدة عن التعديل الأصلي.
هنا استوعبت أن:
المشكلة ليست في Vanilla ولا في Framework… المشكلة في اختيار الأداة الخطأ للحجم الخطأ.
قبل أن تسأل «متى؟»… اسأل «ماذا تبني؟»
من التجارب والمشاريع اللي مرّت علي، وصلت لقناعة بسيطة:
قرارك بين Vanilla و Framework لازم ينبني على وصف المشروع، مش على مزاجك أو الترند.
اسأل نفسك:
- ما حجم المشروع؟
- صفحة واحدة؟ العديد من الصفحات؟ تطبيق معقّد؟
- ما نوع التفاعل (Interactions)؟
- تفاعلات بسيطة (إظهار/إخفاء عناصر، فورم واحد).
- أم تفاعلات معقّدة (فلتر، بحث، Pagination، State كثيرة).
- ما عمر المشروع؟
- صفحة لموسم أو حملة مؤقتة.
- أم منتج/تطبيق سيعيش سنوات ويكبر.
- من الذي سيعمل على الكود؟
- أنت فقط.
- أم فريق بأكثر من مطوّر.
بعد ما تجاوب على هذه الأسئلة، الصورة تبدأ تتوضح.
متى تستخدم Vanilla؟
1. عندما يكون المشروع صغير وبسيط
أمثلة عملية:
- صفحة هبوط لخدمة واحدة.
- صفحة تعريفية لشخص أو شركة.
- ويدجت بسيط لإظهار إشعار أو مودال.
- فورم صغير مع Validation مباشرة.
في هذه الحالات:
- Framework غالبًا Overkill.
- Vanilla يعطيك:
- أداء أفضل (لا Runtime ثقيل).
- حجم ملف أصغر.
- سهولة في النشر بدون إعدادات معقّدة.
قبل أن تقرر تستخدم React أو Vanilla، اسأل:
- هل هذا فعلاً تطبيق يحتاج State معقّدة؟
- أم مجرد صفحة تحتاج عرض محتوى وتفاعل بسيط؟
2. عندما تكون في مرحلة تعلم أساس اللغة
لو هدفك اليوم:
- تبني نفسك كمطوّر JavaScript محترم.
- تفهم اللغة بدون «اختصارات» جاهزة.
فمنطقي جدًا أن:
- تركز أولًا على Vanilla.
- تبني ٣–٤ مشاريع بسيطة بها:
- To-Do List.
- Notes App.
- Fetch API بسيط لجلب بيانات.
- أداة صغيرة داخل صفحة.
في كود التطور يوجد محتوى عن بناء مشاريع عملية بـ JavaScript، وهذا النوع من المشاريع هو المكان المثالي لتطبيق Vanilla بعمق:
لما تبني هذه المشاريع بـ Vanilla:
- تتعلم كيف تفكر باسم المتغيرات، تنظيم الملفات، التعامل مع الـ DOM.
- Framework بعدها يصبح طبقة منطقية فوق شيء أنت أصلاً تفهمه.
3. عندما يكون الأداء وحجم الملف أولوية قصوى
بعض السيناريوهات:
- صفحة تُعرض على شبكات بطيئة.
- موقع إخباري أو مدوّنة تحتاج سرعة عالية في التحميل.
- سكربت يتم تضمينه في مواقع متعددة كجزء من Snippet.
هنا:
- كل كيلوبايت مهم.
- Vanilla غالبًا تقدم خيارًا أخف وأسرع من استخدام Framework بكامل حمولته.
4. عندما تبني أدوات شخصية أو بروتوتايب سريع
لو عندك فكرة:
- أداة صغيرة تساعدك أنت في شغلك.
- Prototype لتجربة UI معيّن.
- مشروع شخصي تحب تلعب فيه بالـ DOM.
في هذه الحالات:
- Vanilla تعطيك حرية أكبر وأقل Ceremony.
- لا تحتاج إعداد مشروع كامل، ولا Dependecies كثيرة.
متى تستخدم Framework؟
1. عندما يكون المشروع عبارة عن تطبيق كامل، وليس مجرد صفحة
أمثلة:
- Dashboard لإدارة بيانات.
- نظام إدارة محتوى (CMS).
- تطبيق فيه تسجيل دخول، صفحات كثيرة، تنقل، وإعدادات.
- واجهة أمامية لتطبيق SaaS.
هنا:
- Vanilla وحدها ممكن تشتغل، لكن التكلفة:
- تعقيد كبير في تنظيم الملفات والمجلدات.
- صعوبة في إدارة الحالة بين أجزاء مختلفة.
- خطر أن يتحول الكود إلى تشابك صعب الفهم.
Framework مثل React/Next/Vue:
- يعطيك هيكل:
- Components بدل أن تبني كل شيء يدوياً.
- Routing منظم.
- State Management واضحة.
- يجبرك – بشكل غير مباشر – أن تكتب كود قابل لإعادة الاستخدام.
لو أنت مهتم بالتعمق في JavaScript وسوقها وكيف تستخدم في مشاريع أكبر، هذا المقال من كود التطور يساعدك تبني صورة أوسع قبل أن تختار إطار عمل:
2. عندما تعمل في فريق وليس وحدك
لو المشروع:
- عليه أكثر من مطوّر Front-End.
- يتسلم منه ناس مختلفين بمرور الوقت.
- هو جزء من منتج لشركة أو منصة تعليمية مثل كود التطور.
Framework هنا:
- يوفر «لغة مشتركة» بينكم:
- كيف نبني Component؟
- أين نضع الـ State؟
- ما هو نمط التعامل مع الـ API؟
- يقلل من تشتت الأساليب الفردية.
بدل أن يكون عندك ٥ طرق مختلفة للتعامل مع DOM، إطار عمل واحد يضع Pattern غالبًا يتفق عليه المجتمع.
3. عندما تحتاج Ecosystem جاهز بدل إعادة اختراع كل شيء
بعض الأطر تأتي مع:
- Router.
- SSR/SSG (مثل Next.js).
- حلول جاهزة للـ Auth، الترجمة، التعامل مع الـ Forms.
- مكتبات UI جاهزة (Tailwind + UI Kits، MUI، وغيرها).
لو مشروعك يحتاج:
- SEO قوي.
- Routing متقدم.
- تكامل مع APIs كثيرة.
- Multilingual Support.
Framework يوفر عليك:
- وقت.
- أخطاء.
- تفكير في التفاصيل الصغيرة بدل التركيز على منطق المشروع نفسه.
4. عندما يكون المشروع طويل الأمد، يعيش سنوات ويتوسع
لو تعرف أن:
- المشروع ليس تجربة لمدة شهر.
- بل نظام سيبقى، ويحتاج Features جديدة باستمرار.
Framework يساعدك:
- تحافظ على شكل موحد للكود مع الزمن.
- تقلل من تراكم «ديون تقنية» (Technical Debt) ناتجة عن حلول سريعة وغير منظّمة.
- تعطي أي مطوّر جديد يدخل المشروع فرصة أن يفهمه أسرع.
معايير عملية لاتخاذ القرار في كل مشروع جديد
قبل أن تفتح VS Code، جرّب تسأل نفسك هذه الأسئلة كـ Checklist:
1. عدد الصفحات والشاشات
- لو عندك صفحة واحدة أو اثنتان، مع تفاعل محدود:
- Vanilla خيار منطقي.
- لو عندك ٧–١٠ صفحات، Routing، وأجزاء مشتركة بين الصفحات:
- Framework يبدأ يصبح منطقيًا أكثر.
2. حجم وتعقيد الـ State
اسأل:
- هل عندي حالة (state) بسيطة أم معقّدة؟
- زر مفعّل/غير مفعّل → بسيطة.
- فلتر + Pagination + User Settings + Auth → معقّدة.
كلما زاد التعقيد:
- Framework مع نظام State Management (مثل Redux أو Context أو Pinia) يساعدك ترتّب الأمور.
3. عمر المشروع
- هل هذه صفحة حملة مؤقتة؟
- أم لوحة تحكم لموقع تعليمي مثل كود التطور، ستُستخدم سنوات؟
مشروع مؤقت:
- Vanilla غالبًا تكفي.
مشروع طويل:
- Framework يعطيك استقرار وتنظيم.
4. من الذي سيكتب الكود ويصونه؟
- شخص واحد فقط:
- حرية أكبر في الاختيار.
- فريق:
- إطار عمل يساعد على توحيد الأسلوب، وتسهيل الفهم المتبادل للكود.
أخطاء متكررة في موضوع Vanilla vs Framework
1. استخدام Framework لكل شيء لمجرد أنه «ترند»
الخطأ:
- مشروع بسيط جدًا، لكن مطوّر يريد يجرب أحدث إطار، فيستعمله لمجرد أنه موجود في الترند.
النتيجة:
- تعقيد زائد.
- حجم ملفات أكبر من الحاجة.
- وقت إعداد أكبر من وقت البناء نفسه.
2. رفض أي Framework بحجة «البساطة» أو «الرجولة التقنية»
في المقابل:
- مطوّر يرى أن استخدام Framework نوع من «الكسل».
- يحاول يبني كل شيء بنفسه، حتى لو المشروع يحتاج تنظيم واضح.
هذا – على المدى البعيد –:
- يخلق كود صعب الصيانة.
- يستهلك وقت أكثر.
- ويجعلك تكرر اختراع حلول موجودة مسبقًا، بدل أن تضيف قيمتك في منطق المشروع نفسه.
3. البدء بفريمورك قبل فهم أساسيات JavaScript
هذا من أكثر الأخطاء فتكًا:
- الدخول مباشرة لـ React أو Vue بدون فهم:
- الـ Scope.
- الـ Closures.
- كيف يعمل الـ Event Loop.
- كيف يشتغل الـ DOM.
النتيجة:
- كود يعتمد على نسخ ولصق.
- إحباط عند أول Bug معقّد.
- شعور أن «البرمجة معقّدة جدًا»، بينما المشكلة في طريقة البدء.
4. بناء Framework شخصي ثم الاعتماد عليه في الإنتاج
فكرة أن تبني Micro Framework بنفسك:
- ممتازة للتعلم.
- تكشف لك لماذا ظهرت الفريموركات العالمية أساسًا.
لكن:
- استخدامها في إنتاج حقيقي مع عملاء أو شركة يجعل مسؤوليتك ضخمة:
- أنت مسؤول عن الأداء.
- الأمن.
- التحديثات.
في كثير من الأحيان:
- الأفضل أن تتعلم من بناء أدوات صغيرة، لكن في الإنتاج تعتمد على شيء مجرّب ومدعوم من مجتمع كبير.
كيف تربط هذا بواقعك كمطور عربي؟
لو أنت تتابع محتوى كود التطور، غالبًا عندك مسار واضح:
- أساسيات الويب.
- JavaScript ومشاريع عملية.
- ثم مراحل اختيار الفريمورك المناسب لمسارك.
ممكن تبني هذه الخريطة لنفسك:
- افهم مشروعك بشكل صحيح
- رجوع لمقال:
- حدد بالضبط:
- هل مشروعك صفحة؟ تطبيق؟ لوحة تحكم؟
- ابنِ مشاريع عملية بـ Vanilla
- طبق محتوى:
- اكتب الكود بنفسك، غلّط، عدّل، جرّب.
- افهم وضع JavaScript وسوقها
- اقرأ:
- هذا يساعدك تربط قرارك التقني بالواقع الوظيفي.
- بعد الأساس، اختر Framework واحد وادخل به بقوة
- لا تتنقل بين ٣ أطر عمل في نفس الوقت.
- اختر واحد يناسب مسارك (مثلاً Next لو مسارك ويب حديث).
- طبّق عليه نفس مشاريعك لكن مدعومة بهيكل أقوى.
الخلاصة
Vanilla و Framework ليستا خصمين، بل أداتين تكملان بعضهما.
- Vanilla:
- أساس فهمك للغة.
- الأنسب للمشاريع الصغيرة البسيطة.
- أداة ممتازة للتعلّم وصقل مهارتك.
- Framework:
- أداة تنظيم للمشاريع المعقّدة.
- لغة مشتركة بينك وبين الفريق.
- وسيلة لتسريع بناء تطبيقات جاهزة للإنتاج.
السؤال الحقيقي ليس:
«هل أستخدم Framework أم Vanilla؟»
السؤال الحقيقي:
«ماذا أحاول أن أبني؟ وما المسار الذي أريد أن أسير فيه كمطوّر؟»
كلما كان هذا السؤال واضحًا في رأسك، كلما أصبح اختيارك بين Vanilla و Framework قرارًا واعيًا وعقلانيًا… وليس مجرد ردّة فعل لحماس كورس جديد، أو خوف من أن تكون «مختلفًا» عن الترند.
وفي النهاية، المهم ليس اسم الأداة التي تستخدمها، بل جودة الكود الذي تكتبه، وواقعية المشاريع التي تبنيها، ومدى اقترابك من الصورة التي تحلم أن ترى فيها نفسك كمطوّر عربي يبني «كود التطور» الخاص به فعلًا، مش مجرد ملفّات عابرة.
اكتشاف المزيد من كود التطور
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
