دليل متعمق لأطر العمل الأمامية

مقدمة

لقد تعلمت أساسيات HTML وCSS وJavaScript، وأصبحت قادرًا على إنشاء صفحات ويب بسيطة. ولكن مع تزايد تعقيد وظائف صفحات الويب، قد تكتشف أن كتابة الكود باستخدام JavaScript الأصلي (Vanilla JS) أصبحت صعبة الصيانة، حيث يتطلب تعديل جزء واحد تغييرات في العديد من الأماكن، وتكثر التعارضات عند العمل الجماعي.

هذا هو السبب وراء حاجتنا إلى أطر العمل الأمامية — فهي تجعل الكود أكثر تنظيمًا وأسهل صيانة وأكثر كفاءة في التطوير. في عالم vibecoding، سيقوم الذكاء الاصطناعي بكتابة معظم الكود نيابةً عنك، لكنك على الأقل يجب أن تكون قادرًا على قراءة أنماط الكود المختلفة لأطر العمل، ومعرفة مزاياها وعيوبها، حتى يتمكن الذكاء الاصطناعي من مساعدتك في اختيار الحزمة التقنية الأنسب.

بعد قراءة هذا الدليل، ستتمكن من:

فهم سبب ضرورة التطور المستمر لتقنيات الواجهة الأمامية
معرفة خصائص كل من Vue وReact وSvelte وAngular
فهم المفاهيم الأساسية مثل "القيادة بالبيانات" (Data-Driven) و"المكونات" (Componentization)
اختيار إطار العمل المناسب وفقًا للمشروع

ما الذي ستتعلمه في هذه المقالة؟

الفصل	المحتوى	ما ستتمكن من فعله بعد التعلم
الفصل 1	لماذا نهتم بتطور الواجهة الأمامية	فهم المشكلات التي يحلها التطور التقني
الفصل 2	عصر صفحات الويب الثابتة	التعرف على أقدم طرق تطوير الويب
الفصل 3	عصر jQuery	فهم نقاط الألم في البرمجة "الأمرية" (Imperative)
الفصل 4	عصر Vue/React	إتقان فكر "البرمجة التصريحية" (Declarative) و"القيادة بالبيانات"
الفصل 5	استراتيجيات العرض (Rendering)	معرفة الفروق بين CSR وSSR وSSG وسيناريوهات استخدامها
الفصل 6	أدوات الهندسة البرمجية	فهم دور أدوات البناء مثل Webpack وVite

يبدأ كل فصل بـ "لماذا نحتاج إلى هذه التقنية"، مما يجعلك تفهم المنطق الكامن وراء التطور التقني.

1. لماذا نهتم بتاريخ تطور الواجهة الأمامية؟

🤔 السؤال الأساسي

لماذا تزداد صفحات الويب تعقيدًا؟ ولماذا يجب أن تتطور تقنيات الواجهة الأمامية باستمرار؟ سيقودك هذا السؤال لفهم مسار التطور التقني من صفحات الويب البسيطة إلى تطبيقات الويب الحديثة.

1.1 من "الملصق الإلكتروني" إلى "تطبيق سطح المكتب"

تخيل ملصقًا (بوستر) تراه في الشارع:

✅ يحتوي على محتوى (نصوص، صور)
✅ يحتوي على تصميم (ألوان، تنسيق)
❌ لكنك إذا تحدثت إليه، لن يرد عليك
❌ إذا نقرت على أي مكان فيه، لن يحدث شيء

أولى صفحات الويب كانت مثل هذه "الملصقات الإلكترونية": يمكن مشاهدتها فقط، لا يمكن تعديلها، محتواها ثابت.

صفحات الويب الحديثة مختلفة تمامًا. إنها مثل تطبيقات سطح المكتب (VS Code، Figma):

✅ يمكنك تحرير المستندات والرسم ولعب الألعاب
✅ تستجيب فورًا لكل إجراء تقوم به
✅ يمكنها حتى العمل دون اتصال بالإنترنت

السبب الأساسي لهذا التحول: وظائف صفحات الويب تزداد تعقيدًا، مما يتطلب تقنيات وطرق تطوير أكثر كفاءة.

1.2 تشبيه من الحياة: بناء منزل

تطور تقنيات الواجهة الأمامية يشبه تطور طرق بناء المنازل:

العصر	🏠 تشبيه بناء المنزل	الخصائص الفعلية	المزايا والعيوب
2000s	لصق الملصقات	صفحات ويب ثابتة، كتابة HTML فقط تكفي	✅ بسيط ❌ لا يمكن التفاعل
2010s	استئجار عمال للديكور اليدوي	عصر jQuery، التحكم اليدوي بكل عنصر	✅ يمكن التفاعل ❌ كود فوضوي وصعب الصيانة
2020s	بناء منزل بمكعبات الليغو	عصر Vue/React، التطوير بالمكونات	✅ فعال وسهل الصيانة ❌ منحنى تعلم

