Кэти Хемпениус на сайте web.dev опубликовала гид по решению проблем, возникающих из-за большого траффика — "Fix an overloaded server".

Если на сайт внезапно пришло большое количество пользователей, и он перестал осиливать нагрузку, то надо предпринять четыре шага:
1. Оценка — поиск причин отказов: CPU, IO, память, сеть.
2. Стабилизация — быстрые фиксы, которые позволят вернуть сайт к жизни: rate limiting, кэширование, отключение фич, которые особо сильно не влияют на бизнес-метрики, но которые потребляют ресурсы.
3. Улучшение — использование CDN и балансеров, добавление железа, использования сжатия ресурсов
4. Мониторинг — использование средств мониторинга показателей по перцентилям, чтобы средние значения не могли скрыть проблемы, которые возникают не у всех пользователей.

Статья полезная, рекомендую почитать.

#performance #backend

https://web.dev/overloaded-server/

В блоге WebKit вышла статья про новинки Safari 13.1, релиз которого запланирован на весну, — "New WebKit Features in Safari 13.1".

На iPadOS появится полноценная поддержка мыши и тачпада. Чтобы контент был доступен для всех пользователей вне зависимости от устройства ввода, он не должен зависеть от тач-событий. Вместо них рекомендуется использовать Pointer Events.

Было добавлено много новых API. С помощью Web Animations API станет доступно программное управление параметрами анимаций и переходов: остановка и повторное воспроизведение анимации, изменение направления, скорости, продолжительности и т.п. Будет доступен Async Clipboard API, который предоставляет доступ к системному буферу обмена, сохраняя отзывчивость страницы. API доступен только в безопасном контексте внутри обработчиков жестов пользователя, например, pointerup. Реализована поддержка ResizeObserver для более гибкого управления дизайном компонентов в зависимости от размеров контейнера, а не вьюпорта. В WebRTC добавлена поддержка работы через прокси-сервисы и Dual-Tone Multi-Frequency (DTMF) для поддержки большего количества аудио-сервисов.

Элементы управления форм будут поддерживать новый атрибут enterkeyhint, с помощью которого можно изменить текст кнопки enter виртуальной клавиатуры на done, go, next, previous, search и send.

В CSS появится поддержка Shadow Parts для стилизации web-компонентов по месту использования. Добавлен line-break: anywhere для мягких переносов внутри текста. Было добавлено новое медиа-выражение dynamic-range для адаптации контента под специфические возможности экрана, например, HDR.

В JavaScript движке появится поддержка оператора nullish coalescing ( ?? ) и нового метода String — String.prototype.replaceAll().

В инструментах разработчика панели Debugger и Resource объединены в единую панель Sources для более удобной отладки кода. Пояится новая вкладка Layers 3D-визаулизацией отрендеренных слоёв для упрощения поиска проблем производительности. На уровне инструментов разработчика можно адаптировать любой скрипт под свои нужды с помощью Local Overrides. Теперь также как и в Chrome Dev Tools любой скрипт может быть проигнорирован во время отладки с помощью Script Blackboxing.

Соединения с ресурсами по протоколам TLS 1.0 и TLS 1.1 будут помечаться как "Not Secure". Информация из document.referrers будет доступна только оригинальному домену. Любые данные web-сайтов (Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations) старше семи дней будут очищаться, если пользователь не посетит сайт в течении этого периода. Последний пункт — очень спорное решение, которое вызвало негодование среди разработчиков.

#safari #announcement

https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/

Лия Веру — участвует в разработке спецификации CSS — написала статью про новый формат кодирования цветов в CSS — "LCH colors in CSS: what, why, and how?".

Цвета в CSS определены в цветовом пространстве sRGB. У sRGB есть недостаток — с помощью него нельзя закодировать все цвета, которые могут быть отображены современными экранами (примерно одна треть от всех возможных цветов). Для решения этой проблемы в спецификацию CSS Color Module Level 4 было добавлено новое представление цветов — lch() (Lightness Chroma Hue).

