Том МакРайт рассказал о своём подходе к работе с зависимостями — "Vendor by default".

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

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

#npm #js #musings

https://macwright.com/2021/03/11/vendor-by-default.html

Лин Кларк опубликовала статью, посвящённую оптимизации работы JavaScript-кода в WebAssembly-окружении — “Making JavaScript run fast on WebAssembly”.

Некоторые платформы ограничивают набор оптимизаций, которые могут быть применены к JavaScript-коду. Например, на iOS и игровых консолях нельзя использовать JIT-компилятор, поэтому JS-движки там могут работать только в режиме интерпретатора. Это ограничивает спектр задач, который может быть решён с помощью JS. Участники Bytecode Alliance (Fastly, Mozilla, Igalia) работают над решением на базе WebAssembly, которое позволит ускорить выполнение JS-кода на таких платформах и достичь уровня производительности JIT-компиляторов ранних версий JavaScript-движков.

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

В статье говорится о том, что подобный подход может использоваться не только с JavaScript, но и с Python, Ruby, Lua.

#js #internals #webassembly

https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly

Сегодня Стэфан Джудис твитнул про то, что в Chrome 91 появилась поддержка JSON-модулей. Это новая фича JavaScript, с помощью которой можно использовать import с JSON-файлами. Твит Стэфана дополнил Аксель Раушмайер ссылкой на статью про Import Assertions.

Синтаксис для импорта JSON немного отличается от стандартного импорта:

// статический импорт
import config from './data/config.json' assert { type: 'json' };

// динамический импорт
import('./data/config.json', { assert: { type: 'json' } })

Добавление assert декларирует намерение разработчика импортировать файл заданного типа. Это нужно делать явно, потому что на расширение имени файла в мире веба полагаться нельзя.

Import Assertions находится в статусе пропозала на stage 3. Он открывает дорогу для импорта не только JSON, но и WebAssembly-модулей и CSS-файлов.

#js #proposal #chrome

https://2ality.com/2021/01/import-assertions.html

Мэттью Гауде — разработчик SpiderMonkey — написал статью про опыт имплементации приватных полей класса в JavaScript-движке — "Implementing Private Fields for JavaScript".

Мэттью пишет о том, что при добавлении новой фичи в движок нужно учитывать три аспекта: ментальную модель, спецификацию и реализацию. Иногда они совпадают друг с другом, и имплементация сводится к пошаговой реализации алгоритма из спецификации. Иногда они расходятся, и имплементация начинает сильно отличаться от спецификации, сохраняя только семантику. Реализация приватных полей попала во вторую категорию.

Также в статье разбираются нюансы работы c приватными полями. Оказывается, приватные поля могут быть добавлены к любому объекту, даже если он был явно закрыт от изменений с помощью Oblect.seal(). Насколько я понимаю, это "побочный эффект" спецификации, и его не стоит использовать для решения своих задач.

Очень интересная статья. Рекомендую почитать.

#js #internals #spec #firefox

https://www.mgaudet.ca/technical/2021/5/4/implementing-private-fields-for-javascript

Анализ JS-бандла с помощью Lighthouse Treemap

Сиа Кармаленгос написала статью про новый инструмент анализа JS-бандлов, доступный в Lighthouse — "Explore JavaScript Dependencies With Lighthouse Treemap".

В последних версиях Lighthouse появилась новая фича — визуализация JS-бандлов с помощью Treemap. Если вы знакомы с webpack-bundle-analyzer, то уже можете представить себе новый инструмент. Основное отличие Treemap в Lighthouse — возможность анализа бандлов любых сборщиков. Если сборка происходит с генерацией сорс-мапов, то в Treemap будут отображаться названия модулей. Но самая интересная функция — оценка покрытия кода. Если включить опцию "unused bytes", то можно оценить сколько кода было загружено, но не выполнено.

Поддержка Lighthouse Treemap уже доступна в сервисе PageSpeed Insights, Lighthouse Node CLI и Chrome Canary.

#tool #js #bundle #performance

https://sia.codes/posts/lighthouse-treemap/

Влияние потребления памяти на производительность

Тим Кадлек попробовал сформировать критерии оптимального потребления памяти страницы — "Benchmarking JavaScript Memory Usage".