💡 ماذا ترى من الجدول؟

المرحلة الأولى → المرحلة الثانية: من "لا يمكن تحريكه" إلى "يمكن تحريكه". هذه نقلة نوعية — بدأت صفحات الويب تحتوي على تفاعلات، لكن الثمن كان فوضى الكود.

المرحلة الثانية → المرحلة الثالثة: من "قابل للاستخدام" إلى "جيد الاستخدام". تجعل المكونات الكود قابلاً لإعادة الاستخدام مثل مكعبات البناء، مما يرفع كفاءة التطوير بشكل كبير.

الفكرة الأساسية: التطور التقني ليس "جديدًا من أجل الجديد"، بل لحل نقاط الألم في المرحلة السابقة.

2. المرحلة الأولى: صفحات الويب الثابتة و"تقطيع الصور" (2000s)

🤔 السؤال الأساسي

كيف كانت تبدو أولى صفحات الويب؟ ولماذا لم تكن هناك حاجة لأطر العمل آنذاك؟ فهم قيود هذه المرحلة هو ما يجعلك تدرك ضرورة التطور التقني لاحقًا.

I. The Static Era

Web pages were just digital documents. The server sent HTML, and the browser rendered it. Want new content? Refresh the whole page.

index.html

<html>
<body>
  <h1>Hello World</h1>
  <p>Static content served by server.</p>
</body>
</html>

Architecture Pattern

📄 HTML (Content)

↓

🌍 Browser (Display)

Server sends complete HTML

2.1 كيف كان هذا العصر؟

طريقة التطوير:

كتابة عدة ملفات HTML
تضمين بعض CSS و JavaScript
سحب الملفات مباشرة إلى المتصفح لمشاهدة النتيجة
رفع المجلد إلى الخادم لاكتمال النشر

الخصائص:

✅ المزايا: بسيط ومباشر، لا توجد تكلفة تعلم، يعمل فور كتابته
❌ العيوب: لا يمكن تحقيق تفاعلات معقدة، الكود يصبح فوضويًا بمجرد أن يكبر

عرض هيكل المشروع في ذلك الوقت

project/
├── index.html
├── login.html
├── css/
│   ├── bootstrap.css
│   └── custom.css
├── js/
│   ├── jquery.js
│   └── app.js
└── images/

المشاكل التي واجهت:

تلوث المتغيرات العامة: جميع المتغيرات في نطاق عام (global namespace)، مما يسهل تعارضها وكتابتها فوق بعضها
فوضى إدارة التبعيات: يجب تحميل ملفات JS بالترتيب الصحيح، وإلا ستظهر أخطاء
صعوبة إعادة استخدام الكود: إذا أردت إعادة استخدام وظيفة معينة، لا يمكنك سوى النسخ واللصق

2.2 ما هو "تقطيع الصور"؟

ربما سمعت بمصطلح "تقطيع الصور". كان هذا هو العمل الرئيسي لمطوري الواجهة الأمامية في البدايات:

ما هو تقطيع الصور؟

المصمم يصمم الصفحة باستخدام Photoshop → المطور الأمامي يقطع التصميم إلى صور صغيرة → يستخدم HTML لتجميع الصور في صفحة

لماذا كان هذا بطيئًا جدًا؟

كل صورة صغيرة في صفحة الويب تتطلب من المتصفح إرسال طلب شبكة (network request). كلما زادت الطلبات، كان التحميل أبطأ.

👇 جرب بنفسك: لاحظ تأثير طلبات الصور على أداء التحميل

Slice count:12 images Merge into a sprite

Total requests

Estimated load time

750 ms

💡 الصور المجمعة (Sprite)

لتقليل عدد الطلبات، ظهرت تقنية "الصور المجمعة" (CSS Sprite): دمج العديد من الصور الصغيرة في صورة واحدة كبيرة.

الميزة هي تقليل عدد الطلبات، والعيب هو صعوبة الإنتاج والصيانة.

درس هذه المرحلة: كثرة الطلبات هي عدو الأداء الأكبر.

3. المرحلة الثانية: عصر jQuery - "نقل الطوب يدويًا" (2010s)

🤔 السؤال الأساسي

لماذا احتجنا إلى jQuery؟ ما المشكلات التي حلها، وما المشكلات الجديدة التي جلبها؟ فهم قيود jQuery هو ما يجعلك تدرك قيمة Vue/React.

3.1 لماذا احتجنا إلى jQuery؟

مع تزايد تعقيد صفحات الويب، ظهرت مشاكل JavaScript الأصلي (Vanilla JS):

❌ API مرهقة: حتى العمليات البسيطة تتطلب كتابة الكثير من الكود
❌ توافق المتصفحات: تختلف API بين المتصفحات المختلفة، مما يتطلب كتابة الكثير من كود التوافق
❌ ضعف المحددات (Selectors): العثور على العناصر كان مزعجًا

jQuery وُلدت. لقد جعلت JavaScript بسيطة:

javascript

// JavaScript الأصلي (مرهق)
const element = document.getElementById('title')

// jQuery (بسيطة)
const element = $('#title')

3.2 فكرة jQuery: تعديل الصفحة يدويًا

الفكرة الأساسية لـ jQuery هي البرمجة الأمرية (Imperative): تخبر المتصفح "كيف يفعل".

javascript

// العثور على عنصر العنوان
$('#title').text('عنوان جديد')

// العثور على الزر وتعطيله
$('#submit-btn').attr('disabled', true)

// العثور على القائمة وإضافة عنصر
$('ul').append('<li>عنصر جديد</li>')

المشكلة: تحتاج إلى تذكر العناصر الموجودة في الصفحة، وفي كل مرة تتغير فيها البيانات، يجب تحديث جميع العناصر المرتبطة يدويًا.

👇 جرب بنفسك: قارن بين jQuery وطريقة القيادة بالبيانات

jQuery mindset: update DOM everywhere

Cart page count: 1

Checkout button:

Simulated commands

✅ All three places are consistent.

Command log

(No actions yet)

Vue/React mindset: update State only

Cart page count: 1

Checkout button:

You only need one action

When State changes, all three UI locations sync automatically. You do not manually find and update DOM nodes.

Two terms here

DOM: The page structure inside the browser, including buttons, text, and images

State: Page data, such as the cart count

⚠️ نقاط ألم jQuery

تخيل أنك تعمل على سلة تسوق:

javascript

// ينقر المستخدم على "أضف إلى السلة"
function addToCart() {
  cartCount++ // البيانات تتغير

  // يجب عليك تحديث جميع الأماكن المرتبطة يدويًا
  $('#cart-count').text(cartCount) // النقطة الحمراء في الزاوية العلوية
  $('#cart-page-count').text(cartCount) // صفحة سلة التسوق
  $('#checkout-price').text(calculatePrice()) // زر الدفع

  // إذا نسيت مكانًا واحدًا، ستصبح الصفحة غير متسقة!
}

هذه هي تكلفة "نقل الطوب يدويًا": سهولة الخطأ وصعوبة الصيانة.

3.3 انتشار الهواتف المحمولة: ظهور التصميم المتجاوب

حدث تغيير مهم آخر في هذه المرحلة: بدأت الهواتف الذكية والأجهزة اللوحية في الانتشار.

يجب أن تتكيف صفحات الويب مع الشاشات المختلفة. هذا يتطلب تخطيطًا متجاوبًا (Responsive Layout): نفس HTML/CSS يتغير تلقائيًا وفقًا لعرض الشاشة.

أساس التخطيط المتجاوب: استعلامات الوسائط (Media Query)

css

/* شاشة الكمبيوتر (أكبر من 640px) */
@media (min-width: 640px) {
  .container {
    display: flex;
  }
}

/* شاشة الهاتف (أصغر من 640px) */
@media (max-width: 640px) {
  .container {
    display: block;
  }
}

👇 جرب بنفسك: اضبط عرض المتصفح ولاحظ تأثير التخطيط المتجاوب

Viewport width:860 px

Card 1

Card 2

Card 3

Card 4

Card 5

Card 6

Current columns:2

💡 التصميم المتجاوب مثل "إطار الصورة الذكي"

تخيل أنك تشاهد نفس الصورة في غرف مختلفة:

في غرفة المعيشة الكبيرة (شاشة الكمبيوتر)، يمكن عرض الصورة بحجم كبير، مع وجود زينة أخرى بجانبها
في غرفة النوم الصغيرة (شاشة الهاتف)، يجب تصغير الصورة وإخفاء الزينة الأخرى

التخطيط المتجاوب هو "إطار الصورة الذكي"، يضبط طريقة العرض تلقائيًا حسب حجم الغرفة.

4. المرحلة الثالثة: من "نقل الطوب يدويًا" إلى "القيادة بالبيانات" (Vue/React)

🤔 السؤال الأساسي

لماذا احتجنا إلى Vue/React؟ ما هو الفرق الأساسي بينهما وبين jQuery؟ فهم "البرمجة التصريحية" و"القيادة بالبيانات" هو مفتاح إتقان أطر العمل الأمامية الحديثة.

4.1 لماذا احتجنا إلى أطر عمل جديدة؟

تراكمت مشاكل عصر jQuery إلى حد معين:

الكود يصبح فوضويًا بمجرد أن يكبر: عمليات DOM في كل مكان، صعبة الصيانة
سهولة حدوث الأخطاء: نسيان تحديث مكان واحد يجعل الصفحة غير متسقة
صعوبة التعاون: تعديل عدة أشخاص لنفس الملف يؤدي بسهولة إلى تعارضات

الفكرة الأساسية لـ Vue / React: غيّر البيانات فقط، والصفحة تتحدث تلقائيًا.

4.2 فكرة Vue/React: واجهة المستخدم التصريحية (Declarative UI)

jQuery (أمري - Imperative):