LCH не только покрывает большее цветовое пространство, но и позволяет работать с цветом более интуитивно. В LCH любое изменение компонент цвета на одно и то же смещение будет давать одно и то же смещение в визуальном представлении цвета. Это свойство в цветовых пространствах называется "perceptual uniformity". В HSL perceptual uniformity не поддерживается, и изменение светлоты на 20% у двух цветов, отличающихся только тоном, будет давать в результате новые цвета с визуально отличающейся светлотой.

Поддержки LCH на данный момент нет ни в одном браузере, но уже идёт работа над его внедрением в Safari.

#css #colors

http://lea.verou.me/2020/04/lch-colors-in-css-what-why-and-how/

Стефан Баумгартнер написал пост про тип Symbol в JS и TypeScript — "Symbols in JavaScript and TypeScript".

Symbol используется для получения уникальных значений. С помощью символов можно разграничивать библиотечные и пользовательские данные в рамках одного объекта. Но это только одно их применение. В статье разбирается пример их использования для создания подобия enum в TypeScript, который кроме типобезопасности накладывает дополнительные ограничения в рантайме после компиляции в JavaScript:

const COLOR_RED: unique symbol = Symbol('RED')
const COLOR_GREEN: unique symbol = Symbol('GREEN')
const COLOR_BLUE: unique symbol = Symbol('BLUE')
const COLOR_BLACK: unique symbol = Symbol('BLACK')

const ColorEnum = {
  [COLOR_RED]: COLOR_RED,
  [COLOR_GREEN]: COLOR_GREEN,
  [COLOR_BLUE]: COLOR_BLUE,
}

function getHexValueWithSymbolKeys(color: keyof typeof ColorEnum) {
  switch(color) {
    case ColorEnum[COLOR_BLUE]: break; // good
    case COLOR_RED: break; // good
    case COLOR_BLACK: break; // bad
  }
}

Идея интересная, но в повседневном коде наврятли стоит использовать такой подход — обычный enum выглядит более эргономично.

#js #typenoscript #es2015

https://fettblog.eu/symbols-in-javanoscript-and-typenoscript/

Недавно в Firefox была обнаружена проблема с кешированием данных в Twitter. Любой пользователь с физическим доступом к компьютеру теоретически мог прочитать чужие личные сообщения. Мартин Томсон из команды разработки Firefox рассказал, почему это произошло, в статье "Twitter Direct Message Caching and Firefox".

Чтобы предотвратить кеширование контента в браузерах, сайт должен отправить в ответе http-заголовок Cache-Control: no-store. В любом другом случае в Firefox начинает работать механизм эвристического кеширования. Этот механизм используется для предсказания, какой контент может быть закеширован и на какое время. Контент без Cache-Control: no-store сохраняется в кэше на семь дней. Как вы наверное уже догадались Twitter не отправлял этот заголовок в ответе из-за чего в Firefox включался механизм кеширования. Вместо него Twitter отправлял заголовок Content-Disposition, который используется для добавления метаинформации (например, имени файла) к загружаемым файлам. В статье говорится, что в "other browser" (как я понимаю Chrome) наличие этого заголовка отключает кеширование, но это поведение не является частью стандарта.

Какие можно сделать выводы из этой истории? Нужно проверять работу сайта в разных браузерах (Chrome, Firefox, Safari) и не стоит полагаться на поведение браузера, которое не соответствует стандартам.

#firefox #cache #http

https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/

Ахмад Шадид написал статью про CSS-находки в новой версии Facebook — "CSS Findings From The New Facebook Design".

Из самого интересного. Для изменения цвета некоторых иконок используется хак с CSS-фильтрами ( filter: invert(59%) sepia(11%) saturate(200%) saturate(135%) hue-rotate(176deg) brightness(96%) contrast(94%); ). Так было сделано, чтобы поддержать смену цвета у legacy-иконок для тёмной темы. Тень заголовка сайта сделана не с помощью свойства box-shadow, а с помощью изображения. Рой Хагиги из Facebook объяснил, что box-shadow убивал производительность при прокрутке страницы, особенно это было заметно на странице с большим количеством видео — отдельные части страницы при прокрутке временно исчезали.

В общем, узнал много нового из статьи, рекомендую почитать.

#css #facebook

https://ishadeed.com/article/new-facebook-css/

Вчера вышла новая версия Chrome. Пит Лепаж рассказал про новинки браузера в статье "New in Chrome 81".

