وقف اختيار التقنيات وكأننا في 2018

بقول شي بيخلي نصكم يقفل الصفحة: أغلب إطارات JavaScript غلطة لأغلب المنتجات.

خلاص. قلتها.

قبل لا تتهموني إني ديناصور أو واحد يدافع عن PHP وعايش في 2010، اسمعوني. بنيت منتجات بـ React وVue وSvelte. شحنت كود بـ Next.js وNuxt وSvelteKit وأي شي جديد طلع هذا الأسبوع.

وأنا هنا أقولكم إننا كنا نسويها غلط.

وهم إطارات الجافاسكربت الكبير

كل كم شهر، يطلع إطار جافاسكربت جديد يوعدنا إنه بيحل كل المشاكل اللي سببها الإطار اللي قبله. Server components! Island architecture! Partial hydration! كل واحد يبان ثوري لين تصير ثلاث شهور في المشروع وأنت تحاول تفهم ليش tokens المصادقة ما تنحفظ بين الصفحات، أو ليش الـ server-side rendering ينكسر بالبرودكشن.

جربنا هذا مرات كثيرة مع عملاء كثيرين، وما نفع.

تظل تعيد اختراع حلول لمشاكل انحلت من عشرين سنة. جلسات المستخدمين منحلة، والتحقق من النماذج منحل، وتحديثات قواعد البيانات منحلة. بس بطريقة ما، في عالم الجافاسكربت، نعامل كل هذي كفرص جديدة مثيرة بدل ما هي بنية تحتية مملة المفروض تشتغل وبس.

وش يصير بالواقع؟ تبدأ مشروع وتختار Next.js لأنه مشهور وتبي تكون “حديث”. بعد ستة شهور، تلاقي نفسك مجمع نظام مصادقة مسكّن بالأمل وأي شي هلوسه لك Claude الصبح. عندك سبعطعش حل مختلف لإدارة الحالة لأنك ما قدرت تقرر بين Redux وZustand وJotai واستخدام React context. حجم الـ bundle وصل 10 ميقا لأن كل حزمة npm جابت معها كون كامل من التبعيات (وأحياناً، دودة تتكاثر ذاتياً وتسرق مفاتيح AWS حقتك). عملية النشر تتطلب معجزات كل مرة.

وهذا نسميه تقدم.

ضريبة التعقيد

وهذا التعقيد له تكاليف حقيقية.

في 3 ديسمبر 2025، React كشفت عن CVE-2025-55182، ثغرة تنفيذ كود عن بعد بتصنيف CVSS 10.0 (أقصى تصنيف خطورة) في React Server Components. مهاجم بدون مصادقة يقدر يصنع طلب HTTP خبيث ويحقق تنفيذ كود كامل على سيرفرك.

تأمل في المشهد. Server Components جاءت تُبشّر بالخلاص من تعقيد React. “أرسل HTML من السيرفر”، قالوا. “ستكون الأمور أبسط”، وعدوا. فإذا بالتجريد يفتح باباً لم يكن موجوداً، وإذا بالميزة التي أُريد لها أن تُبسّط تجلب ثغرة أمنية حرجة طالت Next.js وReact Router وWaku وغيرها.

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

وبينما أنت تصارع هذي المشاكل، Laravel بهدوء يطلع نسخة جديدة، وRails يكمل مشواره، وDjango يظل ممل ومتوقع. غريب كيف “الممل” يبدأ يبان جذاب لما “المثير” يعني ترقيعات أمنية طارئة.

مشكلة عزة النفس

فيه شي ما أحد يتكلم عنه: جانب نفسي لقرارات اختيار التقنية.

اختيار تقنية مملة يحسسك إنك تعترف بشي: إنك مو مبتكر كفاية. إنك مجرد “مبرمج عادي” يطلع تطبيقات CRUD بينما المهندسين الحقيقيين يدفعون الحدود بمعماريات متطورة.

أفهمك. حسيت بهذا بعد.

بس عزة نفسك تكذب عليك. أكثر شي مبتكر تقدر تسويه هو إنك تطلق منتج يحل مشاكل حقيقية. ما أحد يعطي جوائز لاستخدام أعقد استراتيجية rendering. مستخدمينك ما يهمهم إذا تستخدم server components أو server actions أو أي شي اخترعه فريق React هذا الربع. يهمهم إذا الشي يشتغل.