javascript

// تخبر المتصفح بكل خطوة يجب القيام بها
$('#title').text('عنوان جديد')
$('#title').css('color', 'red')
$('#title').show()

Vue (تصريحي - Declarative):

javascript

// تخبر المتصفح فقط "ما الذي يجب عرضه"
data() {
  return {
    title: "عنوان جديد",
    color: "red",
    visible: true
  }
}

👇 جرب بنفسك: قارن بين البرمجة الأمرية والتصريحية

🔄Imperative vs DeclarativeTwo programming mindsets: manual operations vs automatic response

ImperativejQuery style - manual operations

// Manually operate the DOM
 $('#count').text(val);
 if (val > 5) $('#msg').show();

Count: 0

Ready.

DeclarativeVue/React style - automatic response

// Bind data only
{{ count }}
 <div v-if="count > 5">...</div>

Count: 0

Framework handles DOM updates automatically.

💡Core idea:Imperative code tells the computer how to do each step. Declarative code tells it the desired result and lets the framework handle the updates.

💡 الأمرية مقابل التصريحية

مثل رسم لوحة:

البرمجة الأمرية: تخبر الرسام "خذ الفرشاة، اغمسها في اللون الأحمر، ارسم دائرة في الإحداثيات (10,10)"
البرمجة التصريحية: تعطي الرسام صورة مباشرة، وتقول "ارسمها هكذا"

Vue/React هي "تصريحية": تصف "كيف تبدو الصفحة"، والإطار يتولى "كيفية رسمها".

4.3 المكونات (Components): كتابة الصفحات مثل تركيب الليغو

أقوى ميزة في Vue / React هي المكونات (Componentization): تقسيم الصفحة إلى "مكعبات بناء" مستقلة.

تخيل أنك تبني بالليغو:

لا تحتاج إلى "نحت كل مكعب من الصفر" (كتابة HTML/CSS من الصفر)
تحتاج فقط إلى "تجميع المكعبات وفقًا للتعليمات" (تركيب المكونات معًا)
كل مكعب مستقل، ويمكنك إعادة استخدامه في مجموعات مختلفة

فوائد المكونات:

إعادة الاستخدام: اكتب مكون "بطاقة منتج" مرة واحدة، واستخدمه 100 مرة
التغليف (Encapsulation): حالة المكون الداخلية لا تؤثر على الآخرين
الصيانة: تعديل مكون واحد يحدّث كل الأماكن التي تستخدمه

💡 مهارات التعرف

رؤية <ComponentName /> → هذا مكون
رؤية import xxx from './xxx.vue' → استيراد مكون
رؤية props: {...} → المعاملات التي يستقبلها المكون
رؤية emit('xxx') → المكون يرسل حدثًا إلى المكون الأب

4.4 SPA: ولادة تطبيقات الصفحة الواحدة

شهد عصر Vue / React تغييرًا مهمًا آخر: من MPA إلى SPA.

MPA (تطبيق متعدد الصفحات):

النقر على رابط → تحديث الصفحة بالكامل → عرض الصفحة الجديدة
مثل تقليب كتاب: في كل مرة تقلب صفحة، يجب أن تغلق الكتاب القديم وتذهب إلى الرف لإحضار كتاب جديد

SPA (تطبيق الصفحة الواحدة):

النقر على رابط → تحديث منطقة المحتوى فقط → الصفحة لا تُعاد تحميلها
مثل الانتقال بين الفصول في نفس الكتاب: فقط امسح المحتوى القديم واكتب المحتوى الجديد

👇 جرب بنفسك: اختبر الفرق بين MPA وSPA

Current page:Home

MPA: each navigation performs a full-page reload.

مزايا SPA:

✅ تجربة سلسة: التنقل بين الصفحات سريع
✅ سهولة إدارة الحالة: المحتوى المدخل وموضع التمرير يبقيان محفوظين
❌ قد تكون الشاشة الأولى بطيئة: يجب تنزيل JavaScript أولاً
❌ SEO يحتاج إلى معالجة إضافية: قد لا تتمكن محركات البحث من التقاط المحتوى (يحتاج SSR/SSG)

5. استراتيجيات العرض: من CSR إلى SSR/SSG

🤔 السؤال الأساسي

هل يتم إنشاء الصفحة على الخادم أم في المتصفح؟ لكل استراتيجية عرض مزاياها وعيوبها، واختيار الاستراتيجية المناسبة أمر حاسم للأداء وSEO.

CSR (العرض من جانب العميل - Client-Side Rendering):

المتصفح ينزّل JavaScript → ينفذ الكود → ينشئ الصفحة
المزايا: تفاعل سلس، ضغط أقل على الخادم
العيوب: بطء الشاشة الأولى، غير مناسب لـ SEO

SSR (العرض من جانب الخادم - Server-Side Rendering):

الخادم ينشئ HTML → يرسله إلى المتصفح → المتصفح يعرضه مباشرة
المزايا: شاشة أولى سريعة، مناسب لـ SEO
العيوب: ضغط كبير على الخادم، تنفيذ معقد