Было обновлено расписание релизов в связи с обстановкой в мире. Chrome 82 не будет. После версии 81 состоится релиз 83.

Был обновлён Web XR Device API. С помощью него можно будет определять поверхности реального мира и создавать приложения дополненной реальности для виртуального размещения мебели, картин и т.п.

В рамках Origin Trial доступен Badging API. Будет полезно, если вы разрабатываете PWA-приложение и хотите отобразить поверх иконки приложения количество непрочитанных сообщений. Также в Origin Trial стал доступен Web NFC для чтения и записи NFC-меток.

В JavaScript стало доступно новое INTL API DisplayNames. Благодаря ему можно получить название региона, валюты, языка, письменности по идентификатору региона, валюты и т.п.

В инструментах разработчика много изменений для работы с cookies: теперь можно поменять любое значение в cookies, заблокированные cookie подсвечиваются жёлтым цветом, добавлено отображение приоритета cookies (приоритет поддерживается только в Chrome), "Copy as Node.js fetch" в меню ресурса теперь копирует данные с cookies. В симулируемые устройства был добавлен Moto G4. Манифест панели Application отображает более корректные иконки приложения. Если content в CSS включает в себя экранированные символы, то при наведении на них курсором будет видно, что они собой представляют в реальности. Теперь ошибки парсинга source maps показывают больше информации о возникшей проблеме.

#announcement #chrome #release

https://developers.google.com/web/updates/2020/04/nic81

В конце марта прошла конференция PerfMatters, на которой выступили с докладами Йоав Вайс, Пол Айриш, Арон Тёрнер и другие. Посмотрел оттуда доклад "Turbocharging Walmart.com" Васанта Кришнамурти (лид фронтенд-направления Wallmart).

Wallmart.com каждый месяц посещают 100 миллионов пользователей. Для того чтобы обеспечить наилучший пользовательский опыт, команда разработки сфокусировалась на производительности сайта. Применение всех техник, про которые рассказывается в докладе (код сплиттинг, использование сжатия brotli, resource hints и т.п.), уменьшило TTI более чем на 50%.

Из самого интересного. Использование хинта preload продиктовано наиболее распространёнными пользовательскими сценариями работы с сайтом — на каждой странице подгружается код бандла следующей страницы, на которую с большей вероятностью перейдёт пользователь. Preload отключают, если у пользователя включён режим экономии траффика ( NetworkInformation.saveData — доступен только в CHrome). Заголовок и подвал сайта рендерятся в отдельном сервисе, благодаря чему единожды отрендеренные куски HTML переиспользуются на всех страницах.

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

#performance #talk

https://www.youtube.com/watch?v=vB8JUx9Dp08

Эдди Османи написал статью про актуальные способы профилировки React-приложений — "Profiling React.js Performance".

В статье рассказывается про React Profiler API, React Interaction Tracing API, User Timing API, про использование puppeteer и lighthouse для поиска проблем производительности.

С помощью React Profiler API можно получить подробную информацию о рендеринге компонентов. Для этого нужно обернуть интересующий компонент в <Profiler> и передать в пропсе onRender функцию, которая будет вызываться на каждое обновление компонента. Interaction Tracing API — это экспериментальное API, с помощью которого можно отследить, какое событие стало причиной медленного обновления, или, например, измерить сколько времени проходит с момента нажатия на кнопку и фактическим обновлением DOM.

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

#performance #react

https://addyosmani.com/blog/profiling-react-js/

Андрей Ситник в блоге Evil Martians опубликовал статью про грядующие изменения в PostCSS — "PostCSS 8.0 is coming".

В восьмой версии не ожидается ломающих изменений для большинства пользователей — все плагины, написанные для текущей седьмой версии, будут работать. Планируется работа над уменьшением размера node_modules — все плагины будут использовать общий пакет PostCSS. Будет добавлено новое API для написания плагинов, которое ускорит транспиляцию CSS-файлов; старое API остаётся доступно всем разработчикам плагинов без каких-либо нюансов. В PostCSS 8.0 будет удалена поддержка Node,JS 6 и 8. Также будет удалён шаг сборки с помощью Babel, исходники будут публиковаться в npm без транспиляции. Планируется доработка сайта документации.

