10 Best GitHub Repositories to Learn Node.js (2025) 💯

1- Learn Node.js – A Beginner-Friendly Guide
https://github.com/manthanank/learn-nodejs

2- Node.js Best Practices
https://github.com/goldbergyoni/nodebestpractices

3- Node.js Projects
https://github.com/MAshrafM/NodeJS_Projects

4- JavaScript Algorithms
https://github.com/trekhleb/javascript-algorithms

5- Awesome Node.js
https://github.com/sindresorhus/awesome-nodejs

6- Node.js Full Stack Tutorial
https://github.com/Subham-Maity/node-js-full-stack-tutorial

7- The Node.js Master Class
https://github.com/pirple/The-NodeJS-Master-Class

8- Learn You Node
https://github.com/workshopper/learnyounode

9- Express.js Boilerplate
https://github.com/hagopj13/node-express-boilerplate

10- GraphQL Starter Kit
https://github.com/kriasoft/graphql-starter-kit

Operating Systems Course for Beginners 🚀

This course will give you a comprehensive understanding of how operating systems function and manage resources.

https://youtu.be/yK1uBHPdp30

Professional English for Software Engineer

This program is designed to provide you with the knowledge, skills, and tools necessary to become a highly effective professional communicator.

https://app.manara.tech/learning/36

ليه لازم تستخدم الـ Module Bundler؟ 🤔
.
.
لما تبدأ مشروع ويب جديد، الأمور في الأول بتكون بسيطة وسهلة، مجرد كام ملف HTML و CSS و JavaScript، وكل حاجة شغالة تمام.

لكن مع الوقت، ومع إضافة ميزات جديدة، بتبدأ الأمور تتعقد تدريجيًا، وتلاقي نفسك بتواجه مشاكل زي بطء التحميل أو صعوبة في تنظيم الكود...

والحل السحري لكل المشاكل دي هو الـ Module Bundler... تعال نوضح الموضوع ببساطة...💯

———

إيه هو الـ Module Bundler؟ 🛠

ببساطة، هو أداة بتاخد كل الملفات اللي بتستخدمها في مشروعك (JS, CSS, Images... إلخ)، وتظبطها وتجمعهم في ملف واحد أو مجموعة ملفات صغيرة ومنظمة، بحيث تكون جاهزة للتشغيل على المتصفح بكفاءة عالية.

من أشهر الـ Bundlers اللي ممكن تستخدمهم:

- Webpack
- Vite
- Parcel
- Rollup

———

ليه تستخدم الـ Module Bundler؟ 🤷‍♂️

1- تحسين الأداء (Performance Optimization) 🚀

- بيعمل Minification للكود، يعني بيشيل المسافات والتعليقات الزايدة، فحجم الملف بيصغر ويتحمّل أسرع.
- بيعمل Tree Shaking، يعني بيشيل أي كود مش مستخدم من المشروع علشان يبقى خفيف.


2- تقليل عدد الـ Requests 📦

بدل ما المتصفح يطلب 100 ملف JavaScript و CSS، الـ Bundler بيحطهم في ملف واحد أو كام ملف قليلين، فالصفحة تفتح أسرع.


3- التعامل مع الـ Dependencies بسهولة 🔗

لو بتستخدم مكتبات زي React أو Vue، الـ Bundler بينظمها ويدمجها في الكود بذكاء.


4- التوافق مع جميع المتصفحات 🌐

بيحول الكود الحديث لكود قديم مفهوم للمتصفحات القديمة باستخدام أدوات زي Babel.


5- سهولة تقسيم الكود (Code Splitting) 🧩

ممكن تحمل أجزاء معينة من الكود لما تحتاجها بس، بدل ما تحمل كل حاجة مرة واحدة، وده بيسرّع الصفحة.


6- دعم الـ Hot Reloading 🔄

مع أدوات التطوير اللي بتيجي مع الـ Bundler (زي Vite أو Webpack Dev Server)، لما تعدل الكود الصفحة بتتحدث لوحدها من غير ما تعمل Refresh.


7- سهولة التعامل مع الملفات المختلفة 🎨

تقدر تستخدم CSS و SCSS وتضيف صور وخطوط بسهولة عن طريق إعدادات الـ Bundler زي الـ Loaders في Webpack.

