تاريخ JavaScript: ECMAScript و TC39 وما بعده

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

لاحظ أنني سجلت أيضًا نسخة فيديو من هذه المقالة ، إذا كنت تفضل مشاهدة ما يلي:

دعنا نعيد أنفسنا إلى عام 1995. كانت لعبة ثقيلة ثقيلة الوزن الثقيل في المسارح ، وفاز نيكولاس كيج بجائزة الأوسكار ، ومواقع الويب تبدو مثل هذا. الآن ، الاحتمالات هي الطريقة التي شاهدت بها هذا الموقع مع Netscape Navigator.

في ذلك الوقت ، كان Netscape Navigator متصفح الويب الأكثر شعبية بحصة سوقية تقارب 80٪. مؤسس شركة Netscape ، الشركة وراء Netscape Navigator ، كان مارك أندريسن. كان لديه رؤية لمستقبل الويب وكان أكثر من مجرد وسيلة لمشاركة المستندات وتوزيعها. لقد تصور نظامًا أكثر ديناميكية مع تفاعل من جانب العميل - وهو نوع من "مقياس الغراء" الذي كان سهل الاستخدام من قبل كل من المصممين والمطورين.

هذا هو المكان الذي يأتي Brendan Eich إلى الصورة. تم تجنيده بواسطة Netscape بهدف تضمين لغة برمجة Scheme في Netscape Navigator. ولكن قبل أن يتمكن من البدء ، تعاون Netscape مع Sun Microsystems لإتاحة لغة البرمجة بلغة Java القادمة والمتصفح في المتصفح. الآن يطرح هذا السؤال ، "إذا كانت جافا بالفعل لغة مناسبة ، لماذا أحضر بريندان لإنشاء لغة أخرى؟".

حسنًا ، إذا كنت تتذكر العودة إلى هدف Netscape ، فقد أرادوا لغة نصية كانت بسيطة بما يكفي للمصممين والهواة لاستخدامها - لم يكن Java كذلك. وهكذا أصبحت الفكرة أنه يمكن استخدام Java بواسطة المحترفين وأن "Mocha" ، الذي كان الاسم الأولي لجافا سكريبت ، سوف يستخدمه أي شخص آخر.

بسبب هذا التعاون بين اللغات ، قرر Netscape أن Mocha يحتاج إلى تكمل Java ويجب أن يكون له بناء جملة مماثل نسبيًا. بعد ذلك ، في غضون 10 أيام فقط ، أنشأ Brendan الإصدار الأول من Mocha والذي لا يزال لديه بعض الوظائف من Scheme ، وتوجيه كائن SmallTalk ، وبناء جملة Java. في النهاية ، تغير اسم Mocha إلى LiveScript ، ثم تغير LiveScript إلى JavaScript كحيلة تسويقية لركوب الضجيج في Java. لذلك في هذه المرحلة ، تم تسويق JavaScript كلغة نصية للمتصفح - يمكن الوصول إليها من قبل كل من الهواة والمصممين بينما كانت Java هي الأداة الاحترافية لبناء مكونات الويب الغنية.

من المهم الآن فهم السياق الذي تحدث فيه هذه الأحداث. إلى جانب فوز نيكولاس كيج بجائزة الأوسكار ، كانت مايكروسوفت تعمل أيضًا على برنامج Internet Explorer. نظرًا لأن جافا سكريبت قد غيّر بشكل أساسي تجربة المستخدم على الويب ، فإذا كنت متصفحًا منافسًا ، فلن يكون لديك خيار سوى الدخول في تطبيق جافا سكريبت الخاص بك لأنه لم يتم توحيده بعد. لذلك ، هذا بالضبط ما فعلته شركة Microsoft وأطلقوا عليه اسم JScript.

هذا يؤدي إلى مشكلة مشهورة جدا في تاريخ الإنترنت. شغل JScript نفس حالة الاستخدام مثل JavaScript ، لكن تنفيذها كان مختلفًا. هذا يعني أنه لا يمكنك إنشاء موقع ويب واحد وتوقع أن يعمل على كل من Internet Explorer و Nestscape Navigator. في الواقع ، كان التطبيقان مختلفان إلى حد كبير بحيث أصبحت شعارات "Best view in Netscape" و "Best view in Internet Explorer" شائعة بالنسبة لمعظم الشركات التي لم تكن قادرة على البناء لكلا التطبيقين.