المطورين اللي أحترمهم أكثر مو اللي يلاحقون كل إطار جديد. هم اللي شحنوا وبنوا شركات وحلوا مشاكل. وتقريباً كلهم سووها بتقنية مملة خلتهم يركزون على اللي يهم.

الابتكار يصير في منتجك. البنية التحتية المفروض تختفي.

اللي ينفع

السر اللي الوكالات والاستشاريين ما يبونك تعرفه: التقنية المملة هي تقنية جميلة.

Laravel. Rails. Django.

AdonisJS إذا أنت ملتزم بأسلوب TypeScript مثلنا.

Phoenix إذا شفت نور Elixir.

هذي الإطارات عندها شي عالم الجافاسكربت يفتقده: طريقة تفكير.

تقولك وين كودك ينتمي، وتوفر مصادقة مدمجة تشتغل، وتتعامل مع إدارة قاعدة البيانات بأدوات ناضجة ومجربة، وعندها أنماط اختبار مصقولة على مدى عقد من الاستخدام في البرودكشن. ولما شي يخرب (وبيخرب)، أحد صادف نفس المشكلة قبلك. الحل موجود وموثق ويشتغل.

أعرف اللي تفكر فيه: “بس يا فواز، هذي تقنيات قديمة. مو مبتكرة.”

بالضبط.

لما تبني MVP، الابتكار يكون في منتجك، مو في بنيتك التحتية. ما أحد يهتم إذا تستخدم آخر نموذج rendering. المستخدمين يهمهم إذا المنتج يحل مشكلتهم.

ملاحظة عن الـ LLMs والـ Vibe Coding

وبما إننا نتكلم عن أشياء تبان مبتكرة بس بتأذيك: التطوير بمساعدة الـ LLM.

أستخدم Claude يومياً. مفيد للـ boilerplate ولاستكشاف APIs غير مألوفة ولمناقشة المشاكل. بس فيه فخ هنا، خصوصاً مع الإطارات الجديدة.

بيانات التدريب لهذي النماذج تميل للتقنيات المشهورة والراسخة. اسأل Claude عن Rails أو Django وبتحصل كود يشتغل. اسأله عن آخر أنماط Next.js App Router أو أي إعداد React Server Component متطور، وبتحصل شي يشبه اللي كتبته في كتاب لغتي الجميلة في الابتدائي، درس “التعبير الإبداعي”.

تصطدم بحائط مع سلوك غريب في الإطار وتسأل Claude Opus 4.5 عنه. يرد بـ “You’re absolutely right!” ويعطيك أسوأ هلوسات تتخيلها، من دوال ما لها وجود في الحزمة لحزم ما لها وجود أصلاً، وحلول تفهم مشكلتك غلط. يضيف تعليقات مثل // This ensures proper hydration فوق كود ما يسوي شي من هذا.

النموذج مو خبيث، بس متملق. يبي يساعد لدرجة إنه يهلوس بثقة بدل ما يعترف بعدم اليقين. ولأن الإطارات الجديدة عندها بيانات تدريب أقل، الهلوسات تسوء لما تحتاج مساعدة أكثر.

الإطارات المملة ما عندها هذي المشكلة. أسئلة Laravel تجيب إجابات Laravel. النظام البيئي ناضج كفاية إن النماذج شافت آلاف التطبيقات الصحيحة.

متى الجافاسكربت منطقي

أنا مو متعصب. فيه حالات المنهج الجافاسكربتي الثقيل منطقي.

التطبيقات أحادية الغرض، مثلاً. بنينا Astrolabe، MVP ياخذ وثائق المحكمة ويحللها ويطلع أسباب ليش الشركة خسرت القضية مع توصيات للتحسين. معالجة نصوص صرفة، وإدارة مستخدمين بسيطة، ونموذج بيانات سهل، ونطاق محدود عمداً. لشي مثل كذا، stack أخف يشتغل حلو. لما تطبيقك يسوي شي واحد ممتاز، ترسانة إطار monolithic كاملة مبالغ فيها.

الأدلة البسيطة والمواقع الثابتة تشتغل بنفس الطريقة. صفحات التسويق والمدونات وصفحات الهبوط والتوثيق، كلها محتوى ما يحتاج حسابات مستخدمين أو حالة معقدة. لهذي، طبعاً استخدم Astro أو Next.js في وضع static أو أي شي يسعدك.

وفيه التطبيقات اللي التفاعل هو المنتج. تبني منافس لـ Spotify؟ ايه، روح SPA. أداة تصميم مثل Figma؟ تجربة التعاون الفوري تتطلبها. لعبة جماعية؟ تحتاج ذاك الإحساس فائق الاستجابة.

