Ингвар Степанян из Cloudflare написал статью про объяснение принципа работы Binary AST — "Faster script loading with BinaryAST?"

Binary AST — это предложение в TC39, цель которого ускорить парсинг JavaScript. Парсинг может быть основной причиной медленного старта приложений на слабых устройствах. Например, на флагманских смартфонах парсинг 1Мб JavaScrpt занимает 100ms, в то время как на слабых устройствах (Moto G4) — более секунды. С помощью Binary AST на этапе сборки можно представить AST JavaScript в бинарном виде с дополнительными хинтами, которое позволяет ускорить парсинг до 90% в синтетических тестах.

Ингвар в статье также рассказывает про то, каким образом Cloudflare внедрил поддержку Binary AST. Они используют кодировщик Binary AST, который написан на Rust. Исходный JavaScript при этом парсится с помощью Shift в инстансе v8. На данный момент их следующая цель — сбор данных с реальных проектов, чтобы улучшить формат представления AST.

Binary AST находится на первом этапе рассмотрения в TC39. Прототип реализации уже добавлен в Nightly-версию Firefox. Над развитием стандарта работает Mozilla, Cloudflare, Facebook и Bloomberg.

#js #proposal #tc39

https://blog.cloudflare.com/binary-ast/

Вчера увидел ссылку на статью Марка Миллера (участник TC39) "The Tragedy of the Common Lisp: Why Large Languages Explode".

Несмотря на название статьи речь в ней идёт про JavaScript. Марк работает над стандартизацией языка с 2007 года. Он очень заботится о том, чтобы язык оставался минимальным и элегантным. В статье он объясняет, почему избирательно подходит к выбору того, что будет добавлено в ECMAScript. По его мнению, минимализм языка является тем качеством, который ценят большинство разработчиков. Осознание того, что мы полностью понимаем принципы работы инструмента, ведёт к чувству удовлетворения.

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

В конце статьи он призывает (видимо, своих коллег по TC39) стремиться к дисциплине, чтобы возможности языка не разрослись до такой степени, когда язык не даёт удовлетворения от его использования.

#js #tc39 #musings

https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9

Пару дней назад Матиас Байненс из команды v8 твитнул о том, что новые методы массивов flat и flatMap доступны во всех стабильных версиях браузеров и Node.js. Этот твит напомнил мне старую трагедию, которая развернулась из-за проблемы с flatten (предыдущее название `flat`).

Если говорить кратко, то добавление реализации flatten сломало как минимум один популярный сайт в Firefox Nightly. Причиной поломки была библиотека MooTools, которая содержала свою реализацию этого метода. Один из участников комитета TC39 завёл тикет про переименование flatten в smoosh. Это вызвало сильные волнения в js-сообществе — очень много разработчиков негодовало из-за нелогичного названия. Оказалось, что это была внутренняя шутка TC39, которую плохо донесли до сообщества. Как результат Матиас написал пост "#SmooshGate FAQ", в котором постарался объяснить, почему бы это название не прошло в стандарт, даже если бы это была не шутка. Спустя некоторое время, участники комитета TC39 переименовали flatten во flat.

Если интересуетесь историей развития web'а или хотите узнать немного больше о том, как принимаются решения в TC39, обязательно почитайте статью.

#history #tc39

https://developers.google.com/web/updates/2018/03/smooshgate

Пару дней назад в код v8 была добавлена реализация предложения "Top-level await" (Stage 3). Про этот пропозал в канале ещё ничего не было, поэтому хочу написать небольшое объяснение того, какую проблему он решает.

Top-level await добавляет поддержку await на верхнем уровне модуля, то есть вне асинхронных функций, которые декларируются с помощью async. Это позволяет превратить модуль в некое подобие большой асинхронной функции. При импорте такого модуля асинхронный код, помеченный с помощью ключевого слова await, будет останавливать выполнение импортирующего модуля до того момента, пока все зависимости не будут зарезолвлены. Вот пример преобразования "асинхронного модуля" с помощью top-level await:

// было
import { process } from "./some-module.mjs";
export default (async () => {
  const dynamic = await import(computedModuleSpecifier);
  const data = await fetch(url);
  const output = process(dynamic.default, data);
  return { output };
})();

// стало
import { process } from "./some-module.mjs";
const dynamic = import(computedModuleSpecifier);
const data = fetch(url);
export const output = process((await dynamic).default, await data);

Добавление в стандарт top-level await упростит работу с динамическими импортами и модулями, предоставляющими асинхронные ресурсы, например, соединение с базой данных.

#future #async #tc39

https://github.com/tc39/proposal-top-level-await

Матиас Байненс в блоге v8 опубликовал небольшой пост про новый метод строк replaceAll.

Для того чтобы заменить все вхождения подстроки в JS, нужно использовать String.replace с глобальным регулярным выражением в первом аргументе: 'aabbcc'.replace(/b/g, '_'). Более того, надо помнить про эксейпинг специальных символов, например, для замены всех символов + надо использовать выражение 'a+b+c'.replace(/\+/g, ''). Это не очень удобно.

