Історія 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. Важливо зауважити, що використання функції Stage 0 у вашій кодовій базі добре, але навіть якщо вона й надалі стає частиною офіційної специфікації, до цього майже напевно пройде кілька ітерацій.

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

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

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

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

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

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