Отправления из будущего JavaScript

Примечание автора: в этом посте, объясняя происхождение определенного языка программирования, я использую термины «JavaScript» и «ECMAScript®» как синонимы. Разница есть, но она педантична и сегодня не стоит вдаваться в подробности.

В августе 2017 года сотрудник PayPal, занимающийся разработкой JavaScripter Кент С. Доддс, связался со мной и предложил возможность: PayPal является обычным членом Ecma International, сказал он мне, и это означает, что PayPal может отправить любого делегата (делегатов), которого они могут желаете присутствовать на собраниях TC39, комитета, который пишет спецификации для JavaScript. Он хотел знать, не хочу ли я представлять в комитете PayPal, Braintree и Venmo. Я никогда не задумывался о том, откуда появился JavaScript, но внезапно мне захотелось узнать. Поэтому я сказал да, не особо задумываясь об обязательствах, а затем начал исследовать, для чего именно я вызвался.

Подожди - кто-нибудь это делает?

Все функции ES5 и ES6, которыми я был так восхищен несколько лет назад, должны были пройти через процесс комитета TC39. Изменения в спецификации не вносятся случайным образом разработчиком браузера, стремящимся реализовать функцию в их следующем выпуске, а проходят фактический процесс с реальными экспертами, которые знают, о чем они говорят.

Преданные своему делу люди, которые составляют TC39, происходят из самых разных профессий. У нас есть разработчики на всех уровнях взаимодействия с JavaScript: люди, которые работают над движками JavaScript, авторы фреймворков, веб-разработчики и многие другие. Такой смешанный опыт позволяет нам тщательно продумывать каждое принимаемое нами решение и понимать, как оно повлияет на любого, кто имеет дело с JavaScript.

Не ломай сеть

Руководящий принцип номер один, которому неуклонно придерживается комитет, - это «Не взламывать Интернет». Часто члены сообщества JavaScript не видят, насколько широко это применимо к каждому принимаемому нами решению.

Мы должны придерживаться этого принципа, потому что, в отличие от большинства языков, JavaScript должен быть обратно совместимым - навсегда. Размышляя о критических изменениях, мы не можем просто назвать это стартом основной версии и двигаться дальше - если что-то есть, это навсегда. (Только подумайте, что случится со всеми этими заархивированными сайтами Geocities, если мы удалим String.prototype.fontcolor(color)). (Пожалуйста, никогда, никогда не используйте String.prototype.fontcolor(color)). Мы уделяем пристальное внимание распространенному использованию в прошлом и принимаем во внимание любые рамки и соглашения, которые использовались регулярно в какой-то момент, даже если они не используются сейчас. Естественно, мы также стремимся делать все возможное, чтобы соответствовать требованиям завтрашнего дня. Мы не хотим усложнять себе задачу внесения дополнений или изменений в будущем. (Слово пушка разбрасывается много во время пленарного заседания.)

Мы также должны выйти за рамки спецификации ECMAScript®, чтобы убедиться, что наша работа хорошо сочетается со всем, с чем регулярно взаимодействует JavaScript. Несколько делегатов прямо или косвенно связаны с другими соответствующими органами по стандартизации, такими как W3C’s TAG, WHATWG, IETF и другими. Сотрудничая с другими группами по стандартизации, мы гарантируем, что противоречивые идеи могут быть проработаны, и что работа не будет без надобности дублироваться.

Именование вещей¹

Независимо от того, в сотрудничестве с другими организациями по стандартизации или независимо, TC39 должен вложить абсурдное количество мыслей, исследований и планирования в процесс присвоения имен вещам. Присвоение имен общеизвестно считается самым сложным в программировании, но при работе с таким языком, как JavaScript, это усложняется втрое. Помимо общих проблем, затрудняющих наименование, борьба усугубляется тем, что его нельзя изменить или удалить, а также не может быть настолько очевидным, что люди уже используют его таким образом, который может вызвать конфликт. . (См. Также, что тогда предложение Стадии 3 сломало flickr).

Средняя встреча

Когда мы собираемся лично на трехдневные пленарные заседания раз в два месяца, повестка дня следует предсказуемому формату, даже если содержание резко меняется. Пункты повестки дня поступают от редакторов наших различных публикаций, членов подкомитетов, обновлений от других органов по стандартизации, вопросов безопасности и, конечно же, обновлений предложений. (В одном из будущих постов я расскажу о процессе предложения, который приводит к добавлению большинства функций и изменений в JavaScript).