Для решения этой проблемы в следующем стандарте ECMAScript запланировано добавление нового метода String.replaceAll. С его помощью последний пример может переписан так: 'a+b+c'.replaceAll('+', ''). Для консистентности с replace первым аргументом можно передавать регулярное выражение, но оно обязательно должно быть глобальным.

На данный момент String.replaceAll находится на третьем этапе добавления в стандарт. Пока его поддержка есть только в v8 за экспериментальным флагом.

#tc39 #js

https://v8.dev/features/string-replaceall

Недавно увидел твит от разработчика Chrome, в котором он написал, что перевод пропозала Temporal в stage 3 запланирован на февраль. Temporal — это современная замена объекта Date. В 2017 году Мэгги Джонсон-Пит написала две статьи про причины добавления в стандарт нового объекта — "Fixing JavaScript Date".

API существующего объекта Date было скопировано в 1995 году из Java. Это были ранние годы для Java, поэтому java.Util.Date там был плохо проработан. Всё было настолько плохо, что в Java 1.1, которая была выпущена в 1997 году, фактически все существующие методы были объявлены устаревшими и заменены новыми. В JavaScript не было исправлений Date из-за того, что это бы сломало web.

Спустя 20 лет было решено сделать независимую реализацию API для работы с датами и временем, которая получила название Temporal. Её ключевые отличия от Date: иммутабельность, исправленный парсинг строки в дату, исключение дополнительной секунды, добавлены методы для работы с временными зонами, предусмотрено будущее расширение спецификации для работы с негригорианскими календарями и т.п.

Библиотеки для работы со временем потеряют свою актуальность, после того как Temporal будет поддержан во всех браузерах. Для того чтобы не сломать старые браузеры, можно будет пользоваться полифиллом.

#date #tc39 #history #future

https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/
https://maggiepint.com/2017/04/11/fixing-javascript-date-web-compatibility-and-reality/

Никогда такого не было и вот опять. Пару дней назад в твиттере выясняли, что лучше использовать const или let.

На этот раз этот всё началось с твита Дэна Абрамова, в котором он пошутил над участниками Reddit по поводу его недавней статьи, где он предлагал использовать let. В треде он упомянул старый твит, в котором разработчики стандарта признают, что добавление двух способов для декларации переменных в блочном скоупе было ошибкой. Также в тред пришёл Аллен Вирфс-Брок — участник TC39, работавший над ES2015. Он написал, что const и let — наследие ES4, которому не придали большого внимания при переносе в ES2015. Аллен пишет, что если бы он мог это исправить, то оставил бы только const, но переименовал бы его в let. Затем в тред пришёл Брендан Айк и написал, что добавление const было вынужденной мерой, так как в некоторых движках он уже был имплементирован.

В итоге Дэн написал статью "On let vs const", где сравнил преимущества и недостатки использования eslint-правила prefer-const. Вывод простой — используйте то, что вам больше нравится.

#history #es2015 #tc39

https://overreacted.io/on-let-vs-const/
https://twitter.com/littlecalculist/status/917875241891676160
https://twitter.com/awbjs/status/1208447372910444544

Я Серёжа Рубанов, приглашённый эксперт #TC39 (комитета, занимающегося разработкой ECMAScript) и основатель канала @juliarderity.

Сегодня начигается 76я встреча TC39, которая станет второй полностью удалённой. В этот раз встреча будет длиться 4 дня по 5 часов вместо 2 дней по 7 часов и заключительного 6-часового.
Повестка очень интересная! Я уже писал обо всех пропозалах, которые готовятся к продвижению на следующий стейдж. С этой публикацией можно ознакомиться вот тут.
Как всегда буду рассказывать всё самое интересное в этом канале. Если что-то невероятно интересное или важное то сразу же лайвом, а также буду публиковать результаты каждого дня ближе к ночи.
Время проведения встреч — 15:00 - 20:00 UTC, для большинства читателей это будет 18:00 - 23:00 (по Москве, Киеву, Минску).

Мне будет приятно если Вы поделитесь этой записью в своих каналах или в сообществах, участникам которых это может быть интересно. Ещё можно поддержать на Patreon.

Оператор конвейера в JavaScript (pipeline operator)

Аксель Раушмайер написал статью об операторе конвейера (pipeline operator, pipe operator) — новом операторе, над которым идёт работа в TC39 — "A pipe operator for JavaScript: introduction and use cases".

Есть два конкурирующих пропозала с реализацией оператора конвейера: конвейер в F#-стиле и Hack-стиле. Оба пропозала вводят в язык оператор |>, благодаря которому упрощается композиция функций:

// стандартная композиция
const y = h(g(f(x)));
// композиция с пайпом в Hack-стиле
const y = x |> f(%) |> g(%) |> h(%);
// композиция с пайпом в F#-стиле
const y = x |> f |> g |> h;

Несмотря на то что пропозал c конвейером в F#-стиле выглядит чище, у него больше недостатков по сравнению с конвейером в Hack-стиле: нужно использовать каррирование, усложняется добавление поддержки yield и await, больше накладных расходов на память. По этим причинам работа над F#-версией конвейера была остановлена.

На данный момент пропозал о добавлении конвейера в Hack-стиле находится на Stage 2, и его поддержки нет ни в одном браузере.

#js #tc39 #proposal

https://2ality.com/2022/01/pipe-operator.html