لا أختار التقنية لأن الإطار يبدو أقوى في العرض. أختارها بسؤال أبسط: ماذا يحتاج الموقع أو النظام أن يفعل كل يوم بعد الإطلاق؟
في True North، التطوير لا يعيش منفصلاً عن التسويق بالأداء، والإبداع، وSEO، وأتمتة AI. لذلك لا ننظر إلى الموقع كواجهة جميلة فقط. قد يحتاج إلى استقبال زيارات مدفوعة، وعرض HTML نظيف لمحركات البحث والأنظمة الذكية، وسحب بيانات Shopify، وإرسال lead إلى HubSpot، وتشغيل voice agent بأمان، وتحريك لحظة بصرية فاخرة، والبقاء قابلاً للصيانة.
أفضل stack هو الذي يعطي العمل سيطرة حقيقية من دون أن يحمّل الفريق آلة لا يحتاجها.ما الوظيفة التي يجب أن يؤديها الموقع فعلاً؟
اختيار stack يجب أن يجيب عن مشكلة تجارية. "نبني على Next.js" ليست استراتيجية. و"نستخدم Shopify headless" ليست دليلاً على النضج. السؤال الأول: ما الذي يجب أن ينجزه النظام بثبات؟
لهذا تبدو جلسات التقنية لدينا كتصميم تشغيل، لا كجدال أطر. نريد منع المؤسس من شراء موقع جميل لا يمكن قياسه أو تعديله أو ربطه أو قراءته آلياً.
متى أختار Next.js افتراضياً؟
أستخدم Next.js عندما يحتاج المشروع سيطرة قوية على rendering، وهيكل الصفحات، والميتا، والبيانات المنظمة، والأداء، والمسارات الخادمية، والتفاعل المخصص. يناسب مواقع التسويق الجادة، وواجهات AI، والfunnels، والdashboards، ومشاريع headless commerce.
القيمة ليست React فقط. القيمة هي الجمع بين static generation وserver rendering وserver components وmetadata وAPI routes وتحسين الصور وسير نشر واضح داخل تطبيق واحد. توثيق Next.js يجعل rendering والmetadata جزءاً أساسياً من App Router.
نستخدمه كثيراً في:
- مواقع الخدمات التي تحتاج محتوى قابل للزحف وسرعة وبنية صفحات غنية؛
- مواقع SEO وAEO ببيانات منظمة وميتا لكل route؛
- تجارب منتج يكون frontend فيها جزءاً من التحويل؛
- Shopify headless عندما يكون القالب محدوداً؛
- واجهات AI تحتاج أدوات خادمية وتوقيعاً وسجلات وصلاحيات؛
- dashboards وportals تحتاج عقود بيانات typed.
وأتجنبه عندما يحتاج العميل تحريراً بسيطاً وعمليات ecommerce أصلية وتجربة قالب كافية. التطبيق المخصص ليس دائماً أكثر فخامة. أحياناً هو فقط مسؤولية أكبر.
متى يكون Nuxt الخيار الأنسب من Next.js؟
Next.js ليس الإطار الوحيد الجاد للـSSR. Nuxt قوي عندما يكون الفريق أقرب إلى Vue، أو عندما يخدم نظام المحتوى وتجربة المكونات المشروع بشكل أفضل.
يدعم Nuxt server rendering وstatic generation وhybrid rendering وrouting وجلب البيانات ونشر مواقع قابلة للزحف. توثيق Nuxt يعامل rendering mode كقرار معماري أساسي.
أفكر في Nuxt عندما:
- يكون الموقع تحريرياً أو منتجياً والفريق يستخدم Vue؛
- تحتاج العلامة محتوى منظماً وسيطرة frontend قوية؛
- يحتاج المشروع لغات متعددة وسير محتوى مناسب؛
- تكون التجربة شبيهة بتطبيق لكنها لا تحتاج انتقال الفريق إلى React.
المعيار ليس الموضة. المعيار هو قدرة الفريق على تشغيل التقنية وحاجة العمل لمحتوى server-visible.
هل تبقى على Shopify التقليدي أم تنتقل لـ headless؟
Shopify ليس بنية واحدة. قالب Shopify الأصلي وواجهة Shopify headless يحلان مشكلتين مختلفتين.
Shopify الأصلي أفضل عندما تهم عمليات التاجر: المنتجات، المخزون، الدفع، الخصومات، التطبيقات، وتحرير القالب. يمكن تخصيص القالب بجدية: أقسام أفضل، سرعة، tracking، merchandising، حقول SEO، وحركة محسوبة مع البقاء قريبين من تشغيل Shopify.
Shopify headless يستحق النقاش عندما تحتاج الواجهة سيطرة لا يوفرها القالب.
عملنا عبر النمطين. دراسة Twenty One Perfumes مثال جيد لأنها تقارن مسار قالب Shopify مع prototype لـNext.js headless بدلاً من الادعاء أن بنية واحدة تفوز دائماً.
أي CMS يناسب سير النشر لديك فعلاً؟
CMS ليس "مكان النص" فقط. هو يحدد من ينشر، ومن قد يكسر التخطيط، وكيف تعمل اللغة، وحقول SEO، والموافقات، وكيف يصبح المحتوى منظماً للبحث والأنظمة الذكية.
في موقع True North، MDX مناسب لأننا نريد محتوى typed، ودراسات حالة منظمة، وتحكماً بالإصدارات. لكن لعميل ينشر أسبوعياً بفريق غير تقني، قد يكون الخيار نفسه خطأ.
هل تستحق هذه الحركة وزنها؟
الحركة قد تجعل الموقع أغلى إحساساً، وقد تجعله أبطأ وأسوأ على الموبايل.
ترتيبي بسيط:
- CSS للحالات البسيطة والhover والانتقالات.
- Framer Motion عندما نحتاج state وvariants وحركة مرتبطة بـReact.
- GSAP عندما نحتاج timeline أو scroll choreography فعلياً.
- Lenis فقط عندما يخدم smooth scroll التجربة ولا يحارب السلوك الأصلي.
- Three.js عندما يشرح المنتج أو العمق التقني أو الإحساس البصري أفضل من صورة ثابتة.
توثيق GSAP ScrollTrigger قوي، لكن القوة ليست إذناً. نستخدم motion عندما يخدم شرح المنتج، أو إحساس العلامة، أو تفاعل يعلق في الذاكرة لأنه مرتبط بوظيفة الصفحة.
ماذا يجب أن يملك الـ backend فعلاً؟
كثير من المواقع لا تحتاج backend ضخماً. تحتاج عقوداً خادمية موثوقة.
في أنظمة النمو، backend غالباً يملك:
- التقاط lead والتحقق منه؛
- الكتابة إلى HubSpot أو CRM آخر؛
- أحداث server-side للتحليلات والمنصات الإعلانية؛
- webhooks وidempotency؛
- صلاحيات المستخدم؛
- قراءة المنتج أو المخزون أو الحجز؛
- email وWhatsApp وvoice-agent tools؛
- السجلات، والمحاولات، ومسارات الفشل.
Node.js وPostgreSQL وSupabase وqueues وAPIs أدوات حول هذه الوظيفة. في AI، قد نضيف vector search وknowledge base وtool authorization وevaluation logs. في ecommerce، يبقى Shopify غالباً مصدر الحقيقة التجاري بينما تتحكم طبقة التطبيق في العرض والقياس.
هذا يربط التطوير بـأتمتة AI. النموذج قد يتكلم أو يصنف، لكن الخادم يجب أن يقرر ما المسموح وما تم حفظه فعلاً.
أين يجب أن تنشر الموقع فعلاً؟
النشر ليس خطوة أخيرة. يؤثر في الأداء، وpreview، وrollback، وenvironment variables، وedge caching، والصور، وsecurity headers، والثقة في الشحن.
شراكاتنا الرسمية مهمة هنا لأنها قريبة من التنفيذ. Vercel وDigitalOcean وCloudflare تمثل قرارات نشر وبنية وedge نكررها عملياً. HubSpot يؤثر في CRM والhandoff. Google وMeta يؤثران في الاكتساب والقياس. الهدف ليس فرض هذه المنصات على كل عميل، بل فهم علاقة الموقع بباقي نظام النمو.
التقنية يجب أن تجعل الشحن آمناً. إذا كان تعديل نص صغير يحتاج عملية يدوية هشة، فالمعمارية تؤذي العمل.
متى يحتاج المشروع stack تطبيق كامل؟
بعض المشاريع ليست مواقع بقدر ما هي أدوات: dashboards، portals، أنظمة داخلية، أو تجارب بيانات. هنا يتغير السؤال.
منظومة TanStack، مثل Router وQuery وTable وTanStack Start، تفيد عندما يحتاج المنتج state قوي، وجلب بيانات، وجداول، وفلاتر، وrouting typed. توثيق TanStack Start يضع full-document SSR ضمن نمط تطبيقات React الحديثة.
لا أستخدمه لأنه جديد. أستخدمه عندما يحتاج نموذج التفاعل ذلك. موقع تسويق بنموذجين لا يحتاج stack تطبيق بيانات. منتج تقارير بفلاتر وحالة مستخدم ووظائف خادمية قد يحتاجه.
التوصية النهائية يجب أن تكون قابلة للتشغيل
عادة أكتب قرار stack مختصر:
هذا ليس تنظيراً. هو طريقة منع المشروع من التحول إلى استعراض تقنية.
التقنية يجب أن تخدم نظام النمو
أفضل بناء ليس الأكثر تعقيداً. أفضل بناء هو الذي يمكن للعمل استخدامه وقياسه وصيانته وتحسينه.
أحياناً يكون ذلك موقع Next.js ثابتاً مع MDX وstructured data. أحياناً Nuxt مع CMS قوي. أحياناً قالب Shopify مخصص. أحياناً Shopify headless وbackend مخصص وتجربة motion غنية. وأحياناً الجواب الصادق هو بناء حديث ورشيق يستطيع الفريق تشغيله فعلاً، بدل تطبيق مخصص أثقل لن يصونه أبداً. نبني على منظومات حديثة بمستوى هندسي؛ والانضباط يعني مواءمة النطاق مع المهمة، لا الرجوع إلى أدوات قديمة.
هذه هي طريقتي في تطوير الويب والبرمجيات في True North: نختار التقنية حول الوظيفة التجارية، نحافظ على القياس، ولا نضيف التعقيد إلا عندما يعطي سيطرة سيستخدمها العمل فعلاً.