В начале первого дня редакторы и члены подкомитета отчитываются о своей деятельности в перерывах между заседаниями. Редакторы spec² находят время, чтобы сообщить всем обо всех изменениях и их значении для текущей работы. Дополнительные отчеты редактора включают отчеты из API интернационализации и спецификаций JSON, а также Test262, канонического набора тестов ECMAScript®. У нас также есть комитет по Кодексу поведения и несколько информационных подкомитетов, которые предлагают обновленную информацию о своей деятельности между встречами.

Подход TC39 к своей работе уникален в мире стандартов; решения принимаются консенсусом, а не голосованием, как в других органах по стандартизации. Основная причина этого различия - почти немедленное и неизбежное бремя, которое берут на себя заинтересованные стороны при внесении изменений и дополнений в язык. Следствием этого является то, что новые функции означают больше работы для разработчиков, которым нужен способ остановить (временно или навсегда) изменения, которые они не могут выполнить.

Поскольку нам нужен консенсус, разговоры могут легко выйти за рамки их временных рамок. Время от времени это может расстраивать, но позволяет выслушать опасения со всех сторон. JavaScript запускается в таком большом количестве сред - конечно, браузеры, но также нативные приложения, IoT, устройства и в пространстве, - что мы обнаруживаем неожиданные ограничения в ходе обсуждения.

Во время собраний небольшое количество достойных похвалы писцов делают заметки, достаточно подробные, чтобы их можно было рассматривать как стенограммы. Они также записывают окончательные выводы по рассматриваемой теме, какими бы они ни были. Примерно через две недели после того, как все разойдутся по домам, на GitHub публикуются заметки, которые могут прочитать все. Если вы когда-нибудь видели изменения в JavaScript и думали: О чем они, черт возьми, думали?, Заметки могут быть особенно полезными. История каждого заключения похоронена где-то в этом репо, и только ждет, чтобы ее прочитали.

Настоящая работа начинается

Основная часть работы TC39 происходит между встречами на GitHub и IRC. Извлеченные уроки и выводы, сделанные на предыдущем заседании, применяются к коду, описанию и тестам, найденным в репозиториях предложений. В мире браузеров и движков JavaScript инженеры начинают реализовывать функции, готовые для тестирования в реальных условиях. И, конечно же, bikeshedding³ изобилует проблемами GitHub.

Однако мы не тратим время на чисто техническую работу. В настоящее время мы разрабатываем несколько новых информационных групп для конкретных участников, таких как преподаватели и авторы рамок. Наша цель - предложить больше способов общения, чем просто вопросы GitHub и IRC, чтобы мы могли связаться с сообществом там, где они есть, и запросить отзывы. Также в разработке находится бета-сайт с информацией о текущих предложениях, ссылками на заметки о встречах и объяснениями того, что мы делаем и как.

Назад в Брейнтри

Я твердо убежден, что никому не нужно быть экспертом во всех аспектах JavaScript. Я работаю с TC39 как инженер-программист Braintree, а не как автор браузера или движка. Участие в процессе стандартизации действительно помогло понять, как сообщать о наиболее важных приоритетах разработки для Интернета. Эти приоритеты принимают разные формы, но принцип «Не ломайте Интернет» должен быть принципом не только для этого комитета, но и для всех, кто работает над SDK, создает фреймворки или публикует пакеты любого типа. Когда дело доходит до создания продуктов, от которых зависят люди, мой менеджер недавно посоветовал: «Двигайтесь медленно и поддерживайте вещи».

Этот пост - всего лишь введение в то, что делает TC39 и как мы работаем вместе, чтобы продвигать JavaScript вперед. В качестве сопредседателя в 2019 году я с нетерпением жду возможности более подробно рассказать о работе комитета и убедиться, что новые голоса будут услышаны. Если вы хотите, чтобы я осветил определенный аспект TC39 в другом посте, напишите мне на [email protected].

  1. Да, эта песня застряла в моей голове. Хорошее название.
  2. Для ES2019 главный редактор Брайан Терлсон с редакторами Джордан Харбанд и Брэдли Фариас
  3. Велосипедный шеддинг, также известный как закон тривиальности Паркинсона, - это идея, согласно которой организации придают непропорционально большое значение тривиальным вопросам. Вымышленный пример, который привел Паркинсон, был комитетом, анализирующим планы атомной электростанции, но проводившим большую часть своего времени за обсуждением таких деталей, как цвет и конструкция навеса для служебных велосипедов, игнорируя при этом более сложную проблему проектирования самой станции. Хотя это общая проблема в программировании в целом, TC39 считает ее важной частью нашего процесса.