بس أغلبنا مو يبني Figma.

مدى التفاعل

تخيل الموضوع كمقياس.

من طرف تقعد تطبيقات server-rendered. أقصى قابلية للصيانة. فريق من شخصين يقدر يشحن ميزات ويسحق bugs ويطلع من المكتب في أوقات معقولة. النماذج ترسل والصفحات تتحدث بالضبط كيف الويب صُمم يشتغل.

من الطرف الثاني تقعد SPAs كاملة. تجربة مثل التطبيقات الأصلية، وانتقالات سلسة بين العروض، وتحديثات متفائلة تخلي الواجهة تحس فورية.

الصدق اللي يزعل: إلا إذا تبني تطبيق مستهلك حيث تجربة المستخدم هي المميز الرئيسي، غالباً تنتمي أقرب لطرف الـ server-rendered.

عندك B2B SaaS بأنواع مستخدمين وصلاحيات متعددة؟ متطلبات سجلات تدقيق؟ تكاملات طرف ثالث تديرها؟

روح monolithic.

Laravel. Rails. Django. AdonisJS. بترتاح بعدين وأنت تشحن ميزات بدل ما تصلح مشاكل البرودكشن الساعة 2 الفجر.

متى تطبيق الجوال منطقي

أحياناً الويب مو الجواب أصلاً.

بنينا خطوتين، تطبيق خطوبة للأزواج السعوديين يضم 500 سؤال توافق. كان نقدر نبنيه كتطبيق ويب؟ أكيد. هو أساساً feed بأسلوب TikTok من الأسئلة مع ميزة دليل.

بس بنيناه عالجوال.

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

أحياناً المنتجات تتوق لوسيط معين. اسمع لهذا التوق.

صقل الواجهة مو لكل MVP

رأي آخر مثير للجدل: أغلب الـ MVPs ما يحتاجون لمسات UI/UX فاخرة.

أسمع المصممين يلهثون. ابقوا معي.

الحركات والتفاعلات الصغيرة والانتقالات الجميلة، كلها غالية. التكلفة مو بس وقت التطوير، هي عبء الصيانة. كل حركة bug محتمل، وكل تفاعل صغير كود ممكن ينكسر لما المكتبة الأساسية تتحدث.

احفظ الصقل للوقت اللي منتجك يتطلبه.

الألعاب والتجارب المُلَعبة تعيش أو تموت بكيف تحس. لعبة ركيكة لعبة متروكة. والمنتجات اللي المشاعر هي قيمتها تحتاج نفس العناية. خطوتين كان يحتاج يحس دافي وحميمي. الحركات الخفيفة ما كانت غرور، كانت ضرورية لجعل شي سريري مثل “أسئلة التوافق” يحس رومانسي. وتطبيقات المستهلك اللي تنافس على البهجة في أسواق مزدحمة تحتاج الصقل كسلاح.

بس أداة إدارة المخزون لعمال المستودع؟ تخطى الـ parallax scrolling. مستخدمينك يبون سريع وموثوق ويبون ينصرفون في وقتهم.

الأمان: سو الأساسيات وتخطى التعقيد الزايد

أساسيات الأمان بسيطة، بس التعقيد الزايد هو اللي يتعب.

خل S3 buckets خاصة واستخدم مفاتيح عشوائية مو أنماط متوقعة.

لا تسوي تشفيرك بنفسك. تقريباً ما حطيت هذي لأنها المفروض واضحة في 2025، بس شفتها تصير. كل لغة حديثة عندها مكتبات تشفير ممتازة. استخدمها. طريقة الهاش الذكية حقتك مو ذكية.

اعرف نواقل الهجوم الشائعة. CSRF وXSS وسرقة الكوكيز واختطاف الجلسات وSQL injection. إذا تبني للويب، تحتاج تفهم هذي. والحلو في الموضوع إنك إذا تستخدم الإطارات اللي اقترحتها (Laravel وRails وDjango وAdonisJS)، هذي الحمايات مدمجة من البداية. ما تحتاج تفكر فيها لأن ناس أذكياء فكروا فيها.