SSG (توليد المواقع الثابتة - Static Site Generation):

إنشاء HTML لجميع الصفحات أثناء البناء (build time)
المزايا: سريع جدًا، ثابت بالكامل، صديق لـ CDN
العيوب: غير مناسب للمحتوى الديناميكي

👇 جرب بنفسك: قارن خصائص استراتيجيات العرض المختلفة

TTFB

450 ms

Time to interactive

1600 ms

SEO friendly

Fair

The page renders only after JavaScript loads and fetches data.

💡 كيف تختار؟

مواقع المحتوى (مدونات، وثائق): يفضل SSG
مواقع ديناميكية تحتاج SEO (متاجر إلكترونية، أخبار): استخدم SSR
أنظمة إدارة داخلية: استخدم CSR
احتياجات مختلطة: فكر في العرض المختلط في Nuxt/Next.js

6. المرحلة الرابعة: الهندسة البرمجية وأدوات البناء (2015s-2020s)

🤔 السؤال الأساسي

لماذا تحتاج الواجهة الأمامية إلى "الهندسة البرمجية"؟ ماذا تفعل أدوات البناء بالضبط؟ فهم الهندسة البرمجية هو ما يجعلك تستوعب سير العمل في مشاريع الواجهة الأمامية الحديثة.

6.1 لماذا نحتاج إلى "الهندسة البرمجية"؟

مشاريع الواجهة الأمامية تكبر أكثر فأكثر، ولم يعد بالإمكان الاعتماد على "إدراج السكربتات يدويًا".

الهندسة البرمجية هي استخدام الأدوات والمعايير لجعل التطوير أكثر كفاءة، والكود أكثر موثوقية، والتعاون أكثر سلاسة.

💡 الهندسة البرمجية = من "الورشة اليدوية" إلى "المصنع الحديث"

تخيل أنك تطبخ في المنزل مقابل إدارة مطعم:

الطبخ في المنزل: تطبخ ما تريد وقتما تريد، حرية كبيرة
إدارة مطعم: تحتاج إلى وصفات موحدة، وإجراءات تشغيل قياسية، ومشتريات موحدة للمواد الخام

تطوير الواجهة الأمامية هو نفسه:

المشاريع الصغيرة: يمكنك الكتابة بأي طريقة
المشاريع الكبيرة: تحتاج إلى معايير كود موحدة، وأدوات أتمتة، وإجراءات قياسية

6.2 أدوات البناء: Webpack → Vite

Webpack (تقليدي):

طريقة العمل: الحزم أولاً، ثم الخدمة
عند البدء: حزم جميع الأكواد → تشغيل الخادم
المشكلة: بطيء. كلما كبر المشروع، كان البدء أبطأ (قد يصل إلى 30 ثانية)

Vite (حديث):

طريقة العمل: الترجمة عند الطلب
عند البدء: لا يحزم، يشغل الخادم مباشرة
أي ملف يطلبه المتصفح، يتم ترجمته في الوقت الفعلي
الميزة: سريع. يبدأ عادةً في أقل من ثانية

عنصر المقارنة	Webpack	Vite	التحسين
البدء البارد	30s+	<1s	أسرع بـ 30 مرة
التحديث الساخن	3-5s	<100ms	أسرع بـ 30 مرة
ملف الإعدادات	مئات الأسطر	عشرات الأسطر	تبسيط كبير

💡 لماذا Vite سريع جدًا؟

Webpack مثل نقل الأثاث بالكامل: تحزم كل شيء أولاً، ثم تخرج.

Vite مثل السفر الخفيف: تحمل فقط الضروريات، وتشتري ما تحتاجه عند الحاجة.

في بيئة التطوير، معظم الوقت تحتاج فقط إلى تعديل بضعة ملفات، وVite يترجم هذه الملفات فقط، لذلك هو سريع بالطبع.

7. مقارنة أطر العمل الرئيسية

🤔 السؤال الأساسي

ما هي خصائص كل من Vue وReact وSvelte وAngular؟ كيف تختار إطار العمل المناسب لك؟ فهم فلسفة تصميم كل منها وسيناريوهات استخدامها هو ما يمكنك من اتخاذ قرار حكيم.

7.1 مقارنة الأطر الأربعة الرئيسية

الخاصية	Vue	React	Svelte	Angular
الفلسفة التصميمية	إطار تقدمي (Progressive)	مكتبة UI	إطار وقت الترجمة (Compile-time)	منصة كاملة
منحنى التعلم	⭐⭐ بسيط	⭐⭐⭐ متوسط	⭐⭐ بسيط	⭐⭐⭐⭐ حاد
الأداء	سريع	سريع	سريع جدًا	سريع
النظام البيئي	مكتمل	الأكثر اكتمالاً	في طور النمو	مكتمل
حجم الحزمة	صغير	متوسط	الأصغر	كبير
السيناريوهات المناسبة	مشاريع صغيرة ومتوسطة	مشاريع كبيرة	متطلبات أداء عالية	تطبيقات مؤسسية
دعم الشركة	Evan You (مستقل)	Meta	مجتمع	Google

