البرمجة الوظيفية (Functional Programming)
.
.
البرمجة الوظيفية (Functional Programming) هي واحدة من الأنماط البرمجية اللي بتختلف عن النمط التقليدي اللي بنسميه الـ Imperative Programming.
الفكرة الأساسية في البرمجة الوظيفية إنها بتركز على استخدام الدوال (functions) كعنصر أساسي في كتابة الكود، وبتعتمد على فكرة إن الكود يكون واضح وسهل التتبع، بدون ما نغير الـ state أو البيانات بشكل مباشر.
———
📌 إيه اللي بيميز البرمجة الوظيفية؟
في البرمجة الوظيفية، بنستخدم حاجة اسمها pure functions، ودي دوال بتستقبل مدخلات (inputs) وتطلع مخرجات (outputs) من غير ما تأثر على أي حاجة خارج الدالة نفسها.
يعني الدالة اللي بتشتغل بالطريقة دي، كل مرة تستخدمها بنفس المدخلات، هتطلع نفس النتيجة. ده بيسهل جدًا اختبار الكود والتأكد إنه شغال صح.
كمان في البرمجة الوظيفية بنبعد تمامًا عن فكرة side effects، اللي هي تغيير في البيانات أو الـ state خارج الدالة. وده بيدي الكود ميزة إنه يبقى قابل للتوقع (predictable) وسهل الصيانة.
———
📌 الـ Higher-Order Functions
البرمجة الوظيفية بتعتمد بشكل كبير على نوع خاص من الدوال اسمه Higher-Order Functions. الدوال دي بتستقبل دوال تانية كمدخلات أو بتطلع دوال كمخرجات.
مثلًا في JavaScript عندنا دوال زي map, filter, reduce، ودي أمثلة ممتازة على الـ Higher-Order Functions.
الدوال دي بتخليك تقدر تعمل عمليات معقدة على البيانات بطريقة مختصرة ومنظمة، وبدون ما تكتب كود كتير. مثلًا لو عاوز تعدل قيم معينة في Array، بدل ما تستخدم for loop، ممكن تستخدم map واللي بتخليك تقدر تعيد بناء الـ Array بطريقة أسرع وأسهل.
———
📌 الـ Immutable Data
واحدة من المفاهيم الأساسية كمان في البرمجة الوظيفية هي immutable data، يعني البيانات مبتتغيرش. بدل ما نعدل على نفس الـ Array أو الـ Object، بنرجع نسخة جديدة من البيانات بعد التعديل.
ده بيدي الكود أمان أكتر، وبيمنع الأخطاء اللي ممكن تحصل لما البيانات تتغير بطريقة غير متوقعة.
البرمجة الوظيفية بتتطبق في لغات زي Haskell وElm بشكل كبير، لكن الأفكار دي كمان ممكن تتطبق في لغات زي JavaScript, Python وحتى Java و#C.
———
📌 ليه تستخدم البرمجة الوظيفية؟
- الكود بيكون واضح جدًا وسهل التتبع.
- التقليل من الأخطاء بفضل استخدام الـ pure functions.
- سهولة اختبار الكود.
- دعم الـ parallelism والـ concurrency بشكل أفضل.
———
وفقكم الله لكل خير ☘️
.
.
البرمجة الوظيفية (Functional Programming) هي واحدة من الأنماط البرمجية اللي بتختلف عن النمط التقليدي اللي بنسميه الـ Imperative Programming.
الفكرة الأساسية في البرمجة الوظيفية إنها بتركز على استخدام الدوال (functions) كعنصر أساسي في كتابة الكود، وبتعتمد على فكرة إن الكود يكون واضح وسهل التتبع، بدون ما نغير الـ state أو البيانات بشكل مباشر.
———
📌 إيه اللي بيميز البرمجة الوظيفية؟
في البرمجة الوظيفية، بنستخدم حاجة اسمها pure functions، ودي دوال بتستقبل مدخلات (inputs) وتطلع مخرجات (outputs) من غير ما تأثر على أي حاجة خارج الدالة نفسها.
يعني الدالة اللي بتشتغل بالطريقة دي، كل مرة تستخدمها بنفس المدخلات، هتطلع نفس النتيجة. ده بيسهل جدًا اختبار الكود والتأكد إنه شغال صح.
كمان في البرمجة الوظيفية بنبعد تمامًا عن فكرة side effects، اللي هي تغيير في البيانات أو الـ state خارج الدالة. وده بيدي الكود ميزة إنه يبقى قابل للتوقع (predictable) وسهل الصيانة.
———
📌 الـ Higher-Order Functions
البرمجة الوظيفية بتعتمد بشكل كبير على نوع خاص من الدوال اسمه Higher-Order Functions. الدوال دي بتستقبل دوال تانية كمدخلات أو بتطلع دوال كمخرجات.
مثلًا في JavaScript عندنا دوال زي map, filter, reduce، ودي أمثلة ممتازة على الـ Higher-Order Functions.
الدوال دي بتخليك تقدر تعمل عمليات معقدة على البيانات بطريقة مختصرة ومنظمة، وبدون ما تكتب كود كتير. مثلًا لو عاوز تعدل قيم معينة في Array، بدل ما تستخدم for loop، ممكن تستخدم map واللي بتخليك تقدر تعيد بناء الـ Array بطريقة أسرع وأسهل.
———
📌 الـ Immutable Data
واحدة من المفاهيم الأساسية كمان في البرمجة الوظيفية هي immutable data، يعني البيانات مبتتغيرش. بدل ما نعدل على نفس الـ Array أو الـ Object، بنرجع نسخة جديدة من البيانات بعد التعديل.
ده بيدي الكود أمان أكتر، وبيمنع الأخطاء اللي ممكن تحصل لما البيانات تتغير بطريقة غير متوقعة.
البرمجة الوظيفية بتتطبق في لغات زي Haskell وElm بشكل كبير، لكن الأفكار دي كمان ممكن تتطبق في لغات زي JavaScript, Python وحتى Java و#C.
———
📌 ليه تستخدم البرمجة الوظيفية؟
- الكود بيكون واضح جدًا وسهل التتبع.
- التقليل من الأخطاء بفضل استخدام الـ pure functions.
- سهولة اختبار الكود.
- دعم الـ parallelism والـ concurrency بشكل أفضل.
———
وفقكم الله لكل خير ☘️
❤10👍1
مفهوم الـ Optimistic UI 💯
.
.
إزاي تخلي المستخدم يشوف التطبيق بتاعك سريع حتى لو هو سلحفاة؟
تخيل معايا السيناريو ده: أنت فاتح تطبيق طلبات الأكل، ضغطت على زرار "تأكيد الطلب" أو "Confirm Order"، وفورًا ظهر لك إن الطلب اتبعت واتسجل، وبعدها بثانية كده جالك إشعار إن المطعم بدأ يحضّر الأكل. إحساسك إيه؟ التطبيق سريع، ومفيش أي تأخير.
بس الحقيقة إن الطلب ممكن يكون لسه بيتبعت للسيرفر، ولسه فيه احتمال إنه يفشل، صح؟
هنا بقى بييجي دور الـ Optimistic UI ... تعال ندردش شوية ونفهم إزاي بيشتغل وأهم الاستخدامات.
———
📌 إزاي الـ Optimistic UI بيشتغل؟
بدل ما تستنى الـ API Response، التطبيق بيعمل تحديث فوري للـ UI بافتراض إن العملية هتنجح، وبعدها بيتأكد من السيرفر. لو الـ API رجعت success، مفيش حاجة تتغير لأن المستخدم أصلًا شاف النتيجة المتوقعة. لكن لو حصل فشل، ساعتها بتعمل Rollback وترجع الـ UI للحالة الأصلية، أو تعرض رسالة خطأ.
———
🎯 مثال عملي بسيط
خلينا نقول عندنا تطبيق To-Do List، لما المستخدم يضيف Task جديدة:
- بدل ما تستنى Response من السيرفر، بتضيف الـ Task مباشرة في الـ UI.
- في الخلفية، التطبيق بيبعت الـ Request للسيرفر لحفظ الـ Task في قواعد البيانات (Database).
- لو كل حاجة مشيت تمام، مفيش حاجة هتتغير.
- لو حصل Error، بتعمل Rollback وتشيل الـ Task من الواجهة، أو تعرض رسالة خطأ.
———
📌 أهم استخدامات الـ Optimistic UI:
- الـ Like و Follow في السوشيال ميديا (أكيد لاحظت في بعض المنشورات على لينكدإن لما بتتفاعل معها وتعمل سكرول شوية تظهر رسالة إنه حدث خطأ في التفاعل مع المنشور).
- إضافة منتجات لعربة التسوق في المتاجر الإلكترونية.
- التعديلات الفورية على البيانات بدون Reload.
———
⚠️ إمتى تستخدم الـ Optimistic UI وإمتى تبعد عنه؟
✅ استخدمه لو العملية بنسبة كبيرة جدًا هتنجح، زي إضافة لايك، حفظ تعليق، أو تعديل بيانات المستخدم.
❌ بلاش تستخدمه لو العملية فيها احتمالية فشل كبيرة أو ممكن تسبب مشاكل لو حصل Rollback، زي عمليات الدفع المالية أو مسح بيانات حساسة.
———
🛠 تطبيق عملي باستخدام React
لو بتستخدم الـ React Query، فالموضوع سهل وبسيط، عندك useMutation بتوفر خاصية onMutate عشان تحدث الـ UI قبل ما العملية تحصل، ولو فشلت، بتستخدم onError تعمل Rollback.
———
خلاصة القول
الـ Optimistic UI بيحسّن تجربة المستخدم بشكل كبير، وبيخلي التطبيقات سريعة من وجهة نظر المستخدم. بس لازم تخلي بالك من كل حالات الفشل.
———
وفقكم الله لكل خير 🌿
.
.
إزاي تخلي المستخدم يشوف التطبيق بتاعك سريع حتى لو هو سلحفاة؟
تخيل معايا السيناريو ده: أنت فاتح تطبيق طلبات الأكل، ضغطت على زرار "تأكيد الطلب" أو "Confirm Order"، وفورًا ظهر لك إن الطلب اتبعت واتسجل، وبعدها بثانية كده جالك إشعار إن المطعم بدأ يحضّر الأكل. إحساسك إيه؟ التطبيق سريع، ومفيش أي تأخير.
بس الحقيقة إن الطلب ممكن يكون لسه بيتبعت للسيرفر، ولسه فيه احتمال إنه يفشل، صح؟
هنا بقى بييجي دور الـ Optimistic UI ... تعال ندردش شوية ونفهم إزاي بيشتغل وأهم الاستخدامات.
———
📌 إزاي الـ Optimistic UI بيشتغل؟
بدل ما تستنى الـ API Response، التطبيق بيعمل تحديث فوري للـ UI بافتراض إن العملية هتنجح، وبعدها بيتأكد من السيرفر. لو الـ API رجعت success، مفيش حاجة تتغير لأن المستخدم أصلًا شاف النتيجة المتوقعة. لكن لو حصل فشل، ساعتها بتعمل Rollback وترجع الـ UI للحالة الأصلية، أو تعرض رسالة خطأ.
———
🎯 مثال عملي بسيط
خلينا نقول عندنا تطبيق To-Do List، لما المستخدم يضيف Task جديدة:
- بدل ما تستنى Response من السيرفر، بتضيف الـ Task مباشرة في الـ UI.
- في الخلفية، التطبيق بيبعت الـ Request للسيرفر لحفظ الـ Task في قواعد البيانات (Database).
- لو كل حاجة مشيت تمام، مفيش حاجة هتتغير.
- لو حصل Error، بتعمل Rollback وتشيل الـ Task من الواجهة، أو تعرض رسالة خطأ.
———
📌 أهم استخدامات الـ Optimistic UI:
- الـ Like و Follow في السوشيال ميديا (أكيد لاحظت في بعض المنشورات على لينكدإن لما بتتفاعل معها وتعمل سكرول شوية تظهر رسالة إنه حدث خطأ في التفاعل مع المنشور).
- إضافة منتجات لعربة التسوق في المتاجر الإلكترونية.
- التعديلات الفورية على البيانات بدون Reload.
———
⚠️ إمتى تستخدم الـ Optimistic UI وإمتى تبعد عنه؟
✅ استخدمه لو العملية بنسبة كبيرة جدًا هتنجح، زي إضافة لايك، حفظ تعليق، أو تعديل بيانات المستخدم.
❌ بلاش تستخدمه لو العملية فيها احتمالية فشل كبيرة أو ممكن تسبب مشاكل لو حصل Rollback، زي عمليات الدفع المالية أو مسح بيانات حساسة.
———
🛠 تطبيق عملي باستخدام React
لو بتستخدم الـ React Query، فالموضوع سهل وبسيط، عندك useMutation بتوفر خاصية onMutate عشان تحدث الـ UI قبل ما العملية تحصل، ولو فشلت، بتستخدم onError تعمل Rollback.
———
خلاصة القول
الـ Optimistic UI بيحسّن تجربة المستخدم بشكل كبير، وبيخلي التطبيقات سريعة من وجهة نظر المستخدم. بس لازم تخلي بالك من كل حالات الفشل.
———
وفقكم الله لكل خير 🌿
❤12
الموقع ده هيساعدك تقوي مهاراتك في عالم الـ System Design 💯
.
.
Practice High-Level Design (HLD) with our interactive whiteboard and get AI-powered feedback.
———
https://www.scalemock.com/hld
.
.
System Design Problems 💯
Practice High-Level Design (HLD) with our interactive whiteboard and get AI-powered feedback.
———
https://www.scalemock.com/hld
❤3
الفرق بين gRPC و REST – أيهما أقوى وليه ممكن تحتاج الـ gRPC؟ 🤔
.
.
لفترة طويلة، الـ REST كان كفاية جدًا علشان الـ APIs تتعامل مع بعضها. بس مع الوقت، ظهرت تحديات جديدة، وبدأنا نحتاج حلول أسرع، أخف، وأكتر كفاءة.
هنا ظهر الـ gRPC، بس هل ده معناه إن REST انتهى؟ لا طبعًا، كل واحد له مكانه واستخدامه. تعال نشوف الفرق بينهم وإمتى تستخدم كل واحد منهم...
———
1. طريقة الاتصال
- الـ REST: بيعتمد على HTTP 1.1، وكل Request بيبقى مستقل تمامًا عن اللي قبله. يعني كل مرة بتطلب حاجة، السيرفر بيحتاج يفتح Connection جديد ويرد عليك، وبعدها الـ Connection بيتقفل – لكن لو السيرفر بيدعم Keep-Alive (وهي ميزة في HTTP 1.1)، الـ Connection ممكن يفضل مفتوح لفترة، وده بيقلل المشكلة شوية. بس برضو، HTTP 1.1 مش بيدعم Multiplexing.
- الـ gRPC: بيستخدم HTTP/2، وده بيسمح بأنه يعمل Multiplexing، يعني يقدر يبعت أكتر من طلب في نفس الـ Connection بدون ما يستنى كل طلب يخلص الأول. النتيجة؟ أداء أسرع واستهلاك أقل للـ Resources
———
2. نقل البيانات
- الـ REST: بيعتمد على JSON في أغلب الحالات، وده فورمات سهل القراءة بس مش الأمثل من حيث السرعة أو حجم البيانات. لكن REST مش مقتصر على JSON؛ ممكن تستخدم XML أو حتى Plain Text لو عايز، بس JSON هو الأكثر شيوعًا.
- الـ gRPC: بيعتمد على Protocol Buffers (Protobuf)، وهو Binary Format مضغوط جدًا، وأسرع بكتير في الـ Serialization/Deserialization من JSON
———
3. الأداء
- الـ REST: بيستهلك Bandwidth أعلى بسبب الـ JSON (أو أي Text Format) والـ Headers الكبيرة اللي في كل Request.
- الـ gRPC: أخف وأسرع لأنه بيستخدم Binary Encoding وبيحافظ على Connection مفتوح طول الجلسة.
———
4. الـ Code Generation
- الـ REST: لو عايز تكتب Client، لازم تبنيه يدويًا وتتعامل مع الـ HTTP Requests بنفسك.
- الـ gRPC: بيديك Code Generation جاهز بلغات كتير (JavaScript, Python, Go, etc.)، يعني تقدر تكتب الـ API مرة واحدة بس والـ Clients في لغات مختلفة تستهلكها بسهولة.
———
5. دعم الـ Streaming
- الـ REST: مش بيدعم الـ Streaming بشكل Native، ولو عايز تعمل حاجة شبه كده هتحتاج حلول زي WebSockets. لكن لو بتستخدم HTTP/2 مع REST، ممكن تستفيد من Server-Sent Events كحل جزئي، بس ده مش شائع.
- الـ gRPC: بيدعم Bi-directional Streaming، يعني الكلاينت والسيرفر يقدروا يبعتوا بيانات لبعض بشكل متزامن من غير ما يستنوا بعض.
———
6. التوافقية مع الـ Browsers
- الـ REST: بيشتغل في أي مكان، أي متصفح، وأي بيئة بدون مشاكل.
- الـ gRPC: ما بيشتغل مباشرة في المتصفح لأنه بيعتمد على HTTP/2 و Protobuf، لكن ممكن تدمجه مع gRPC-Web علشان تتعامل مع المتصفحات.
———
📌 إمتى تستخدم REST؟
✅ لو الـ API بتاعك هيشتغل مع المتصفحات مباشرة.
✅ لو عايز حل سهل، موثق كويس، ومعروف عند أغلب المطورين.
✅ لو بتتعامل مع سيرفرات مش بتدعم gRPC أو مش عايز تبني حاجة معقدة.
———
📌 إمتى تستخدم gRPC؟
🚀 لو عندك Microservices Architecture وعايز أداء سريع واستهلاك قليل.
🚀 لو بتتعامل مع Mobile Apps أو IoT Devices وعايز تقلل الـ Bandwidth.
🚀 لو عايز تعمل Real-time Communication بين الـ Services.
———
الـ REST مش رايح في أي حتة، ولسه مناسب لمعظم الاستخدامات. لكن لو بتبني سيستم معقد، وعايز كفاءة أعلى، وخصوصًا لو عندك Microservices أو High-performance Systems، الـ gRPC ممكن يكون الحل الأمثل لك.
.
.
لفترة طويلة، الـ REST كان كفاية جدًا علشان الـ APIs تتعامل مع بعضها. بس مع الوقت، ظهرت تحديات جديدة، وبدأنا نحتاج حلول أسرع، أخف، وأكتر كفاءة.
هنا ظهر الـ gRPC، بس هل ده معناه إن REST انتهى؟ لا طبعًا، كل واحد له مكانه واستخدامه. تعال نشوف الفرق بينهم وإمتى تستخدم كل واحد منهم...
———
1. طريقة الاتصال
- الـ REST: بيعتمد على HTTP 1.1، وكل Request بيبقى مستقل تمامًا عن اللي قبله. يعني كل مرة بتطلب حاجة، السيرفر بيحتاج يفتح Connection جديد ويرد عليك، وبعدها الـ Connection بيتقفل – لكن لو السيرفر بيدعم Keep-Alive (وهي ميزة في HTTP 1.1)، الـ Connection ممكن يفضل مفتوح لفترة، وده بيقلل المشكلة شوية. بس برضو، HTTP 1.1 مش بيدعم Multiplexing.
- الـ gRPC: بيستخدم HTTP/2، وده بيسمح بأنه يعمل Multiplexing، يعني يقدر يبعت أكتر من طلب في نفس الـ Connection بدون ما يستنى كل طلب يخلص الأول. النتيجة؟ أداء أسرع واستهلاك أقل للـ Resources
———
2. نقل البيانات
- الـ REST: بيعتمد على JSON في أغلب الحالات، وده فورمات سهل القراءة بس مش الأمثل من حيث السرعة أو حجم البيانات. لكن REST مش مقتصر على JSON؛ ممكن تستخدم XML أو حتى Plain Text لو عايز، بس JSON هو الأكثر شيوعًا.
- الـ gRPC: بيعتمد على Protocol Buffers (Protobuf)، وهو Binary Format مضغوط جدًا، وأسرع بكتير في الـ Serialization/Deserialization من JSON
———
3. الأداء
- الـ REST: بيستهلك Bandwidth أعلى بسبب الـ JSON (أو أي Text Format) والـ Headers الكبيرة اللي في كل Request.
- الـ gRPC: أخف وأسرع لأنه بيستخدم Binary Encoding وبيحافظ على Connection مفتوح طول الجلسة.
———
4. الـ Code Generation
- الـ REST: لو عايز تكتب Client، لازم تبنيه يدويًا وتتعامل مع الـ HTTP Requests بنفسك.
- الـ gRPC: بيديك Code Generation جاهز بلغات كتير (JavaScript, Python, Go, etc.)، يعني تقدر تكتب الـ API مرة واحدة بس والـ Clients في لغات مختلفة تستهلكها بسهولة.
———
5. دعم الـ Streaming
- الـ REST: مش بيدعم الـ Streaming بشكل Native، ولو عايز تعمل حاجة شبه كده هتحتاج حلول زي WebSockets. لكن لو بتستخدم HTTP/2 مع REST، ممكن تستفيد من Server-Sent Events كحل جزئي، بس ده مش شائع.
- الـ gRPC: بيدعم Bi-directional Streaming، يعني الكلاينت والسيرفر يقدروا يبعتوا بيانات لبعض بشكل متزامن من غير ما يستنوا بعض.
———
6. التوافقية مع الـ Browsers
- الـ REST: بيشتغل في أي مكان، أي متصفح، وأي بيئة بدون مشاكل.
- الـ gRPC: ما بيشتغل مباشرة في المتصفح لأنه بيعتمد على HTTP/2 و Protobuf، لكن ممكن تدمجه مع gRPC-Web علشان تتعامل مع المتصفحات.
———
📌 إمتى تستخدم REST؟
✅ لو الـ API بتاعك هيشتغل مع المتصفحات مباشرة.
✅ لو عايز حل سهل، موثق كويس، ومعروف عند أغلب المطورين.
✅ لو بتتعامل مع سيرفرات مش بتدعم gRPC أو مش عايز تبني حاجة معقدة.
———
📌 إمتى تستخدم gRPC؟
🚀 لو عندك Microservices Architecture وعايز أداء سريع واستهلاك قليل.
🚀 لو بتتعامل مع Mobile Apps أو IoT Devices وعايز تقلل الـ Bandwidth.
🚀 لو عايز تعمل Real-time Communication بين الـ Services.
———
الـ REST مش رايح في أي حتة، ولسه مناسب لمعظم الاستخدامات. لكن لو بتبني سيستم معقد، وعايز كفاءة أعلى، وخصوصًا لو عندك Microservices أو High-performance Systems، الـ gRPC ممكن يكون الحل الأمثل لك.
❤9
بفضل الله تم نشر مقال جديد في مدونة Level Up Coding على منصة Medium 🔥
📌 Pagination is the technique of dividing large datasets into smaller, manageable chunks (pages) to improve performance, usability, and content discoverability.
https://levelup.gitconnected.com/page-pagination-offset-vs-cursor-pagination-a-practical-guide-for-developers-seo-professionals-489624914905
Page Pagination (Offset) vs Cursor Pagination: A Practical Guide for Developers & SEO Professionals
📌 Pagination is the technique of dividing large datasets into smaller, manageable chunks (pages) to improve performance, usability, and content discoverability.
https://levelup.gitconnected.com/page-pagination-offset-vs-cursor-pagination-a-practical-guide-for-developers-seo-professionals-489624914905
❤6
مقياس طويق لتحديد الميول التقني💡
يساعدك هذا الاختبار من معرفة المجالات المناسبة لميولك التقنيّة، بين أهم المجالات التقنيّة الأكثر احتياجًا في سوق العمل وتقنيات المستقبل.
https://assessment.tuwaiq.edu.sa
مقياس طويق لتحديد الميول التقني
يساعدك هذا الاختبار من معرفة المجالات المناسبة لميولك التقنيّة، بين أهم المجالات التقنيّة الأكثر احتياجًا في سوق العمل وتقنيات المستقبل.
❤4
الفرق بين SSR و CSR و SSG 💯
.
.
في عالم الويب، لما بتيجي تختار الطريقة اللي هيتم بها عمل (Render) لصفحات الموقع بتاعك، أكيد قابلت المصطلحات دي:
📌 الـ Server-Side Rendering (SSR)
📌 الـ Client-Side Rendering (CSR)
📌 الـ Static Site Generation (SSG)
تعال ندردش شوية ونعرف الفرق بينهم وإمتى تختار كل واحد منهم وشوية تفاصيل لذيذة...
———
📍 الـ Server-Side Rendering (SSR):
الـ SSR يعني الصفحة بيحصل لها "Rendering" بالكامل في السيرفر قبل ما توصل للمستخدم. يعني أول لما المستخدم يفتح الموقع، السيرفر بيعمل معالجة للبيانات ويرجع صفحة HTML كاملة.
✅ مميزاته:
- أسرع في أول تحميل للصفحة (First Contentful Paint)، لأن الصفحة بتوصل جاهزة.
- ممتاز للـ SEO، لأن محركات البحث زي Google بتقدر تفهم الصفحة بسهولة.
- مفيد جدًا لو عندك محتوى بيتغير كتير أو بناءً على بيانات المستخدم (زي الصفحات الشخصية أو الـ Dashboards).
❌ عيوبه:
- وقت استجابة السيرفر (Server Response Time) ممكن يبقى طويل مع الضغط الكبير.
- السيرفر نفسه محتاج يبقى قوي عشان يقدر يتعامل مع عدد المستخدمين.
⚡️ أمثلة:
- مواقع الأخبار اللي محتواها بيحتاج تحديث لحظي.
- مواقع التجارة الإلكترونية زي Amazon (محتوى متغير ومهم للـ SEO).
———
📍 الـ Client-Side Rendering (CSR):
في الـ CSR الـ Render بيحصل في جهاز المستخدم. يعني السيرفر بيبعت ملف HTML بسيط مع JavaScript، والـ JavaScript دي بتتكفل بكل حاجة بعد كده.
✅ مميزاته:
- أسرع بعد أول تحميل للصفحة، لأن الـ JavaScript بتحول التطبيق لحاجة ديناميكية وسريعة.
- مناسب جدًا للـ SPAs (Single Page Applications).
- تقليل العبء على السيرفر مقارنة بـ SSR.
❌ عيوبه:
- الـ SEO ضعيف شوية، لأن محركات البحث ساعات بتواجه صعوبة في قراءة المحتوى.
- أول تحميل للصفحة ممكن يبقى بطيء (Initial Load Time) لأن الجهاز بيحتاج يحمّل كل الـ JavaScript.
⚡️ أمثلة:
- تطبيقات زي Gmail أو Trello اللي المستخدم بيتفاعل معاها كتير بعد التحميل الأول.
- أي حاجة فيها Dynamic Interactions كتير.
———
📍 الـ 3. Static Site Generation (SSG):
الـ SSG يعني كل الصفحات بيحصل لها "Render" مرة واحدة أثناء الـ Build Time (وقت بناء الموقع). والصفحات دي بتتبعت للمستخدم جاهزة من غير معالجة إضافية.
✅ مميزاته:
- أسرع حاجة في التحميل (Load Time) لأن الصفحة ثابتة وجاهزة.
- ممتاز جدًا للـ SEO.
- مفيش عبء على السيرفر تقريبًا، لأن الصفحات كلها جاهزة وموجودة على CDN (شبكة توصيل المحتوى).
❌ عيوبه:
- مش عملي للمواقع اللي محتواها بيتغير باستمرار (Dynamic Content).
- لو عندك عدد ضخم من الصفحات، وقت الـ Build هيبقى طويل جدًا.
⚡️ أمثلة:
- المدونات (Blogs) زي Gatsby أو Hugo.
- المواقع اللي محتواها ثابت زي المواقع التعريفية (Portfolio Websites).
———
📌 إمتى تستخدم إيه؟
- الـ SSR: لو محتاج محتوى ديناميكي مع SEO ممتاز.
- الـ CSR: لو بتعمل SPA ومش محتاج SEO قوي.
- الـ SSG: لو عندك محتوى ثابت وعايز سرعة عالية في التحميل.
.
.
في عالم الويب، لما بتيجي تختار الطريقة اللي هيتم بها عمل (Render) لصفحات الموقع بتاعك، أكيد قابلت المصطلحات دي:
📌 الـ Server-Side Rendering (SSR)
📌 الـ Client-Side Rendering (CSR)
📌 الـ Static Site Generation (SSG)
تعال ندردش شوية ونعرف الفرق بينهم وإمتى تختار كل واحد منهم وشوية تفاصيل لذيذة...
———
📍 الـ Server-Side Rendering (SSR):
الـ SSR يعني الصفحة بيحصل لها "Rendering" بالكامل في السيرفر قبل ما توصل للمستخدم. يعني أول لما المستخدم يفتح الموقع، السيرفر بيعمل معالجة للبيانات ويرجع صفحة HTML كاملة.
✅ مميزاته:
- أسرع في أول تحميل للصفحة (First Contentful Paint)، لأن الصفحة بتوصل جاهزة.
- ممتاز للـ SEO، لأن محركات البحث زي Google بتقدر تفهم الصفحة بسهولة.
- مفيد جدًا لو عندك محتوى بيتغير كتير أو بناءً على بيانات المستخدم (زي الصفحات الشخصية أو الـ Dashboards).
❌ عيوبه:
- وقت استجابة السيرفر (Server Response Time) ممكن يبقى طويل مع الضغط الكبير.
- السيرفر نفسه محتاج يبقى قوي عشان يقدر يتعامل مع عدد المستخدمين.
⚡️ أمثلة:
- مواقع الأخبار اللي محتواها بيحتاج تحديث لحظي.
- مواقع التجارة الإلكترونية زي Amazon (محتوى متغير ومهم للـ SEO).
———
📍 الـ Client-Side Rendering (CSR):
في الـ CSR الـ Render بيحصل في جهاز المستخدم. يعني السيرفر بيبعت ملف HTML بسيط مع JavaScript، والـ JavaScript دي بتتكفل بكل حاجة بعد كده.
✅ مميزاته:
- أسرع بعد أول تحميل للصفحة، لأن الـ JavaScript بتحول التطبيق لحاجة ديناميكية وسريعة.
- مناسب جدًا للـ SPAs (Single Page Applications).
- تقليل العبء على السيرفر مقارنة بـ SSR.
❌ عيوبه:
- الـ SEO ضعيف شوية، لأن محركات البحث ساعات بتواجه صعوبة في قراءة المحتوى.
- أول تحميل للصفحة ممكن يبقى بطيء (Initial Load Time) لأن الجهاز بيحتاج يحمّل كل الـ JavaScript.
⚡️ أمثلة:
- تطبيقات زي Gmail أو Trello اللي المستخدم بيتفاعل معاها كتير بعد التحميل الأول.
- أي حاجة فيها Dynamic Interactions كتير.
———
📍 الـ 3. Static Site Generation (SSG):
الـ SSG يعني كل الصفحات بيحصل لها "Render" مرة واحدة أثناء الـ Build Time (وقت بناء الموقع). والصفحات دي بتتبعت للمستخدم جاهزة من غير معالجة إضافية.
✅ مميزاته:
- أسرع حاجة في التحميل (Load Time) لأن الصفحة ثابتة وجاهزة.
- ممتاز جدًا للـ SEO.
- مفيش عبء على السيرفر تقريبًا، لأن الصفحات كلها جاهزة وموجودة على CDN (شبكة توصيل المحتوى).
❌ عيوبه:
- مش عملي للمواقع اللي محتواها بيتغير باستمرار (Dynamic Content).
- لو عندك عدد ضخم من الصفحات، وقت الـ Build هيبقى طويل جدًا.
⚡️ أمثلة:
- المدونات (Blogs) زي Gatsby أو Hugo.
- المواقع اللي محتواها ثابت زي المواقع التعريفية (Portfolio Websites).
———
📌 إمتى تستخدم إيه؟
- الـ SSR: لو محتاج محتوى ديناميكي مع SEO ممتاز.
- الـ CSR: لو بتعمل SPA ومش محتاج SEO قوي.
- الـ SSG: لو عندك محتوى ثابت وعايز سرعة عالية في التحميل.
❤11
Stop writing CSS like it's 2015
Modern CSS code snippets, side by side with the old hacks they replace. Every technique you still Google has a clean, native replacement now.
https://modern-css.com
❤4