لماذا أعدت بناء portfolio بـ Next.js

أنا مصمم ومدرّب أبني للويب، لذا فإن portfolio الخاص بي شيئان في آنٍ واحد: مكان لعرض عملي، وعمل بحد ذاته. عندما قررت إعادة بنائه، كان الطريق الواضح هو أداة no-code (Webflow، Framer، قالب Squarespace). اخترت Next.js بدلاً من ذلك. إليك المنطق الصريح، بما في ذلك الأجزاء التي قد أعيد النظر فيها.

لماذا لا أداة no-code

أدوات no-code جيدة فعلاً، وبالنسبة للكثيرين هي الإجابة الصحيحة. ذهبت في الاتجاه الآخر لثلاثة أسباب.

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

الأداء. الـ portfolio هو سيرتي الذاتية التقنية. إذا كنت أخبر العملاء أنني أهتم بواجهات سريعة وسهلة الوصول، يجب أن يُظهر الموقع ذلك بمقاييس Core Web Vitals حقيقية، لا بقالب ثقيل محمّل بسكربتات لا أتحكم بها. يمنحني Next.js توليداً ثابتاً، وتحسين صور، وتحكماً دقيقاً فيما يُرسل إلى المتصفح.

امتلاك أجزاء الخلفية (backend). كان هذا العامل الحاسم. تعمل نماذج الموارد المجانية والتواصل عندي عبر مسارات API في Next.js متصلة بخدمة بريد إلكتروني. تدفق جمع العملاء المحتملين (يُدخل شخص بريده، يحصل على المورد، وأتلقى إشعاراً) هو شيء أملكه من البداية للنهاية، لا نموذج طرف ثالث بحدود. القدرة على تسليم مسار API إلى جانب الواجهة هو ما لم يستطع no-code منحي إياه بشكل نظيف.

ما نجح

• الثابت أولاً. معظم الصفحات مولّدة بشكل ثابت، فهي سريعة ورخيصة التقديم، مع مسار خادم واحد فقط للبريد. بالنسبة لـ portfolio، هذا هو الخيار الافتراضي الصحيح.
• مصدر واحد للحقيقة للبيانات. نقلت كل إحصائية وشهادة وخبرة إلى ملف بيانات واحد حتى لا يقول نفس الرقم "+1000" في صفحة وشيئاً آخر في أخرى. (تعلمتها بالطريقة الصعبة.)
• الموقع كقطعة portfolio. بناؤه بنفسي يعني أن الكود هو عيّنة، وكتابة هذا المقال جزء من ذلك.

ما كنت سأفعله بشكل مختلف

الصدق أكثر فائدة من جولة انتصار، فإليك ما أخطأت فيه أو كنت سأغيّره:

1. أطلقته دون حواجز الأمان. للتحرك بسرعة، تركت البناء يتجاهل أخطاء TypeScript والـ lint. هذا جيد للزخم وخطير للصيانة. الانحدارات تُشحن بصمت. لو بدأت من جديد، كنت سأبقي فحص الأنواع في البناء منذ اليوم الأول وأدفع الضريبة الصغيرة مقدماً.

2. التعدد اللغوي استحق خطة حقيقية. أعمل بالعربية والفرنسية والإنجليزية، وأضفت i18n لاحقاً بدلاً من اختيار استراتيجية توجيه صحيحة من البداية. تعديل الترجمات لاحقاً أصعب بكثير من التصميم لها منذ اليوم الأول. إذا كانت تعدد اللغات مهماً لك، قرّر ذلك قبل البناء.

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

4. لا اختبارات، ثم مفاجآت. بدون فحوصات آلية، كسرت تغييرات صغيرة أحياناً أشياء لم ألاحظها إلا لاحقاً. حتى حفنة من اختبارات الدخان (هل تظهر القائمة، هل يُرسل النموذج، هل تُظهر الإحصائيات أرقاماً حقيقية) كانت ستوفر عليّ الكثير.

هل يجب عليك استخدام Next.js لـ portfolio؟

إذا كنت مطوراً، نعم. يجب أن يثبت portfolio أنك تستطيع البناء، وهذا أصدق دليل موجود. إذا لم تكن كذلك، ستمنحك أداة no-code جيدة موقعاً جميلاً أسرع، وهذا صحيح تماماً؛ موقع منشور أفضل من موقع مثالي لا يُطلق أبداً. الإطار وسيلة، لا غاية.

ما أعود إليه دائماً هو هذا: الأداة التي تختارها يجب أن تطابق القصة التي تحكيها. أخبر عملائي أنني أستطيع أخذ فكرة من التصميم إلى منتج مُسلَّم وسريع وقابل للصيانة. بناء هذا الموقع بنفسي، بأخطائه، هو أكثر شيء مقنع يمكنني وضعه أمامهم.

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