ولا تنسى تراجع كودك المولد من LLM. في تجربتنا، أحدث النماذج مثل Claude Opus 4.5 وGemini 3 Pro عموماً ما تطلع كود غير آمن واضح. بس “عموماً” مو “أبداً”، والـ LLMs ما تستبدل المراجعة البشرية، خصوصاً للمسارات الحرجة أمنياً مثل تدفقات المصادقة ومعالجة المدفوعات وضوابط الوصول للبيانات. إنسان يحتاج يقرأ هذا الكود.

إذا تبي تتعمق أكثر، OWASP Top 10 لسنة 2025 تستاهل وقتك.

اللي ما تحتاجه في MVP

الحين للتعقيد الزايد، الأشياء اللي تحسسك بالمسؤولية بس تبطئك.

Rate limiting لكل شي. لا تكون proactive هنا، كن reactive. إلا إذا تتكامل مع APIs تكلف مئات الآلاف للاستعلام (أنظر إليك، APIs الحكومية)، الـ rate limiting يقدر ينتظر لين يكون عندك مشكلة rate. غالباً ما عندك مستخدمين كفاية عشان هذا يهم بعد.

الإفراط في التحقق من المدخلات. تبان متناقضة، بس التحقق المفرط يبطئك ويزيد الاحتكاك مع العملاء، خصوصاً في B2B. العميل المؤسسي اللي بياناته ما تناسب السكيما الجامدة حقتك؟ بيروح لمنافسك اللي أكثر مرونة. تحقق من اللي يهم للأمان وسلامة البيانات.

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

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

البنية لسرعة الإطلاق

لما أصمم أنظمة، أحسّن لشي واحد فوق كل شي: سرعة الإطلاق.

مكّن التحديثات عبر الهواء حيثما أمكن. نستخدم React Native مع Expo للمشاريع المحمولة لهذي القدرة. ادفع إصلاح والمستخدمين يحصلونه فوراً بدون مراجعة App Store. لمشاريع IoT، نطبق نفس الفلسفة. مرة سوينا غلطة نشرنا مستشعرات بدون قدرة OTA. تحديث عشرات الأجهزة باليد تجربة ما أنصح فيها. تعلموا من معاناتنا.

خل تحديثات قواعد البيانات سهلة. أي ORM أو أداة تختارها تحتاج تكون موثوقة وسريعة. قليل أشياء تقتل الزخم مثل قضاء وقت أكثر في محاربة الـ migrations من بناء الميزات. وإذا العملية مخيفة، بتتجنب تغييرات السكيما وبتبدأ تلتف حول نموذج البيانات بدل تطوره. سكيماك تتحجر لشي ما يطابق الواقع.

أسس سير عمل نشر سريع. ما تحتاج CI/CD pipeline بسبعطعش مرحلة وإشعارات Slack لكل تحذير linter. سكربت ./deploy.sh يشتغل في 30 ثانية أفضل من pipeline “صحيح” ياخذ 20 دقيقة. قلل الوقت بين “جتني فكرة” و”صارت لايف في البرودكشن”. كل شي يطول هذي الحلقة عدوك.

الزبدة

شوف، أنا ما أقولك لا تستخدم React أو Vue أو أي إطار ترند هذا الأسبوع. أستخدمهم بنفسي. هذا الموقع نفسه مبني بـ Astro.

اللي أقوله هو: اختر تقنيتك بناءً على اللي منتجك يحتاجه، مو بناءً على اللي مشهور على تويتر أو اللي يحلّي سيرتك الذاتية. وبالتأكيد مو بناءً على اللي يحسسك إنك مهندس “حقيقي”.

لأغلب الـ MVPs، خصوصاً منتجات B2B ولوحات الإدارة وأي شي فيه إدارة مستخدمين معقدة، تبي إطار monolithic ممل ومُجرّب. Laravel. Rails. Django. AdonisJS. مو مثيرة، وهذا ميزة.

للأدوات أحادية الغرض والمنتجات بمتطلبات مصادقة بسيطة، stacks أخف تمام.

لتطبيقات المستهلك اللي تحس أصلية حيث التجربة هي كل شي، روح SPA أو موبايل.

ومهما اخترت، حسّن لسرعة الإطلاق. الشي الوحيد اللي يهم في المراحل الأولى هو التعلم، وما تقدر تتعلم إذا ما تقدر تشحن.

دَعِ القصورَ التي في الوهمِ ترفعُها

وشيّد على الأرضِ ما يبقى لهُ أثرُ

---

عندك أسئلة عن اختيار الـ stack المناسب لـ MVP-ك؟ تواصل معنا. سوينا أغلب الأخطاء عشان ما تحتاج تسويها.