7.2 Vue: إطار تقدمي

الفكرة الأساسية: تبنّي تدريجي، يمكنك استخدام جزء منه فقط، أو استخدام المجموعة الكاملة

vue

<template>
  <div>{{ message }}</div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello Vue'
    }
  }
}
</script>

المزايا:

✅ منحنى تعلم سلس، وثائق صينية مكتملة
✅ صيغة القوالب (Template Syntax) بديهية وسهلة الفهم
✅ مكونات الملف الواحد (.vue) هيكلها واضح
✅ مناسبة للتطوير السريع

العيوب:

❌ إدارة الحالة في المشاريع الكبيرة تتطلب تعلمًا إضافيًا لـ Vuex/Pinia
❌ مرونة أقل قليلاً من React

السيناريوهات المناسبة:

تطبيقات ويب صغيرة ومتوسطة
تطوير النماذج الأولية السريعة
فرق ناطقة بالصينية (الوثائق صديقة)

7.3 React: مكتبة UI

الفكرة الأساسية: مسؤولة فقط عن طبقة العرض، والمشاكل الأخرى تترك للمجتمع

jsx

function App() {
  const [message, setMessage] = useState('Hello React')
  return <div>{message}</div>
}

المزايا:

✅ النظام البيئي الأكثر اكتمالاً، مكتبات مكونات غنية
✅ صيغة JSX مرنة وقدرة تعبيرية قوية
✅ أداء DOM الافتراضي (Virtual DOM) ممتاز
✅ مناسبة للمشاريع الكبيرة

العيوب:

❌ منحنى تعلم حاد نسبيًا، يتطلب إتقان مفاهيم إضافية
❌ تحتاج إلى اختيار وتجميع المكتبات المختلفة بنفسك
❌ JSX يحتاج إلى ترجمة (Compilation)، لا يمكن تشغيله مباشرة في المتصفح

السيناريوهات المناسبة:

تطبيقات كبيرة ومعقدة
مشاريع تحتاج إلى نظام بيئي غني
تطوير متعدد المنصات (React Native)

7.4 Svelte: إطار وقت الترجمة

الفكرة الأساسية: لا يوجد DOM افتراضي، يتم تحويل المكونات إلى كود أصلي (Native) فعال أثناء الترجمة

svelte

<script>
  let message = 'Hello Svelte'
</script>

<div>{message}</div>

المزايا:

✅ أداء مثالي (لا توجد تكلفة وقت تشغيل لـ Virtual DOM)
✅ أصغر حجم حزمة
✅ صيغة بسيطة وبديهية
✅ نظام تفاعلي (Reactive) مدعوم بشكل طبيعي

العيوب:

❌ النظام البيئي صغير نسبيًا
❌ حجم المجتمع أقل من Vue/React
❌ مكتبات الطرف الثالث أقل

السيناريوهات المناسبة:

تطبيقات تتطلب أداءً عاليًا جدًا
مشاريع حساسة لحجم الحزمة
فرق مستعدة لتجربة تقنيات جديدة

7.5 Angular: منصة كاملة

الفكرة الأساسية: توفير حل كامل، جاهز للاستخدام فورًا

typescript

@Component({
  selector: 'app-root',
  template: '<div>{{ message }}</div>'
})
export class AppComponent {
  message = 'Hello Angular'
}

المزايا:

✅ وظائف كاملة، التوجيه (Routing) وHTTP والنماذج كلها موجودة
✅ دعم أصلي لـ TypeScript
✅ مناسبة للفرق والمشاريع الكبيرة
✅ معايير كود موحدة

العيوب:

❌ منحنى تعلم حاد
❌ مفاهيم كثيرة، تعقيد عالٍ
❌ حجم الحزمة كبير
❌ غير مناسبة للمشاريع الصغيرة

السيناريوهات المناسبة:

تطبيقات مؤسسية كبيرة
فرق تحتاج إلى معايير صارمة
مشاريع تستخدم بالفعل حزمة TypeScript التقنية

8. الخلاصة: جوهر التطور

تطور تقنيات الواجهة الأمامية، في جوهره، يحل مشكلتين:

8.1 الكفاءة: من اليدوي إلى الآلي

العصر	طريقة التطوير	الكفاءة
2000s	كتابة HTML/CSS/JS يدويًا	⭐
2010s	jQuery + عمليات DOM يدوية	⭐⭐
2020s	Vue/React + القيادة بالبيانات	⭐⭐⭐
الآن	المكونات + الهندسة البرمجية + الأتمتة	⭐⭐⭐⭐⭐

8.2 الحجم: من الفرد إلى الفريق