هذا هو المكان الذي يأتي Ecma في الصورة. Ecma International هي "جمعية صناعية تأسست في عام 1961 ، مكرسة لتوحيد نظم المعلومات والاتصالات." في نوفمبر من عام 1996 ، قدمت Netscape JavaScript إلى Ecma لوضع مواصفات قياسية.

من خلال القيام بذلك ، أعطى المنفذين الآخرين صوتًا في تطور اللغة ، ومن الناحية المثالية ، فإنه سيبقي التطبيقات الأخرى متسقة عبر المتصفحات. لذلك دعونا نتعمق في طريقة عمل Ecma.

كل المواصفات الجديدة تأتي مع معيار ولجنة. في حالة JavaScript ، المعيار هو ECMA-262 واللجنة التي تعمل على معيار ECMA-262 هي TC39. إذا بحثت عن معيار ECMA262 ، ستلاحظ أن مصطلح "JavaScript" لا يُستخدم أبدًا. بدلاً من ذلك ، يستخدمون مصطلح "EcmaScript" للحديث عن اللغة الرسمية. السبب في ذلك هو أن Oracle تمتلك العلامة التجارية لمصطلح "JavaScript" ، لذا لتجنب المشاكل القانونية ، استخدمت Ecma مصطلح EcmaScript بدلاً من ذلك.

في العالم الواقعي ، يستخدم ECMAScript عادة للإشارة إلى المعيار الرسمي ، EMCA-262 ، بينما يتم استخدام JavaScript عند التحدث عن اللغة في الممارسة. كما ذكرنا سابقًا ، فإن اللجنة التي تشرف على تطور معيار Ecma262 هي TC39 ، والتي تمثل اللجنة الفنية 39.

يتكون TC39 من "أعضاء" هم عادة بائعو المستعرضات والشركات الكبيرة التي استثمرت بكثافة في الويب مثل Facebook و PayPal. لحضور الاجتماعات ، سيقوم "الأعضاء" (مرة أخرى ، الشركات الكبيرة وبائعي المستعرضات) بإرسال "مندوبين" لتمثيل الشركة المذكورة أو المتصفح. هؤلاء المندوبون هم المسؤولون عن إنشاء اقتراحات لغوية أو الموافقة عليها أو رفضها.

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

يبدأ كل اقتراح جديد في المرحلة 0. وتسمى هذه المرحلة مرحلة Strawman. مقترحات المرحلة 0 هي "المقترحات التي من المقرر تقديمها إلى اللجنة من قبل بطل TC39 أو ، تم تقديمها إلى اللجنة ولم يتم رفضها نهائيًا ، لكنها لم تحقق بعد أيًا من المعايير للدخول في المرحلة 1." الشرط الوحيد لكي تصبح مقترح المرحلة 0 هو أنه يجب مراجعة الوثيقة في اجتماع TC39. من المهم ملاحظة أن استخدام ميزة Stage 0 في قاعدة بياناتك يعد أمرًا جيدًا ، ولكن حتى إذا استمرت في أن تصبح جزءًا من المواصفات الرسمية ، فمن المؤكد أنها ستخضع لبعض التكرار قبل ذلك.

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

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

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

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

اعتبارًا من عام 2016 ، يتم إصدار نسخة جديدة من ECMAScript كل عام مع أي ميزات جاهزة في ذلك الوقت. ما يعنيه ذلك هو أن أي مقترحات من المرحلة 4 موجودة عند حدوث إصدار جديد ، سيتم تضمينها في الإصدار لتلك السنة. نظرًا لدورة الإصدار السنوية هذه ، يجب أن تكون الميزات الجديدة أكثر تدريجيًا وأسهل اعتمادًا.

هذا جزء من دورة tylermcginnis.com الخاصة بي "JavaScript الحديثة".