———

امتى ممكن تستغنى عن الـ Bundler؟ ❌

لو مشروعك صغير جدًا، زي صفحة HTML بسيطة مع شوية CSS و JS، ممكن تشتغل من غير Bundler. لكن لو المشروع كبر ودخل فيه مكتبات أو أكواد كتير، هتحتاجه جدًا.

———

خلاصة الكلام 🎯

استخدام Module Bundler بيساعدك في:

✅ تحسين الأداء وتسريع التحميل.
✅ تنظيم المشروع وتقليل المشاكل.
✅ توافق أفضل مع المتصفحات.
✅ تجربة تطوير أسهل وأسرع.

———

وفقكم الله لكل خير 🌿

لو شغال بـ React، أكيد سمعت عن useCallback، بس هل فعلًا محتاج تستخدمه؟ 🤔

في المقال ده، هتفهم الـ useCallback بطريقة بسيطة، وإزاي تستخدمه صح عشان تحسن أداء الكود بتاعك بدون تعقيد. 🚀

——-

Simplifying React Hooks: useCallback 💯

📍 Dev Community
https://dev.to/alisamir/simplifying-react-hooks-usecallback-46pp

📍 Medium
https://medium.com/@dev.alisamir/simplifying-react-hooks-usecallback-bb03cf54a641

أهم 25 دالة للتعامل مع الـ Strings في JavaScript 💯
.
.

25 JavaScript String Methods Cheat Sheet - Part 1 💡

1. length
2. charAt()
3. charCodeAt()
4. toUpperCase()
5. toLowerCase()
6. slice()
7. substring()
8. trim()
9. trimStart()
10. trimEnd()
11. String.concat()
12. endsWith()

———

وفقكم الله لكل خير 🌿

دردشة سريعة عن الـ Shadow DOM 💡
.
.
تخيل معايا أنك شغال على مشروع ضخم، وعامل Components Modular، بس فجأة حصلت كارثة! الـ CSS اللي كتبته لـمكون (Component) معين بقى بيأثر على مكونات (Components) تانية في الصفحة، والـ JavaScript بدأ يدخل في متاهات بسبب الـ Global Scope. الحل؟ هنا بييجي دور Shadow DOM!

تعال ندردش شوية عن Shadow DOM، إزاي بيشتغل، ليه هو مهم، وإزاي تستخدمه عمليًا في مشاريعك...🔥

———

📍 LinkedIn

https://www.linkedin.com/posts/dev-alisamir_webdeveloper-webdevelopment-devabrguide-activity-7303859163757957121-bwdh

📍 Qabilah

https://qabilah.com/posts/pXMvwi8VKXk

📍 Facebook

https://www.facebook.com/share/p/1A8EL2kmMj

———

وفقكم الله لكل خير 🌿

الـ Asynchronous Programming في JavaScript ⚙️
.
.
البرمجة فيها نوعين أساسيين: Synchronous و Asynchronous، ولما نفهم الفرق بينهم، هيبقى أسهل نعرف ليه الـ Asynchronous مهم جدًا.

📌 الـ Synchronous Programming:

ده يعني إن الكود بيتنفذ خطوة بخطوة، بمعنى إن الكود مبيكملش تنفيذ أي خطوة تانية إلا لما الخطوة اللي قبلها تخلص. يعني لو عندك عملية بتاخد وقت زي إنك بتحمل بيانات من السرفر عن طريق الـ API، الكود هيفضل مستني لحد ما البيانات تتحمل قبل ما يكمل باقي التنفيذ.

📌 الـ Asynchronous Programming:

أما في البرمجة الـ Asynchronous، الكود يقدر ينفذ حاجات كتير في نفس الوقت من غير ما يستنى العملية الطويلة تخلص. يعني لو عندك عملية زي تحميل البيانات من السرفر، الكود ممكن يستمر في تنفيذ أكواد تانية، ولما البيانات تتحمل، الكود هيعرف ويتعامل مع النتيجة.

———

📌 إزاي الكلام ده بيحصل في JavaScript؟

في JavaScript، عندنا طريقتين رئيسيتين للتعامل مع الـ asynchronous programming

🔻 الـ Callbacks
🔻 الـ Promises

(وطبعًا async/await اللي هو تحسين للـ Promises)

———

📌 الـ Callbacks

أول طريقة للتعامل مع الـ asynchronous programming كانت عن طريق الـ Callbacks. الفكرة ببساطة إنك بتمرر دالة معينة كـ "callback" للكود اللي بيتنفذ، ولما الكود ده يخلص، الدالة دي بتشتغل.

لكن الـ callbacks بتتحول بسرعة لكود معقد جدًا لما يكون عندك عمليات كتير وبتحتاج تكتب حاجات كتير جوة بعضها، وده اللي بنسميه Callback Hell.

📌 الحل: الـ Promises

هنا بيجي دور الـ Promises، اللي هي طريقة جديدة وأكثر تنظيمًا للتعامل مع العمليات الـ asynchronous. الـ Promise هو في الأساس "وعد" إن العملية هتخلص في المستقبل.

الـ Promise بيكون ليه 3 حالات:

🔻 حالة الـ Pending: يعني العملية لسه مخلصتش.
🔻 حالة الـ Fulfilled: يعني العملية نجحت وطلعت النتيجة.
🔻 حالة الـ Rejected: يعني العملية فشلت وفيه خطأ حصل.

لما العملية تخلص بنجاح، الـ Promise بيتحول لحالة "fulfilled"، ولو العملية فشلت بيتحول لحالة "rejected".

———

خلينا نشوف مثال عشان نفهم الكلام ده بشكل أوضح. هنفترض إننا عايزين نحاكي عملية استرجاع بيانات من الـ API.

const fetchData = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const dataAvailable = true;

      if (dataAvailable) {
        resolve("Data retrieved successfully!");
      } else {
        reject("Error: Unable to retrieve data.");
      }
    }, 3000);
  });
};

fetchData()
  .then((result) => console.log(result))
  .catch((error) => console.log(error));

في الكود ده، الدالة fetchData بترجع Promise. داخل الـ Promise، بنستخدم إما resolve لو العملية نجحت أو reject لو حصل خطأ.

باستخدام then، بنقدر نتعامل مع النتيجة لو العملية نجحت، ولو حصل خطأ، الـ catch بتساعدنا في التعامل معاه.

———

📌 الـ Async/Await

علشان نخلي الكود أبسط وأوضح، ظهر حاجة اسمها async/await اللي بتشتغل على الـ Promises بس بشكل مبسط جدًا وبتخلي الكود يبان كأنه synchronous.

نفس المثال اللي اللي فات نقدر نكتبه بطريقة async/await بالشكل ده:

const fetchData = async () => {
  try {
    const result = await new Promise((resolve, reject) => {
      setTimeout(() => {
        const dataAvailable = true;
        if (dataAvailable) {
          resolve("Data retrieved successfully!");
        } else {
          reject("Error: Unable to retrieve data.");
        }
      }, 3000);
    });
    console.log(result);
  } catch (error) {
    console.log(error);
  }
};

fetchData();

الميزة هنا إننا استخدمنا await عشان نستنى النتيجة من الـ Promise وكأن العملية دي synchronous، لكن في الحقيقة الكود شغال بطريقة asynchronous.

وبدل ما نستخدم then و catch، استخدمنا try و catch علشان نتعامل مع النجاح أو الفشل.

———

📌 ليه تستخدم الـ Promises والـ Async/Await؟

✅ تنظيم الكود: الكود بيبقى أنضف وأبسط في الفهم مقارنة بالـ Callbacks.
✅ الـ Error Handling أفضل: التعامل مع الأخطاء بقى أسهل باستخدام try/catch.
✅ لما يكون عندك مشروع كبير، الـ async/await هيساعدك في إدارة الأكواد الطويلة والمعقدة بسهولة.

———

وفقكم الله لكل خير 🌿

يعني إيه Bearer Token وإزاي بيشتغل؟ 🤔

.
.
خليني أسألك سؤال... لما تدخل أي موقع ويطلب منك تسجيل الدخول، هل كل مرة بتفتح الموقع بيطلب منك اسم المستخدم والباسورد من الأول؟ "في الغالب" لا، لأنه بعد ما بتسجّل دخول بيتم إصدار Token تستخدمه بدل ما تدخل بياناتك كل مرة.

