لقد رأيت مطورين يعملون مع C لفترة طويلة، وما زالوا يطورون مع MFC (فئات مؤسسة Microsoft). السبب بسيط: لا توجد بدائل حقيقية لبناء واجهات المستخدم في لغة C. على الرغم من وجود Qt، إلا أنها تتطلب ترخيصًا تجاريًا للاستخدام المهني، مما يجعل MFC هو الخيار الوحيد.

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

الحالة الحالية لنظام جافا سكريبت البيئي مشابهة تمامًا.

لا يوجد إطار تم تصميمه خصيصًا لمعالجة أهداف HPSE. على الرغم من وجود محركات ألعاب مثل Babylon.js، إلا أنها تقدم فقط ميزات للرسومات ثلاثية الأبعاد ولا توفر بنية شاملة مثل React.

لذا، في النهاية، يعود الأمر كله إلى Vanilla JavaScript وTypeScript. لا يعني ذلك أن المطورين يستخدمون Vanilla JavaScript لأنهم يحبونها؛ يستخدمونه لأنه لا يوجد خيار آخر. تمامًا كما كان الحال في الأيام الأولى عندما كان على المطورين إنشاء كل شيء من الصفر بلغة C بسبب عدم وجود أطر عمل تجارية، فإننا نواجه الآن نفس الموقف في JavaScript. لا يوجد إطار حالي يلبي متطلبات HPSE بشكل كامل، لذا لم يتبق لنا سوى التطوير يدويًا باستخدام Vanilla JavaScript.

وبصراحة، هذا لا يقتصر على JavaScript. وهذا صحيح بالنسبة لمعظم اللغات الأخرى أيضًا.

هناك قول مأثور، "لا يوجد شيء اسمه وجبة غداء مجانية."

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

قد يجادل البعض، "لماذا لا نتخلى عن JavaScript ونستخدم C أو Rust لإنشاء وحدة WebAssembly (WASM) وتشغيلها في المتصفح بدلاً من ذلك؟"

هناك قصة جيدة تجيب على هذا السؤال.

تم سؤال قادة Babylon.js و Three.js ذات مرة في أحد التعليقات عما إذا كانت تقنية WASM ستكون مستقبل محركاتهم. وكانت إجابتهم "لا."

السبب بسيط: كود C /Rust لا يعمل مباشرة في بيئة الويب، مما يجعل تصحيح الأخطاء أكثر صعوبة. وبفضل التطورات التي تم إحرازها في محرك V8، يمكن لجافا سكريبت الآن تحقيق أداء عالٍ. JavaScript هي لغة برمجة نصية يتم تشغيلها مباشرةً في المتصفح وتوفر إنتاجية عالية — ليست هناك حاجة للتخلي عن نقاط القوة هذه.

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

إذا كانت هناك خطوط واضحة حول ما يجب وما لا ينبغي استخدام JavaScript من أجله، وإذا كانت المهام المتطورة غير مناسبة حقًا لـ JavaScript، فلن تكون Microsoft قد بدأت أبدًا مشروع Babylon.js، ولن يكون Three.js أبدًا تم إنشاؤها. الأمر نفسه ينطبق على WebGPU، الذي تم إنشاؤه كمعيار ويب جديد.

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

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