Андреа Гиммарачи написал статью о том, почему некорректно называть JavaScript-классы синтаксическим сахаром для прототипного наследования — "JS classes are not 'just syntactic sugar'".

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

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

#js

https://webreflection.medium.com/js-classes-are-not-just-syntactic-sugar-28690fedf078
https://www.reddit.com/r/javascript/comments/mq9upa/js_classes_are_not_just_syntactic_sugar/ (обуждение на Reddit)

Николас Закас написал статью про ленивый доступ к свойствам объекта — "The lazy-loading property pattern in JavaScript".

Если в объекте есть свойство, значением которого является результат выполнения тяжёлого вычисления, то имеет смысл отложить это вычисление до того момента, пока не произойдёт обращение к свойству. Николас предлагает использовать паттерн, который позволяет не только откладывать вычисление, но и кеширует результат его выполнения:

const object = {
  get data() {
    const actualData = someExpensiveComputation();

    Object.defineProperty(this, "data", {
      value: actualData,
      writable: false,
      configurable: false,
      enumerable: false
    });

    return actualData;
  }
};

Этот подход можно использовать с любыми объектами и классами.

#js #performance

https://humanwhocodes.com/blog/2021/04/lazy-loading-property-pattern-javascript/

Карло Пиовесан — разработчик Cheerp — попробовал выяснить, можно ли в автоматическом режиме преобразовать JavaScript-код в эквивалентный более производительный JavaScript-код и поделился результатами своего исследования в статье "A JavaScript optimizing compiler".

Карло написал очень ограниченный транспилятор из JavaScript в C++. Прогнал через него код бенчмарков. Затем получившийся C++-код скомпилировал обратно в JavaScript-код с помощью Cheerp с применением оптимизаций на уровне компилятора (Cheerp — это компилятор, построенный на базе LLVM, аналог Emscripten).

В результате такого преобразования кода, большинство бенчмарков показали прирост производительности. Особенно хорошо показал себя код для проверки простых чисел — он стал быстрее на 80%.

Этот подход нельзя использовать в продакшене, так как транспилятор из JavaScript в C++ очень хрупкий и покрывает только небольшое подмножество JavaScript. Тем не менее проведённый эксперимент говорит о том, что у этой стратегии оптимизации есть право на жизнь.

#experimental #js #performance

https://medium.com/leaningtech/a-javascript-optimizing-compiler-3fd3f49bd071

Том МакРайт рассказал о своём подходе к работе с зависимостями — "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