https://evilmartians.com/chronicles/postcss-8-is-coming-here-is-what-it-brings

#announcement #library #css

Томас Штейнер в блоге web.dev написал статью про новое экспериментальное API — "WebSocketStream: integrating streams with the WebSocket API".

WebSocketStream в отличие от стандартного WebSocket API может ограничить поток входящих и исходящих сообщений в зависимости от текущей нагрузки (backpressure). Это особенно полезно для приложений, которые передают много траффика: видеоконференции, шаринг рабочего стала и т.п. В текущей версии WebSocket API реализовать backpressure для входящих сообщений невозможно, для исходящих сообщений — возможно, но только постоянно опрашивая WebSocket.bufferedAmount, что неэффективно и неэргономично.

WebSocketStream доступен только в Chrome. От команд Firefox и Safari пока не было сигналов о добавлении этой фичи.

#net #experimental

https://web.dev/websocketstream/

Не все проблемы производительности требуют глубокого понимания проблемы. Иногда их исправление может быть очень скучным, как удаление ненужного кода. Тим Кадлек написал небольшой пост по этому поводу — "Mundane Improvements, Big Impact".

Тим работал с клиентом, который использует Shopify (это такой аналог Битрикса, заточенный под магазины, популярный в Европе и Северной Америке). Одна из проблем заключалась в высоком TTFB (time to first byte) — сайт для некоторых пользователей начинал передавать данные спустя несколько секунд, но в синтетических тестах всё было хорошо. После небольшого исследования в html был найден огромный json-объект, генерация которого и приводила к задержке. Этот объект был нужен для старой системы аналитики, которая больше не использовалась, поэтому его можно было удалить. Удаление сериализованного объекта из html дало сокращение TTFB на 60%.

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

#musings #performance

https://timkadlec.com/remembers/2020-04-13-mundane-improvements-big-impact/

Итамар Бен Закен поделился опытом оптимизации Node.js-сервиса — "6 Lessons learned from optimizing the performance of a Node.js service".

Итамар разрабатывал сервис для A/B-тестирования. Такие сервисы должны работать очень стабильно, поэтому много внимания было уделено оптимизации. Вот некоторые мысли из статьи.

Нагрузочное тестирование — полезный инструмент. Оно даёт гарантии, что новые фичи не будут ломать производительность сервиса. Некоторые проблемы могут вскрываться только на больших промежутках времени, поэтому стоит увеличить время прогона тестов. Если каждый запрос должен быть обработан внешним сервисом, то при большом траффике это может создать проблемы. В статье разбирался кейс с Kafka — при её интеграции возникала большая задержка при отправке запросов. Чтобы решить эту проблему, была изменена логика обработки запросов. Их стали собирать в батчи и отправлять на обработку каждую секунду.

Довольно неплохая статья. Рекомендую почитать всем, кто разрабатывает сервисы на Node.js.

#performance #nodejs

https://engineering.klarna.com/6-lessons-learned-from-optimizing-the-performance-of-a-node-js-service-f163cac20473

В блоге Cloudflare была опубликована статья со сравнением производительности HTTP/2 и HTTP/3 — "Comparing HTTP/3 vs. HTTP/2 Performance".