В Chrome 83 появилась возможность измерения потребляемой памяти страницы с помощью метода performance.measureMemory. В январе 2021 года он был переименован в performance.measureUserAgentSpecificMemory. Несмотря на то что API существует уже довольно долго, разработчики ещё не полностью понимают, как его использовать для анализа производительности страницы. Основная проблема — недостаток данных, чтобы понимать какой объём потребляемой памяти считать приемлемым, а какой избыточным.

Тим пытается ответить на этот вопрос с помощью сбора метрик с 10000 популярных сайтов и распределения результатов по перцентилям. В итоге он предложил следующее распределение:
— хорошо: <4.8MB
— нуждается в улучшении: >4.8MB и <19.4MB
— плохо: >19.4MB

Также в статье есть исследование влияния используемых JS-фреймворков на объём потребляемой памяти. Больше всего памяти потребляют React и Angular. Это объясняется бо́льшим количеством доставляемого кода по сравнению с Vue и jQuery.

#js #performance

https://blog.webpagetest.org/posts/benchmarking-javascript-memory-usage/

Partytown — запуск сторонних скриптов в веб-воркере

Автор фреймворка Ioinic Адам Бредли представил новую библиотеку для запуска сторонних скриптов в веб-воркере — "Introducing Partytown: Run Third-Party Scripts From a Web Worker".

Разработчики JS-фреймворков вкладывают много сил, чтобы пользовательские приложения были быстрыми и отзывчивыми. Эти усилия могут нивелировать сторонние скрипты. Например, добавление на сайт Google аналитики срезает 20 баллов производительности в Lighthouse, так как увеличивается время инициализации страницы.

Partytown позволяет вынести сторонние скрипты в веб-воркер, разгружая основной поток выполнения. У скриптов в воркере появляется синхронный доступ к DOM, который реализуется с помощью Proxy и блокирующих XHR-запросов.

На данный момент доступна альфа-версия библиотеки. Простестирован сандбоксинг скриптов Google Analytics, Google Tag Manager, Amplitude и нескольких других сервисов.

Очень полезная библиотека, попробую её у себя в проекте.

#js #library #performance

https://dev.to/adamdbradley/introducing-partytown-run-third-party-scripts-from-a-web-worker-2cnp

Поиск необработанных промисов

Свизек Теллер написал статью про ошибки, приводящие к возникновению необработанных промисов — "Finding unresolved promises in JavaScript".

Необработанные промисы — это большой источник проблем, который может привести к крешу программы. Они возникают при забытом перехвате исключения с помощью catch, при отсутствующем вызове resolve / rejet или при забытом return в цепочке промисов.

Свизек нашёл научную статью "Finding broken promises in asynchronous JavaScript programs", в которой авторы попробовали автоматизировать поиск подобных ошибок и создали утилиту PromiseKeeper. Идея интересная, но похоже, что работу над проектом остановили после публикации статьи.

#async #js #experimental

https://swizec.com/blog/finding-unresolved-promises-in-javascript/

Утечка исходных кодов из source maps (сорс мапов)

Попалась на глаза статья про потенциальные проблемы сорс мапов — "Source-maps could be revealing your private project files".

Сорс мапы — это служебные файлы, содержащие исходный проекта. Они используются для облегчения отладки транспилированного кода. Если сорс мапы доступны в проде, то любой человек может посмотреть исходный код проекта. Для бизнеса это может быть большой проблемой.

В общем, статья про довольно известные вещи. Я бы не стал про неё писать, если бы не вспомнил про ещё одну статью — "Топ тупых лазеек для исследования конкурентов: source map". В этой статье автор рассказывает про доступ к исходным кодам фронтенда Яндекс.Еды с помощью сорс мапов. Также он настроил переодическую автоматическую выгрузку кода в GitHub, чтобы следить за процессом разработки фронта.

Как бы то ни было, статьи полезные. И на всякий случай ещё разок проверьте, не доступны ли в проде сорс мапы для ваших проектов.

#js #security

https://levelup.gitconnected.com/automatically-generated-source-maps-could-be-revealing-your-private-projects-files-17b2d13d7da4
https://teletype.in/@opendevcast/SyYaunCHB

Не пишите квадраты

Степан Зубашев критикует современные тренды написания JavaScript-кода — "Обращение к Javascript-сообществу: перестаньте писать квадраты".

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