العصر	حجم المشروع	طريقة التعاون
2000s	بضعة ملفات	يمكن لشخص واحد صيانتها
2010s	عشرات الملفات	فريق صغير، تعارضات متكررة
2020s	مئات الملفات	فريق متوسط، يحتاج إلى معايير
الآن	آلاف الملفات	فريق كبير، يحتاج إلى نظام هندسي كامل

9. خارطة طريق التعلم

9.1 إذا كنت مبتدئًا تمامًا

الخطوة 1: أساسيات HTML/CSS/JavaScript

فهم الركائز الثلاث لصفحات الويب
القدرة على كتابة صفحات ثابتة بسيطة

الخطوة 2: تعلم إطار عمل واحد (نوصي بـ Vue)

فهم فكرة "القيادة بالبيانات"
إتقان تطوير المكونات

الخطوة 3: مشروع عملي

بناء تطبيق صفحة واحدة كامل
التعرف على التوجيه (Routing) وإدارة الحالة (State Management) واستدعاء API

9.2 إذا كانت لديك أساسيات

اتجاهات متقدمة:

الهندسة البرمجية: تعلم Vite/Webpack، فهم عملية البناء
تحسين الأداء: تعلم التحميل الكسول (Lazy Loading)، تقسيم الكود (Code Splitting)، استراتيجيات التخزين المؤقت
TypeScript: إضافة الأنواع (Types) للكود لزيادة الموثوقية
العرض من جانب الخادم: تعلم Nuxt/Next.js لحل مشاكل SEO والشاشة الأولى

10. ما يجب أن تكون قادرًا على التعرف عليه الآن

بعد قراءة هذا الفصل، يجب أن تكون قادرًا على:

✅ فهم سياق وأسباب تطور تقنيات الواجهة الأمامية
✅ التمييز بين خصائص Vue وReact وSvelte وAngular
✅ فهم الفرق بين "البرمجة الأمرية" و"البرمجة التصريحية"
✅ إتقان الفكرة الأساسية لـ "القيادة بالبيانات"
✅ معرفة قيمة تطوير المكونات
✅ فهم سيناريوهات استخدام CSR وSSR وSSG
✅ فهم دور أدوات البناء (Webpack، Vite)
✅ القدرة على اختيار إطار العمل والحزمة التقنية المناسبة للمشروع

💡 تطبيق عملي

عندما تستخدم الذكاء الاصطناعي في مشروعك، يمكنك إخباره بما يلي:

"هذا موقع مدونة يحتاج إلى SEO، استخدم Nuxt (إطار SSR الخاص بـ Vue)"
"هذا نظام إدارة داخلي، استخدم Vue + Element Plus، لا حاجة لـ SSR"
"هذا تطبيق ويب بمتطلبات أداء عالية، فكر في استخدام Svelte"
"المشروع يستخدم React بالفعل، استمر في استخدام مكتبات نظام React البيئي"

جدول المصطلحات

المصطلح	الإنجليزية	شرح مبسط
DOM	Document Object Model	نموذج كائن المستند. تمثيل الصفحة كشجرة كائنات يمكن قراءتها وكتابتها عبر JS.
jQuery	-	مكتبة JS شائعة قديمة، بسّطت عمليات DOM.
Vue/React	-	أطر عمل أمامية حديثة، تعتمد القيادة بالبيانات وتطوير المكونات.
المكون	Component	وحدة UI قابلة لإعادة الاستخدام، مثل الأزرار والبطاقات وشريط التنقل.
MPA	Multi-Page Application	تطبيق متعدد الصفحات. كل انتقال يعيد تحميل الصفحة بالكامل.
SPA	Single-Page Application	تطبيق الصفحة الواحدة. يُحمّل مرة واحدة، والتنقلات اللاحقة لا تعيد تحميل الصفحة.
التوجيه	Routing	إدارة قواعد وعملية التنقل بين الصفحات.
SSR	Server-Side Rendering	العرض من جانب الخادم. الخادم ينشئ HTML ثم يرسله إلى المتصفح.
SSG	Static Site Generation	توليد المواقع الثابتة. عرض مسبق للصفحات كـ HTML ثابت أثناء البناء.
CSR	Client-Side Rendering	العرض من جانب العميل. المتصفح ينشئ الصفحة عبر JavaScript.
Webpack	-	أداة حزم تقليدية، تحزم أولاً ثم تخدم.
Vite	-	أداة بناء حديثة، ترجمة عند الطلب، سرعة فائقة.
التصميم المتجاوب	Responsive Design	تصميم يتكيف تلقائيًا مع أحجام الشاشات المختلفة.
استعلامات الوسائط	Media Query	شرط في CSS، يطبق أنماطًا مختلفة حسب عرض الشاشة.
البرمجة الأمرية	Imperative	إخبار البرنامج "كيف يفعل".
البرمجة التصريحية	Declarative	إخبار البرنامج "ماذا تريد".
القيادة بالبيانات	Data-Driven	تعديل البيانات فقط، والواجهة تتحدث تلقائيًا.
Tree Shaking	-	تحسين هز الشجرة. إزالة الكود غير المستخدم تلقائيًا لتقليل حجم الحزمة.
تقسيم الكود	Code Splitting	تقسيم الكود إلى أجزاء صغيرة متعددة، تُحمّل عند الطلب.