هنا بقى بييجي دور الـ Bearer Token... ده واحد من أشهر أنواع الـ Access Tokens واللي بيتم استخدامه في الـ authentication (وغالبًا مع معيار OAuth 2.0)، وده معناه إنك لما تبعت request لأي API محمي (Protected)، بدل ما تبعت بيانات تسجيل الدخول كل مرة، بتبعت الـ Token بيأكد إنك شخص موثوق.

بس خليني أقولك إن استخدام Bearer Token محتاج شوية تفاصيل لازم تبقى فاهمها كويس، لأن أي غلطة في التعامل معاه ممكن تخلي بياناتك عرضة للإختراق.
.
.
لا تنسوا أهلنا المستضعفين من الدعاء.
———

📌 إزاي الـ Bearer Token بيشتغل؟

الموضوع بيتم على 3 مراحل:

1- تسجيل الدخول: لما المستخدم بيدخل بياناته الصح، السيرفر بيعمله authenticate، وبعدها بيصدرله Bearer Token (ممكن يكون مشفر زي JWT).

2- استخدام الـ Token: في كل request بعد كده، الـ Token بيتبعت مع الهيدر (Header) في الـ Authorization بالشكل ده:

Authorization: Bearer YOUR_ACCESS_TOKEN

وده معناه إن أي حد معاه الـ Token يقدر يستخدمه للوصول للـ API

3- التحقق من الـ Token: السيرفر بيستلم الـ Token ويشوف إذا كان صالح ولا لا (ممكن بمفتاح تشفير لو مشفر)، ولو كان صحيح، بيكمل تنفيذ الطلب، ولو كان منتهي أو غير صحيح، بيرد بخطأ Unauthorized (401).

———

📌 طب ليه اسمه Bearer Token؟

كلمة Bearer معناها "حامل"، وده لأن أي حد معاه الـ Token ده يقدر يستخدمه من غير ما يثبت هويته بأي حاجة تانية. بمعنى إن الـ Token لو اتسرق، اللي سرقه هيقدر يستخدمه كأنه أنت بالضبط.

———

📌 إيه المشاكل الأمنية اللي ممكن تواجهك مع Bearer Token؟

💀 الـ Token Theft: لو حد قدر يحصل على الـ Token بتاعك، يقدر يستخدمه كأنه أنت، ومفيش extra verification زي الـ refresh tokens أو OAuth flows اللي بتتأكد إن الشخص فعلًا هو المستخدم الحقيقي.

⌛️ الـ Expiration Issues: لو الـ Token مش بيخلص بسرعة، يبقى عندك مشكلة، لأن أي حد يسرقه يقدر يستخدمه لمدة طويلة، عشان كده الـ Tokens بتبقى لها expiry time، وبعدها لازم تعمل refresh.

📡 الـ Man-in-the-Middle Attacks: لو الـ Token بيتبعت من غير encryption، ممكن حد يعترضه ويستخدمه، عشان كده لازم تتأكد إن كل حاجة بتتم تحت HTTPS مش HTTP

🔄 الـ Replay Attacks: لو مكنش فيه حماية زي timestamps، ممكن حد يستخدم الـ Token المسروق أكتر من مرة.

———

📌 إزاي تأمن الـ Bearer Token؟

✅ استخدم HTTPS: عشان تمنع أي حد من التجسس على الـ Token أثناء نقله.

✅ حدد مدة صلاحية قصيرة للـ Token: خلي الـ Token يخلص بعد فترة قصيرة عشان لو اتسرق، يبقى ملوش لازمة.

✅ استخدم Refresh Tokens: عشان المستخدم يقدر يحصل على Token جديد لما الـ Token القديم يخلص.

✅ خزن الـ Token في مكان آمن: في المتصفح، بلاش تخزنه في localStorage لأنه ممكن يتسرق بسهولة، استخدم HttpOnly Cookies لو أمكن.

✅ استخدم Scopes: لو بتستخدم API، متديش الـ Token صلاحيات أكتر من المطلوب، مثلًا متديلوش صلاحية إنه يمسح داتا لو هو بس هيقرأ بيانات.

✅ ظبط CORS كويس: عشان تمنع أي مصدر مش موثوق من استخدام الـ Token.

———

وفقكم الله لكل خير 🌿

برنامج ITIDA Gigs لتأهيل الشباب للعمل الحر

https://landing.eyouthlearning.com/index.php/digital-freelancing-placement-program

💡 الحل هو التطبيق العملي

في الـ Front-End، ممكن تبدأ بمشاريع بسيطة زي صفحة ويب شخصية أو آلة حاسبة، وبعدين تطور نفسك بمشاريع زي تطبيق إدارة مهام أو موقع إخباري بواجهة احترافية.

أما في الـ Back-End، ابدأ بمشاريع زي API بسيطة، ومع الوقت اشتغل على حاجات زي نظام إدارة مستخدمين أو تطبيق شات متكامل.

المهم تفضل تطبق عملي عشان المهارات اللي بتتعلمها تبقى ثابتة، وكل مشروع هتعمله هيرفع من مستواك واحدة واحدة لحد ما تبقى محترف.

دي مجموعة مشاريع في مجال الـ Front-End ومجال الـ Back-End هتنقلك من المستوى المبتدئ للمستوى الاحترافي

⚡️ مشاريع الـ Front-End

https://roadmap.sh/frontend/projects

⚡️ مشاريع الـ Back-End

https://roadmap.sh/backend/projects

الفرق بين الـ Monorepo والـ Multirepo 💯
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.

المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡

هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟

كل طريقة لها ميزاتها وعيوبها، واختيارك ممكن يحسن شغلك بنسبة كبيرة أو يعقد حياتك لو اختارت الغلط.

تعال نوضح الفرق بينهم وامتى تختار الطريقة المناسبة...

———

📌 أولًا: يعني إيه Monorepo؟

الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.

يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.

———

📍 مميزات الـ Monorepo:

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

- إعادة استخدام الكود (Code Reusability): لو في مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من موديول، تقدر تعمله بسهولة من غير duplication.

- تنسيق أفضل بين الفرق: كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).

- تكامل أفضل بين الأدوات: زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.

———

📍 عيوب الـ Monorepo:

- الحجم الكبير للـ repo: مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.

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

- مشاكل مع الـ Tools: لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.

———

📌 ثانيًا: يعني إيه Multirepo؟

على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو موديول من المشروع يكون في Repository خاص به. يعني كل موديول بيبقى مستقل بذاته وكأنه مشروع لوحده.

———

📍 مميزات الـ Multirepo:

- كل موديول ليه حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.

- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.

- لو فيه موديول أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه.

- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.

———

📍 عيوب الـ Multirepo:

- تكرار الكود: لو فيه أكتر من موديول بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه.

- تعقيد في التنسيق بين الفرق: التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules.

- تكامل معقد للـ CI/CD: عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.

- صعوبة في إدارة التغييرات الكبيرة: لو عندك تغيير ضخم بيأثر على أكتر من موديول، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.

———

📌 امتى تختار مين؟

✅ اختر Monorepo لو:

1- مشروعك عبارة عن مجموعة modules مرتبطة ببعضها.

2- عندك فريق صغير أو متوسط.

3- بتحتاج تعمل تغييرات بشكل متكرر على أكتر من موديول في نفس الوقت.

4- الأدوات اللي بتستخدمها بتدعم إدارة monorepos بشكل كويس.


✅ اختر Multirepo لو:

1- مشروعك كبير جدًا ومعقد، وكل جزء فيه مستقل تمامًا.

2- بتحتاج تتحكم في الصلاحيات على مستوى كل موديول.

3- عندك فرق مختلفة كل فريق شغال على موديول خاص به.

4- عايز تتجنب المشاكل اللي بتسببها أحجام الـ repos الكبيرة.

———

القرار في الآخر بيرجع لطبيعة مشروعك واحتياجات فريقك. مفيش طريقة "صح" وطريقة "غلط"، لكن فيه طريقة مناسبة أكتر حسب ظروفك. أهم حاجة إنك تكون فاهم كل طريقة بتقدم إيه وعيوبها إيه. 💡

وفقكم الله لكل خير 🌿