source.reduce(
  (acc, item) => acc.concat(func(item)),    
  [] 
);

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

Степан призывает не ставить в абсолют краткость кода и задумываться о производительности.

#js #algorithm #performance

https://habr.com/ru/post/590663/

Глубокое клонирование объектов с помощью structuredClone

Сурма из Google рассказал про новое API для глубокого клонирования JavaScript-объектов — "Deep-copying in JavaScript using structuredClone".

Самым популярным решением для глубокого клонирования объектов был JSON-хак:

const myDeepCopy = JSON.parse(JSON.stringify(myOriginal));

Он стал настолько популярен, что в браузерах были добавлены специальные оптимизации для этого хака. На данный момент он остаётся самым быстрым способом для глубокого клонирования небольших объектов. Однако он не поддерживает объекты с циклическими ссылками, Map, Set, Date, RegExp и ArrayBuffer.

Структурное клонирование — это другое название для глубокого клонирования. Оно использовалось браузерами неявно при передаче объектов с помощью postMessage и сохранении объектов в IndexedDB. Новый метод structuredClone открывает удобный доступ к этому механизму клонирования без недостатков JSON-хака:

const myDeepCopy = structuredClone(myOriginal);

Поддержка strucutredClone на данный момент есть в Firefox 94, в nightly-версии Chrome и Safari TP.

#js #api

https://web.dev/structured-clone/

Группировка элементов массива с помощью groupBy

На последней встрече TC39 пропозал groupBy перешёл на stage 3. Лаури Барт рассказала о том, как он работает — "Array Grouping Explainer".

Группировка элементов массива распространённая операция. Она поддерживается всеми популярными утилитарными библиотеками (lodash, ramda). Пропозал реализует похожий алгоритм из этих библиотек. Метод groupBy принимает коллбек, в параметрах которого передаются текущий элемент, текущий индекс и сам массив. Элементы массива разбиваются на группы на основе строки, которая возвращается коллбеком. В результате получается объект с распределёнными элементами массива:

const names = ['vasya', 'vasilisa', 'oleg'];
const groupedNames = names.groupBy(name => {
 return name.charAt(0);
}
// результат:
// {v: ['vasya', 'vasilisa'], o: ['oleg']}

Также в пропозале есть второй метод groupByToMap, который работает точно также как groupBy, но возвращает не объект, а Map.

#js #proposal

https://laurieontech.com/posts/array-grouping/

Возможно, вам не нужен Rust и WASM, если у вас есть JavaScript

Увидел в канале @ufostation ссылку на статью Вячеслава Егорова про анализ проблем производительности библиотеки source-map — "Maybe you don't need Rust and WASM to speed up your JS".

Авторы source-map переписали основную логику библиотеки на Rust и WebAssembly, чтобы улучшить производительность. Егор решил проверить оригинальный код на предмет возможных оптимизаций. Там были найдены и исправлены проблемы, связанные с неоптимальной сортировкой, была уменьшена нагрузка на сборщик мусора заменой большого числа объектов типизированным массивом с ссылками на нужные данные, была испралвена проблема с деоптимизацией кода, связанной с передачей двух аргументов в функцию, которая ожидает на вход три аргумента.

В результате всех оптимизаций JavaScript-код стал уступать по скорости Rust и WebAssembly всего лишь на 15%.

Крутая статья. Рекомендую почитать всем.

#performance #js #internals #webassembly #rust

https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
https://habr.com/ru/post/350018/ (перевод на русский)

Пропозал "await.ops"

Недавно узнал про пропозал "await.ops" — расширение await операторами await.all, await.any, await.race и await.allSettled. Они работают точно также как одноимённые методы у Promise.

Благодаря новым операторам код получается немного короче, так как отпадает необходимость в написании Promise:

// до
await Promise.all(users.map(async x => fetchProfile(x.id)))

// после
await.all users.map(async x => fetchProfile(x.id))

На данный момент "await.ops" находится на Stage 1, и его поддержки в браузерах нет. Авторы ищут дополнительные сценарии использования предложения для его продвижения на Stage 2.

#js #proposal

https://github.com/tc39/proposal-await.ops

Абсолютные импорты в JavaScript

Евгений Карагодин написал статью про настройку абсолютных импортов — "Абсолютные импорты в JavaScript".

Относительные пути в спецификаторах импортов могут быть неудобны в проектах с глубокой вложенностью директорий. Поэтому были придуманы разные способы для импорта файлов от корня проекта. В статье рассказывается про основные способы упрощения работы с импортами. Про сложность настройки абсолютных импортов в Node.js-проектах c TypeScript и тест-раннерами.

Процесс настройки абсолютных импортов должен стать проще после имплементации спецификация import maps, с помощью которой можно управлять резолвингом модулей. На данный момент import maps поддерживаются только в Deno.

#js #esm

https://blog.ekaragodin.com/TH2jgliMXOO

Cовременные возможности для работы с JavaScript-модулями

Аксель Раушмайер написал статью про современные возможности для работы с JavaScript-модулями — "Publishing and consuming ECMAScript modules via packages – the big picture".

Последние версии Node.js поддерживают package exports и package imports. Package exports используются авторами библиотек для настройки путей, по которым будет доступен импорт модулей. Package imports позволяют создавать альясы на пакеты или модули. Их можно использовать для подмены реализации модуля в зависимости от окружения. Package exports и package imports настраиваются в package.json.

В браузерах скоро появится поддержка import maps. С их помощью можно создавать альясы, относительно которых будут резолвиться спецификаторы модулей в браузере. Это полезно при доставке кода пользователям в чистом ESM, когда в названии файлов модулей есть хеши. Import maps уже используют в проде авторы почтового клиента hey.

#js #esm #nodejs #npm

https://2ality.com/2022/01/esm-specifiers.html

Сравнение производительности Array.push и Array.concat

Ши Лин сравнила производительноcть методов .push и .concat у массивов — "Javascript Array.push is 945x faster than Array.concat".

Ши разрабатывает фреймворк для автоматического тестирования. У одного пользователя фреймворка скорость выполнения тестов снизилась в несколько раз. Выяснилось, что для работы с DOM-деревом фреймворк собирал все элементы страницы в одномерный массив с помощью .concat. Так как каждый вызов .concat создаёт новый массив, это негативно сказывалось на производительности прогона тестов.

В статье есть несколько бенчмарков, которые показывают, что объединение массивов с помощью .push(...arr) на два порядка быстрее .concat(arr).

Добавлю свои пять копеек. Заменять .concat(arr) на .push(...arr) стоит только там, где есть проблема, так как на очень больших массивах .push(...arr) выкинет ошибку переполнения стека.

#js #performance

https://dev.to/uilicious/javascript-array-push-is-945x-faster-than-array-concat-1oki

Оператор конвейера в 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

Выбор библиотеки по её размеру

Владимир Клепов рассказал про подводные камни выбора библиотек с использованием размера как основной метрики — "Don't trust JS library size, min+gzip".

В статье Владимир пишет о том, что размер библиотеки в Readme, может не отражать реальный процент бандла, который она будет занимать. Обычно код жмётся лучше, чем больше в приложении используется стороннего кода. Также пайплайн сборки может оказывать негативный эффект на размер из-за транспиляции в старую версию JavaScript. Иногда меньший размер библиотеки означает, что нужно использовать больше кода по сравнению с альтернативной библиотекой с большим размером, поэтому размер в этом случае не имеет значения.

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

Хорошая статья. Рекомендую почитать.

#js #performance #musings

https://thoughtspile.github.io/2022/02/15/bundle-size-lies/

Обработка ошибок с помощью reportError

Стэфан Джудис рассказал про малоизвестный метод для облегчения обработки ошибок в библиотечном коде — "New in JavaScript: reportError – a method to report to global event handlers".

Для логирования ошибок на странице часто устанавливают глобальный обработчик события error. Библиотеки могут редиректить возникающие исключения в этот глобальный обработчик с помощью setTimeout, но такой код выглядит как хак. Для упрощения решения этой проблемы в платформу был добавлен специальный метод reportError:

try {
  fn();
} catch (error) {
  // добавление кастомной обработки исключений и
  // вызов глобального обработчика
  reportError(error);
}

Поддержка метода reportError есть во всех актуальных браузерах.

#js

https://www.stefanjudis.com/blog/reporterror-a-method-to-report-to-global-event-handlers/