دليل متعمق لأطر العمل الأمامية ​

1. لماذا نهتم بتاريخ تطور الواجهة الأمامية؟ ​

1.1 من "الملصق الإلكتروني" إلى "تطبيق سطح المكتب" ​

1.2 تشبيه من الحياة: بناء منزل ​

2. المرحلة الأولى: صفحات الويب الثابتة و"تقطيع الصور" (2000s) ​

I. The Static Era

2.1 كيف كان هذا العصر؟ ​

2.2 ما هو "تقطيع الصور"؟ ​

3. المرحلة الثانية: عصر jQuery - "نقل الطوب يدويًا" (2010s) ​

3.1 لماذا احتجنا إلى jQuery؟ ​

3.2 فكرة jQuery: تعديل الصفحة يدويًا ​

3.3 انتشار الهواتف المحمولة: ظهور التصميم المتجاوب ​

4. المرحلة الثالثة: من "نقل الطوب يدويًا" إلى "القيادة بالبيانات" (Vue/React) ​

4.1 لماذا احتجنا إلى أطر عمل جديدة؟ ​

4.2 فكرة Vue/React: واجهة المستخدم التصريحية (Declarative UI) ​

4.3 المكونات (Components): كتابة الصفحات مثل تركيب الليغو ​

4.4 SPA: ولادة تطبيقات الصفحة الواحدة ​

5. استراتيجيات العرض: من CSR إلى SSR/SSG ​

6. المرحلة الرابعة: الهندسة البرمجية وأدوات البناء (2015s-2020s) ​

6.1 لماذا نحتاج إلى "الهندسة البرمجية"؟ ​

6.2 أدوات البناء: Webpack → Vite ​

7. مقارنة أطر العمل الرئيسية ​

7.1 مقارنة الأطر الأربعة الرئيسية ​

7.2 Vue: إطار تقدمي ​

7.3 React: مكتبة UI ​

7.4 Svelte: إطار وقت الترجمة ​

7.5 Angular: منصة كاملة ​

8. الخلاصة: جوهر التطور ​

8.1 الكفاءة: من اليدوي إلى الآلي ​

8.2 الحجم: من الفرد إلى الفريق ​

9. خارطة طريق التعلم ​

9.1 إذا كنت مبتدئًا تمامًا ​

9.2 إذا كانت لديك أساسيات ​

10. ما يجب أن تكون قادرًا على التعرف عليه الآن ​

جدول المصطلحات ​

دليل متعمق لأطر العمل الأمامية

1. لماذا نهتم بتاريخ تطور الواجهة الأمامية؟

1.1 من "الملصق الإلكتروني" إلى "تطبيق سطح المكتب"

1.2 تشبيه من الحياة: بناء منزل

2. المرحلة الأولى: صفحات الويب الثابتة و"تقطيع الصور" (2000s)

2.1 كيف كان هذا العصر؟

2.2 ما هو "تقطيع الصور"؟

3. المرحلة الثانية: عصر jQuery - "نقل الطوب يدويًا" (2010s)

3.1 لماذا احتجنا إلى jQuery؟

3.2 فكرة jQuery: تعديل الصفحة يدويًا

3.3 انتشار الهواتف المحمولة: ظهور التصميم المتجاوب

4. المرحلة الثالثة: من "نقل الطوب يدويًا" إلى "القيادة بالبيانات" (Vue/React)

4.1 لماذا احتجنا إلى أطر عمل جديدة؟

4.2 فكرة Vue/React: واجهة المستخدم التصريحية (Declarative UI)

4.3 المكونات (Components): كتابة الصفحات مثل تركيب الليغو

4.4 SPA: ولادة تطبيقات الصفحة الواحدة

5. استراتيجيات العرض: من CSR إلى SSR/SSG

6. المرحلة الرابعة: الهندسة البرمجية وأدوات البناء (2015s-2020s)

6.1 لماذا نحتاج إلى "الهندسة البرمجية"؟

6.2 أدوات البناء: Webpack → Vite

7. مقارنة أطر العمل الرئيسية

7.1 مقارنة الأطر الأربعة الرئيسية

7.2 Vue: إطار تقدمي

7.3 React: مكتبة UI

7.4 Svelte: إطار وقت الترجمة

7.5 Angular: منصة كاملة

8. الخلاصة: جوهر التطور

8.1 الكفاءة: من اليدوي إلى الآلي

8.2 الحجم: من الفرد إلى الفريق

9. خارطة طريق التعلم

9.1 إذا كنت مبتدئًا تمامًا

9.2 إذا كانت لديك أساسيات

10. ما يجب أن تكون قادرًا على التعرف عليه الآن

جدول المصطلحات