Історія JavaScript: ECMAScript, TC39 та новіших версій

JavaScript - це жива мова, яка постійно додає нові функції. Що я хочу зробити в цій публікації - це розбити цей процес і показати кроки, необхідні для того, щоб нова функція перейшла від простої ідеї до частини офіційної специфікації. Для цього нам потрібно буде охопити три речі: ECMA, ECMAScript і TC39.

Зауважте, що я також записав відео-версію цієї статті, якщо ви хочете переглянути це:

Повернемося до 1995 року. Культовий класичний важкі ваги був у театрах, Ніколя Кейдж отримав "Оскар", а веб-сайти виглядали приблизно так. Тепер шанси - це те, як ви переглядали цей веб-сайт за допомогою Netscape Navigator.

У той час Netscape Navigator був найпопулярнішим веб-браузером з майже 80% часткою ринку. Засновником компанії Netscape, компанії, що стоїть за Netscape Navigator, був Марк Андрессен. У нього було бачення майбутнього Інтернету, і це було більше, ніж просто спосіб обміну та розповсюдження документів. Він передбачив більш динамічну платформу з інтерактивністю на стороні клієнта - свого роду "клейовий лангаж", який був легким у використанні як дизайнерами, так і розробниками.

Ось тут в картину входить Брендан Ейх. Він був набраний Netscape з метою вбудувати мову програмування Scheme в Netscape Navigator. Але перш ніж він міг розпочати роботу, Netscape співпрацював з Sun Microsystems, щоб зробити їх доступною та доступною мовою програмування Java доступною у браузері. Тепер виникає питання: «Якщо Java вже була підходящою мовою, навіщо брати Brendan для створення ще однієї?».

Добре, якщо ви пам’ятаєте про мету Netscape, вони хотіли, щоб мова дизайнерів була достатньо простою для дизайнерів та любителів користування - Java це не була. Так виникла ідея, що Java можуть бути використані професіоналами, а "Mocha", яка була початковою назвою JavaScript, буде використана всіма іншими.

Через таку співпрацю між мовами, Netscape вирішив, що Mocha потрібно зробити комплімент Java та має відносно схожий синтаксис. Тоді, всього за 10 днів, Брендан створив першу версію Mocha, яка все ще мала певну функціональність від Scheme, орієнтацію об'єкта SmallTalk та синтаксис Java. Врешті-решт ім'я Mocha змінилося на LiveScript, а потім LiveScript перетворився на JavaScript як маркетинговий склад для їзди на Java. Таким чином, на даний момент JavaScript був проданий як сценарій мови для браузера - доступний як любителям, так і дизайнерам, тоді як Java був професійним інструментом для створення багатих веб-компонентів.

Тепер важливо зрозуміти контекст, коли ці події відбувалися. Крім Ніколя Кейджа, який отримав "Оскар", Microsoft також працювала над Internet Explorer. Оскільки JavaScript принципово змінив користувальницьку роботу в Інтернеті, якщо ви був конкуруючим браузером, у вас не було іншого вибору, як придумати власну реалізацію JavaScript, оскільки вона ще не була стандартизована. Отже, саме це зробило Microsoft, і вони назвали його JScript.

Це призводить до досить відомої проблеми в історії Інтернету. JScript заповнив той самий випадок використання, що і JavaScript, але його реалізація була іншою. Це означало, що ви не можете створити один веб-сайт і очікувати, що він буде працювати як в Internet Explorer, так і в Nestscape Navigator. Насправді дві реалізації були настільки різними, що логотипи "Найкраще переглядаються в Netscape" та "Найкраще переглядаються в Internet Explorer" стали загальними для більшості компаній, які не могли дозволити собі побудувати для обох реалізацій.

Ось тут Екма входить у картину. 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. Цей етап називається етапом соломки. Пропозиції на етапі 0 - це "пропозиції, які планується представити комітету чемпіоном TC39 або, вони були представлені комітету і не були остаточно відхилені, але ще не виконали жодного з критеріїв, щоб перейти на етап 1". Єдиною вимогою, щоб стати пропозицією на етапі 0, є те, що документ повинен бути розглянутий на засіданні TC39. Важливо зауважити, що використання функції Етап 0 у вашій кодовій базі добре, але навіть якщо вона й надалі стає частиною офіційної характеристики, до цього майже напевно пройде кілька ітерацій.

Наступним етапом зрілості нової пропозиції є Етап 1. Для того, щоб перейти до 1-го етапу, повинен бути визначений офіційний «чемпіон», який входить до складу TC39 і несе відповідальність за пропозицію. Крім того, пропозиція повинна описати проблему, яку вона вирішує, мати наочні приклади використання, API високого рівня та визначити будь-які потенційні проблеми та проблеми з впровадженням. Приймаючи пропозицію про етап 1, комітет повідомляє, що вони готові витратити ресурси, щоб детальніше розглянути пропозицію.

Наступний етап - етап 2. На даний момент більш ніж ймовірно, що ця функція згодом стане частиною офіційної специфікації. Для того, щоб перейти на другий етап, пропозиція повинна, формально кажучи, містити опис синтаксису та семантики нової функції. Іншими словами, пишеться чернетка або перша версія того, що буде в офіційній специфікації. Це етап для дійсного блокування всіх аспектів функції. Майбутні зміни все ще можуть відбутися, але вони повинні бути лише незначними, поступовими змінами.

Наступний етап - етап 3. Наразі пропозиція здебільшого закінчена, і зараз їй потрібні лише зворотний зв'язок від виконавців та користувачів, щоб прогресувати далі. Для того щоб перейти до 3-го етапу, текст специфікації повинен бути завершений та створити щонайменше два виконання специфікацій.

Останній етап - етап 4. На даний момент пропозиція готова до включення в офіційну специфікацію. Щоб потрапити на Етап 4, тести повинні бути складені, дві тестові програми повинні пройти ці тести, учасники повинні мати значний практичний досвід з новою функцією, а редактор специфікацій EcmaScript повинен вийти з тексту специфікації. В основному, коли пропозиція переходить на етап 4, вона готова перестати бути пропозицією та пробитися до офіційної специфікації. Це відображає останнє, що потрібно знати про весь цей процес, і це графік випуску TC39.

З 2016 року щорічно випускається нова версія ECMAScript з будь-якими можливостями, готовими до цього часу. Це означає, що будь-які пропозиції на етапі 4, які існують, коли відбудеться новий випуск, будуть включені до випуску за цей рік. Через цей щорічний цикл випуску нові функції повинні бути набагато більш поступовими та легшими у застосуванні.

Це частина мого курсу "сучасний JavaScript" на tylermcginnis.com.