الـ languages، والـ frameworks، والـ packages

افتح codebase حقيقية، وأول ما ستلاحظه أنك محاط بأسماء لم تسمع بها قطّ. React. Tailwind. Express. Django. Pandas. Lodash. Next.js. قد يبدو الأمر وكأنه جمعية سرّية.

إنها ثلاثة أشياء، تتزيّا بألف زيّ.

الـ language هو كيف تكتب الكود. والـ framework قطعة كبيرة مكتوبة مسبقًا من الكود تمنح المشروع شكله العام. والـ package (أو الـ library) قطعة أصغر مكتوبة مسبقًا من الكود تأخذها لتؤدّي شيئًا محدّدًا واحدًا.

حالما تستطيع تصنيف أيّ اسم في واحدة من تلك السلال الثلاث، يتلاشى جدار المصطلحات.

الـ languages

الـ programming language هو القواعد النحوية التي تُكتب بها تعليماتك. وهناك الكثير منها. سترى هذه باستمرار:

• JavaScript / TypeScript — لغة الويب. كلتاهما تعملان في المتصفّحات وعلى الـ servers. TypeScript هي JavaScript مع تدقيق إضافي. ومعظم كود الـ frontend هو إحداهما.
• Python — لغة البيانات، والبرمجة النصية، والذكاء الاصطناعي، و«أريد فقط أن يعمل هذا». مقروءة جدًا.
• Go وRust وJava وC# وRuby وPHP وSwift وKotlin — كلها شائعة، وكلٌّ منها مناسبة لمهام مختلفة.

تُكتب الـ codebase عادةً في الأساس بـ language واحد، مع رشّة من غيره ربما. حين يخبرك Claude بأن «هذا مشروع TypeScript»، فتلك هي اللغة الأساسية — ومعظم الملفات التي ستفتحها ستكون TypeScript.

الـ frameworks

الـ framework هو بداية ضخمة سبقك إليها شخص آخر.

بناء موقع ويب من JavaScript الخام يعني كتابة آلاف الأسطر من السباكة — الـ routing، وعرض الصفحات، ومعالجة النماذج — قبل أن تصل حتى إلى فكرتك الفعلية. لذا بدلًا من ذلك، يستخدم الناس framework: حزمة كبيرة من الكود المكتوب مسبقًا تتولّى الأمور المملّة وتترك لك ملء الأجزاء الخاصة بمشروعك.

الأسماء الكبيرة التي سترَاها:

• React وVue وSvelte — frameworks للـ frontend (هي تقنيًا libraries، لكن الجميع يسمّيها frameworks).
• Next.js وAstro وRemix — frameworks أكمل للـ frontend مبنية فوق تلك.
• Express وFastify وNestJS — frameworks للـ backend بلغة JavaScript.
• Django وFlask وFastAPI — frameworks للـ backend بلغة Python.
• Rails — framework للـ backend بلغة Ruby.

حين يقول Claude «هذا تطبيق Next.js»، فهذا يعني: شكل المشروع — كيف تعمل الـ routes، وكيف تُعرَض الصفحات، وكيف تتدفّق البيانات — يأتي من Next.js. أنت تكتب الأجزاء التي تصنع المشروع نفسه؛ ويتولّى Next.js الباقي.

الـ packages

الـ package (تُستخدم بالتبادل مع الـ library) قطعة أصغر مكتوبة مسبقًا من الكود تأخذها لمهمة محدّدة واحدة.

تحتاج إلى رسم مخطّط بياني؟ خذ package رسوم بيانية. تحتاج إلى تنسيق التواريخ؟ خذ package تواريخ. تحتاج إلى التحدث مع Stripe؟ خذ package الخاص بـ Stripe. هناك ملايين الـ packages في الخارج، مجانية، وجاهزة للتثبيت.

كل language له مخزن packages الخاص به:

• JavaScript / TypeScript — الـ packages تعيش على npm. تُثبَّت بأمر npm install. وتُدرَج في package.json.
• Python — الـ packages تعيش على PyPI. تُثبَّت بأمر pip install. وتُدرَج في requirements.txt أو pyproject.toml.
• Rust — cargo، وتُدرَج في Cargo.toml. Ruby — gem، وتُدرَج في Gemfile. النمط ذاته، بأسماء مختلفة.

ملف package.json ذاك الموجود في شجرة الدرس السابق هو قائمة بالـ packages التي يستخدمها هذا المشروع.

النقطة التي تربك الناس عادةً

ستنظر إلى codebase حقيقية وتكتشف أن معظم الكود فيها ليس لك.

افتح مجلد node_modules في أيّ مشروع JavaScript وستجد عشرات الآلاف من الملفات. لم يكتب أحدٌ منها فريقك. لقد ثُبِّتت بأمر npm install، وهي الـ packages والـ frameworks التي يعتمد عليها المشروع.

مهمة المطوّر الحديث نادرًا ما تكون «اكتب كل شيء من الصفر». بل هي «ألصِق معًا الكود المناسب الموجود مسبقًا، واكتب الأجزاء الفريدة بفكرتك.»

ليس هذا كسلًا. إنه كيف يعمل كل مشروع جادّ. الفريق الذي بنى إنستغرام لم يكتب كودًا لعرض المستطيلات ذات الزوايا الدائرية، ولا لإرسال طلبات HTTP، ولا لتحليل JSON. بل ثبّتوا packages تفعل تلك الأشياء، وانصرفوا إلى المنتج الفعلي.

حين يوجّهك Claude نحو مجلد node_modules ويقول «لا تعدّل هذه»، صرت الآن تعرف لماذا.

ما التالي

غطّينا ما هي البرمجيات، وكيف تنقسم، وكيف تتحدث، وأين تتذكّر، وممّ تُبنى. بقي شيء واحد في هذا المستوى: أين يعمل الكود؟ على حاسوبك المحمول، أم في مكان آخر؟ الفرق مهم أكثر مما تظن.