Cloudflare объявил об экспериментальной поддержке HTTP/3 в сентябре 2019 (подробнее про HTTP/3 можно почитать тут https://news.1rj.ru/str/defront/268). За прошедшие полгода протокол был обновлён до 27-ой версии черновика протокола, а также были получены живые данные, которые помогли рабочей группе, занимающейся разработкой HTTP/3.

0-RTT — фича HTTP/3, которая позволяет сократить время при установке соединения. В сравнении с HTTP/2 метрика time to first byte (TTFB) для HTTP/3 при включённом RTT-0 улучшилась на 12%. С текущей реализацией алгоритма управления потоком (спецификация не накладывает на него ограничений) нельзя корректно сравнить время загрузки, но эксперименты показывают, что она как мининмум не хуже HTTP/2.

Экспериментальная поддержка HTTP/3 есть во всех основных браузерах: Chromium-based (Crhome, Edge, Opera), Firefox Nightly, Safari Technology Preview.

#http #performance

https://blog.cloudflare.com/http-3-vs-http-2/

Гари Бернхардт — автор проекта destroyallsoftware (и знаменитого доклада "Wat") — опубликовал серию статей про миграцию своего стартапа с JS и Ruby на TypeScript.

В первой статье "Porting a React Frontend to TypeScript" он пишет про миграцию фронтенд-кода. Добавление типов позволило статически проверять генерацию ссылок для роутера и кода, работающего с ответом из api.

Вторая статья "Porting to TypeScript Solved Our API Woes" рассказывает про миграцию Ruby-проекта на TypeScript. Один из главных плюсов перехода — статическая проверка api-хендлеров и упрощение масштабного рефакторинга. Немного рассказывается про кодогенерацию с помощью библиотеки schemats, которая по структуре базы данных генерирует d.ts-файлы сущностей предметной области.

В статье "Are Tests Necessary in TypeScript?" разбирается вопрос, нужен ли TS для проекта с большим покрытием тестами. Основная мысль — использование TS позволяет избавиться от целого класса тестов, которые необходимы в JS-коде. Тесты, в случае Гари, покрывают логику только очень важных подсистем: биллинг, управление подпиской.

Последняя статья "Problems With TypeScript in 2020" рассказывает про проблемы TypeScript. Есть баги с вотчингом файлов — могут возникать фантомные ошибки, когда из проекта удаляются файлы или добавляются новые. Редко бывают проблемы с внешними библиотеками, типы для которых поддерживаются сообществом. Но в целом, все известные минусы перекрываются преимуществами.

Рекомендую почитать статьи всем, кто задумывается о переходе на TypeScript.

#typenoscript #migration

Сегодня у канала @winterview день рождения. Поздравляю с этим достижением! По своему опыту знаю, что создание качественного материала иногда даётся очень непросто. Паша у себя в канале рассказывает про прохождение собеседований, soft skills и немного про психологию. Читаю посты с интересом. И да, это не реклама. Просто хочется немного поддержать дружественный канал.

Марк Ноттингэм — участвует в разработке http и других протоколов — написал статью про малоизвестный http-заголовок Prefer: Safe — "On RFC8674, the safe preference for HTTP".

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

Заголовок Prefer: Safe не получил широкого распространения из-за того, что он может потенциально использоваться для идентификации пользователей. А также из-за того, что понятие "Safe" каждый воспринимает по-своему. В статье рассказывается про случай с youtube, который сделал похожую настройку в своём приложении. После её добавления пользователи стали массово жаловаться на то, что они не видят нужный контент. Как оказалось, понятие "Safe" очень субъективно. То что было "Non-Safe" для youtube, было вполне "Safe" для пользователей. Тем не менее Марк считает RFC8674 шагом в правильном направлении, так как он обеспечивает фильтрацию контента на стороне пользователя без участия третьих сторон.

Cтатья интересная. В ней также немного рассказывается про процесс принятия новых фич на уровне IETF.

#http #musings

https://www.mnot.net/blog/2019/12/05/safe_hint

Ингвар Степанян из Google написал статью про ускорение сжатия png-изображений в Squoosh — "Bringing OxiPNG to Squoosh".

Squoosh.app, несмотря на то что работает в вебе, попадает в категорию лучших инструментов для сжатия изображений. Для работы с png в нём использовалась скомпилированная в WebAssembly C-библиотека OptiPNG. У неё есть продвинутая альтернатива — Rust-библиотека OxiPNG, основное преимущество которой поддержка многопоточности (планируют задействовать в будущих релизах Squoosh).

Первая попытка миграции на OxiPNG привела к увеличению размера сжимаемых png относительно OptiPNG. Проблема была в библиотеке miniz_oxide, которая реализует алгоритм сжатия без потерь deflate, использующийся в png. Проблемная библиотека в итоге была заменена на libdeflater. После миграции на OxiPNG скорость сжатия png в некоторых случаях ускорилась более чем в два раза, и на несколько процентов сократился объём генерируемых файлов.

Статья скорее всего будет интересна тем, кто работает с WebAssembly и кому интересно почитать про библиотеки для сжатия png.

#webassembly #tool #graphics

https://rreverser.com/bringing-oxipng-to-squoosh/

Барри Поллард — специалист в области web-производительности и автор книги “HTTP/2 in Action” — рассказал, почему совет про упаковку html-кода в первых 14kb не стоит воспринимать как жёсткое правило.

Дело в том, что цифра 14kb основана не на реальных данных, а на теоретических вычислениях. В первой транзакции передачи tcp-пактов можно отправить 10 пакетов. Каждый пакет весит 1500 байт, в каждом пакете 40 байт занимает служебная информация. На основе этих данных и получается 14kb (10 * (1500 - 40)). Барри на примере показывает, что в реальных условиях это не всегда так. При использовании HTTPS и HTTP/2 служебные данные могут занимать до 5 пакетов, то есть половину всего теоретического лимита. Но это не означает, что нужно пренебрегать размером отправляемых ресурсов. Всё также достаточно важно размещать в первых ~14kb отправляемого html ссылки на критические ресурсы, чтобы браузер начал их загрузку во время парсинга html.

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

#performance #http

https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

В блоге web.dev была опубликована статья про изолированные окружения — "Making your website "cross-origin isolated" using COOP and COEP".

В web-платформе есть потенциально небезопасные, но мощные API: SharedArrayBuffer (требуется для WebAssembly Threads), performance.measureMemory (будет доступно в Chrome 83) и JS Self-Profiling API (пока нет поддержки в браузерах). Чтобы понять насколько опасно может быть их использование, можно вспомнить 2018 год, когда SharedArrayBuffer использовался для реализации атаки Spectre. Как противодействие Spectre SharedArrayBuffer был по умолчанию отключён во всех браузерах.

Для получения возможности использовать эти API ребята из Google разработали концепцию изолированного окружения (cross-origin isolated environment). Чтобы его включить, нужно отправить с документом http-заголовки:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Изолированное окружение (cross-origin isolated environment) полностью запрещает доступ к странице сторонним скриптам через window.opener или iframe и отключает изменение свойства document.domain. Благодаря чему семейство атак по сторонним каналам (например, Spectre) перестают работать.

Включение COOP и COEP на больших сайтах может быть нетривиально, поэтому в статье есть инструкции, как найти и исправить возникшие проблемы. Поддержка изолированных окружений ожидается в Chrome 83.

#security #api

https://web.dev/coop-coep/

Сегодня вышел Node.js 14. На medium был опубликован пост с описанием основных изменений — "Node.js version 14 available now".

Node.js 14 переходит на текущую ветку поддержки "Current", вытесняя оттуда Node.js 13. По плану через 6 месяцев (октябрь 2020) 14-ая версия перейдёт в фазу LTS. Node.js 12 будет поддерживаться до апреля 2022 года, Node.js 10 — до апреля 2021 года.

В Node.js 14 стабилизирован Diagnostic Report. Это API позволяет получить много полезной информации для локализации утечек памяти, причин падений и проблем производительности. В канале было несколько постов про эту фичу, их можно почитать тут и тут.

В новой версии доступен экспериментальный Async Local Storage API (есть бэкпорт для Node.js 13.10). Благодаря ему в Node.js появляется готовый инструмент для сохранения данных на время жизни http-запросов и любых других асинхронных процессов.

Были сделаны мажорные исправления в Streams API для улучшения согласованности и устранения неоднозначности. Например, http.OutgoingMessage теперь подобен stream.Writable, а net.Socket ведёт себя точно также как stream.Duplex. Ещё одно заметное изменение — включение по умолчанию опции autoDestroy.

Появилась экспериментальная поддержка Web Assembly System Interface (WASI), цель которого упростить работу с нативными модулями в Node.js. Про WASI также был пост в канале ранее, его можно найти тут.

Движок V8 обновлён до v8.1. Новая версия приносит улучшения производительности и поддержку новых спецификаций: Optional Chaining, Nullish Coalescing, Intl.DisplayNames, Intl.DateTimeFormat ( calendar, numberingSystem ).

В Node.js 13 ECMAScript modules стали доступны без явной передачи флага --experimental-modules. В 14-ой версии сделан следующий значимый шаг — убрано предупреждение при использовании ESM ExperimentalWarning: The ESM module loader is experimental. Тем не менее формально ESM остаётся экспериментальной фичей, поэтому в будущем могут быть мажорные изменения.

#nodejs #release

https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e