نشأة وموت JavaScript
تعمل JavaScript في المتصفح بصلاحيات محدودة. ومع ذلك، فهي تشغل الخوادم، وأدوات البناء، وخطوط الإنتاج (pipelines). لم يكن هذا مخططاً له، بل كان عبارة عن سلسلة من الحلول المؤقتة (patches) لقرار اتُخذ في عام 1995.
إن فهم سبب حدوث ذلك يغير طريقة تصميمك لمجموعة تقنياتك (stack) اليوم.
حديث Gary Bernhardt في عام 2014 ليس عن الحنين إلى الماضي، بل هو تشخيص للاحتكاك المعماري (architectural friction). لقد لاحظ مساراً ساخراً: كانت JavaScript لغة بسيطة (toy language) نجت لأنها كانت تحتكر المتصفح. وهذا الاحتكار جعلها اللغة الأكثر استخداماً على وجه الأرض.
التوتر بسيط؛ يجب على المتصفح تشغيل الكود بأمان وسرعة، وهذان الهدفان متعارضان.
في عام 2014، كان الرهان هو أن WebAssembly ستحل محل JavaScript. لم يحدث ذلك بالكامل؛ فتقنية WebAssembly مستقرة ومفيدة لأشياء مثل Figma أو Google Earth، لكنها لم تحل محل JavaScript كلغة تطبيقات.
بدلاً من ذلك، تحورت JavaScript. فوجود TypeScript، وأدوات التجميع (bundlers)، وبيئات التشغيل (runtimes) الجديدة مثل Bun، جاء لمعالجة حالات الاحتكاك التي حددها Bernhardt.
لا تستخدم هذا الحديث لتجنب تعلم JavaScript، ولا تستخدمه لتبرير الانتقال إلى WebAssembly دون وجود مشكلة في الأداء.
استخدمه كقائمة مراجعة لمجموعة تقنياتك (stack):
- هل أستخدم هذا لأنه الأداة الأفضل؟
- أم لأنه الشيء الوحيد الذي يعمل هنا؟
- هل تعالج الأعباء الإضافية (overhead) للأدوات الاحتكاك أم تنقله فقط؟
- لو بدأت من الصفر اليوم، هل سأختار هذا؟
- هل سقف الأداء مقبول لحالة الاستخدام الخاصة بي؟
تساعد TypeScript في التعامل مع الأنواع (types) أثناء وقت التجميع (compile time)، لكنها لا تعالج الفجوة بين أنواع البيانات لديك والبيانات التي تصل عبر الشبكة. لا تزال بحاجة إلى التحقق من صحة البيانات أثناء التشغيل (runtime validation).
الدرس الأهم هو: اعرف ما إذا كانت تقنيتك موجودة بناءً على جدارتها أم بسبب الاحتكار.
لا تغير بيئة التشغيل (runtime) الخاصة بك بناءً على توقعات من عام 2014. غيرها عندما تتوفر لديك بيانات مقاسة تظهر وجود عنق زجاجة (bottleneck).
المصدر: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae