Node.js, начиная с 20.6.0, поддерживает env файлы. Пример запуска node --env-file .env --env-file .env.development. В целом, мы давно уже привыкли считывать env файлы с помощью библиотек, но у нативного способа есть одно преимущество - т.к. нативно Node.js считывает енвы перед запуском, то есть возможность описать NODE_OPTIONS. Раньше такой возможности не было (т.к. устанавливать опции надо до запуска ноды, а считывать через либы можно только после запуска ноды) и нужно было указывать разные важные для ноды вещи отдельно.

Для тех кто не знает что такое env-файлы. Это файлы, описывающие переменные окружения, которые будут использоваться для запуска приложения. Часто часть конфигов приложения (урлы до API, уровень логирования, ключи) выносят в переменные окружения, которые сохраняют в отдельном env-файле и из которого их в последствии устанавливают для приложения

Рим пал, центурион! Rome - набор инструментов, который обещал изменить веб-разработку, но разработка которого остановилась. Но т.к. Rome - это опенсорс, то часть разработчиков форкнулась с названием Biome и они планируют продолжать работать над инструментарием.

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

В общем, смотрим что будет с Biome, но я надежд не питаю.

В продолжении недавних статей про взлет и падение веб-компонентов, вышла статья про проблемы Shadow DOM

В целом, статья рассказывает, что применение Shadow DOM для инкапсуляции привносит в проект лишь проблемы. В будущем ситуация будет лучше, но пока так. Поэтому Enhance (я так понял это фреймворк) не использует Shadow DOM при описании компонентов

Проблемы Shadow DOM:

1. Shadow DOM требует загрузки и исполнения JS, что по перформансу намного хуже чем простой HTML
2. Пока не завезли декларативный Shadow DOM, нет возможности делать серверный рендер
3. Пока не будет вызван customElements.define(), к компоненту не будут применены стили (FOUCE - Flash of Unstyled Custom Element)
4. Кнопки в Shadow DOM в формах работают иначе, чем кнопки вне Shadow DOM в формах.
5. Shadow DOM усложняет реализацию доступности

Сайт про вьюпорты. Основная мысль которого - что завязываться на определенный размер окна браузера - это равносильно созданию плохого UX. Т.к. пользователи имеют всякие разные вьюпорты и их комбинации намного шире, чем вы можете себе представить (только в ios есть несколько видов отображения браузеров - в safari, webview, in-app browser, 3d touch preview)

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

Хороший гайд про создание оптимизированного докер-образа для nodejs приложения. Докер образа построены на слоях - т.е. каждая команда в нем создает отдельный слой, который затем может кешироваться. При скачивании образа, где оптимизации не были применены, мы можем скачать много "лишних" слоев

В этом гайде шаг за шагом показано, как использовать особенности работы Docker себе во благо. Автор добивается ускорения сборки новой версии образа в 43% без кеша и 73% с кешом, а также уменьшения размера образа в 5 раз.

Примененные оптимизации:

1. Взять оптимизированный base для образа. Автор берет nodejs-slim, т.к. alpine хоть и меньше, несет с собой musl вместо glibc, из-за чего могут наблюдаться ошибки в работе кода
2. Использовать dockerignore
3. Использовать multi-stage сборку. Автор использует 3 стейджа.
4. Не устанавливать или удалять dev и некоторые другие "лишние" зависимости
5. Вынести установку пакетов из package.json в отдельные шаги. Т.е. вместо добавления всех исходников и установки пакетов, в образ сначала добавляются только package.json. Это позволяет улучшить кеширование (т.к. исходный код меняется часто, а package.json - нет)

Лично для меня новыми были 2 техники: установка пакетов с копированием только package.json (не совсем новое, но давненько про это не читал и не использовал) и запуск кастомного скрипта чтобы зафорсить кеширование определенных слоев (автор удаляет лишние зависимости из package.json, но это также можно использовать и для удаления или изменения полей, например version)

Статья рассматривает как React Suspense в React 18 влияет на приложение в трех разных архитектурах: клиентский рендер, серверный рендер и серверные компоненты.

При клиентском рендере есть 2 ключевых юзкейса для Suspense: загрузка больших компонентов и загрузка данных

Если для работы страницы нужен большой кусок кода (компонент + его логика), то имеет смысл выделить это в отдельный чанк и ждать его загрузки. Один из простых способов это сделать - это скомбинировать Suspense и React.lazy

Про загрузку данных не буду особо пояснять, это кажется самый базовый кейс для Suspense

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

При серверных компонентах Suspense позволяет отдавать готовый HTML сразу, а то что ожидается в Suspense догружать позже по готовности контента. Этакий стриминг контента на новых рельсах.

Статья объясняет проблему тротлинга рендера при вложенных Suspense. Не уверен что это корректно называть тротлингом, но сама проблема интересна.

Представьте, что у вас есть вложенные Suspense. React работает так, что если первый Suspense ушел в ожидание раньше, чем рендер дошел до вложенного Suspense, то как следствие когда promise, подвесивший первый Suspense выйдет из ожидания, рендер дойдет до второго Suspense и мы бы ожидали увидеть контент первого Suspense и fallback у второго. Но на практике наблюдается некоторое время, когда мы видим состояние fallback первого Suspense. Так происходит потому что React умный и не комитит изменения Virtual DOM сразу в DOM, а ждет некоторое время. Из-за чего появляется задержка, когда мы бы могли уже показать пользователю контент, но этого не происходит.

В принципе, ничего криминального React не делает, но факт интересный

Статья от 2ГИС про то, как разные агрегации по миллионам объектам на карте. 2ГИС часто радует своими статьями с интересными высоконагруженными кейсами, и эта статья - не исключение, хотя коротковата

В статье рассказывается, как можно обрабатывать огромные массивы данных в браузере. Если коротко, то решение 2ГИС в использовании следующих инструментов: WebWorkers, передача данных в бинарном виде, обработка на GPU

Статья, защищающая веб-компоненты, написанная ответ на другую статью про то, что веб-компоненты непопулярны

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

Первый хороший кейс, это компоненты, которые имеют смысл только в браузере (виджет выбора дат в календаре или выбор эможи)

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

Третий хороший кейс - это крупные компании и дизайн системы. Автор говорит, что по некоторым замерам, веб-компоненты в интернете встречаются намного чаще, чем React. Это готовые дизайн-системы на веб-компоненты и крупные компании типа Oracle, IBM, Adobe и другие . Они используют web-component'ы потому что они работают почти везде и их легко подключать: никаких бандлеров и транспайлеров, просто вставь html тэг и скрипт и все заработает

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

Githu-репозиторий, который объясняет, что современный JS достаточно богат методами и синтаксисом, чтобы не использовать lodash вообще. Для каждого lodash метода приводятся 1 или несколько сниппетов кода на нативном JS, который выполняет аналогичную задачу и минимальные версии браузеров с поддержкой этого кода. Также, кроме понятных объяснений, предоставляется eslint плагин, который, наверное, делает автозамену вызовов lodash на нативный код.

В целом, ничего нового, но хорошо визуализировано и автоматизировано eslint'ом. Некоторые сниппеты кода на нативном JS вызывают улыбку. Например, аналоги _.get и _.chunk. Очень интересно было бы посмотреть потребления памяти и перформанс некоторых аналогов

Статья от команды Dropbox о том, как они сменили бандлер и уменьшили размер JS статики на треть.

Dropbox - крупная компания со своими сложными вызовами и поэтому, в 2014 году они сделали свой бандлер и свою технологию Dropbox Web Server (DWS). DWS позволяет делать модульный веб - страница состоит из независимых страничных блоков (pagelet), которые разрабатываются и обрабатываются независимо друг от друга.

Кастомный бандлер сильно отстал от лидеров рынка и поэтому было принято решение переезжать на современные решения. Самые крупные проблемы предыдущей архитектуры:

1. Дублирующийся код. Т.к. pagelet-ы независимы друг от друга, то если у них есть общий код, то они его встраивают в себя, вместо того чтобы переиспользовать
2. Отсутствие автоматического код-сплиттинга. Бандлер поддерживал его, но только через ручной конфиг на 6000 строк
3. Отсутствие три-шейкинга

Все эти проблемы давно решены текущими сборщиками, но не были решены в самописном решении. Dropbox переехал на использование rollup, но при этом миграция на него была плавная: сначала только dev сборка, затем только для сотрудников, затем раскатка на пользователей.

Во время плавной миграции были следующие трудности:

1. Иногда rollup падал из-за высокого потребления памяти в CI
2. Сложно поддерживать одновременно 2 бандлера
3. Появились баги из-за слишком агрессивного три-шейкинга у Rollup
4. Rollup включал strict mode для кода, что ломало некоторые зависимости

Как результат:

1. Удалось уменьшить JS статику на 33%
2. Количество JS файлов уменьшилось на 15%
3. Улучшился TTVC (time to visual complete). Я так понял это одна из основных метрик, за которыми следит dropbox

Перевод статьи о достаточно интересном баге. Баги встречаются практически везде, но чаще всего в коде приложения. Чуть реже в тулинге - такие баги можно искать, но бывает просто. Но одни из самых сложных багов - связанные с железом или чем-то близким к нему (драйвера например).

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

Подборка статей про автоматическое тестирование от консультанта в этой сфере. Подборка содержит 10 статей, обязательных к прочтению (по мнению автора) + 10 ссылок на полезные материалы

Список статей весьма хороший. Часть из них я уже читал (и вероятно они даже есть где-то в этом канале), часть, видимо, прочту в скором времени

Рекомендую к ознакомлению

Статья от мейнтенера популярных npm-пакетов (redux) про боль переезд на ES-модули. Казалось бы, модули появились еще в 2015 году и сейчас переезжать на них должно быть достаточно легко. Однако, на деле это достаточно нетривиальная задача.

В статье автор описывает кучу проблем, с которыми он боролся во время переезда с commonJS на ESM. Чтобы перевести пакеты на ESM, необходимо иметь очень хорошие знания о том, как ведет себя различный тулинг. Поэтому автор часто консультировался с мейнтейнерами других пакетов и разработчиками TS. Кое-где даже пришлось заменить тулинг, например, переехать с jest на vitest.

Очень хорошая статья с кучей ссылок и проблем. Рекомендую к прочтению, если у вас есть свои open source пакеты или вы разрабатываете внутренний инструментарий в компании и поставляете его через npm-пакеты

В devops культуре в случае возникновения серьезного инцидента принято описывать post-mortem - документ, описывающий причины возникновения инцидента, хронологию и действия, которые необходимо предпринять чтобы не допустить повторения инцидента в будущем

Обычно в этих документах ищется корневая причина - root cause. Таким образом предполагается, что есть какая-то одна, главная причина, полечив которую можно исправить множество проблем. В аналогии с земледелием (а корневая причина это именно оно и есть) существует небольшая несостыковка - у всех растений нет единого корня, корни - это почти всегда достаточно развесистая система.

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

Чтобы построить такое дерево достаточно использовать обычные практики для обсуждения post-mortem'ов:

1. Задавать вопросы 5W 1.1. What heppened (Что случилось)? 1.2. Where did it happen (Где случилось)? 1.3. Who was impacted by incident (На кого повлияло)? 1.4. Where did problem and resolution events occur (Когда случилось)? 1.5. Why did the incident occur (Почему это случилось)?
2. Для каждой найденной причины и эффекта спрашивать Why (почему), пока мы не достигнем причины, на которую повлиять не можем или на которую влиять слишком дорого.
3. Построить дерево причин и эффектов, проанализировать его и придумать действия, выполнение которых покроет как можно большее количество ветвей дерева

Статья про опыт переезда приложения на 50к строчек на React Server Components.

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

Для чего подходят RSC:

1. Позволяют четко определить, где код будет запускаться. Что позволяет, например, оптимизировать загрузку статики
2. Позволяют загружать данные прямо в компоненте, что в целом упрощает флоу данных в коде

Какие проблемы есть у RSC:

1. CSS-in-JS не работает в RSC
2. React Context работает только в клиентских компонентах. Это достаточно жесткое ограничение, мешающее мигрировать существующий код или использовать внешние решения (например, вы используете либку, которая как API предоставляет контекст - значит вы не сможете воспользоваться ей в RSC)
3. Сложность (Complexity). React и так не простой, а с RSC разработчик теперь должен будет всегда помнить, что есть 2 вида компонентов и они работают по-разному и к ним нужны разные подходы

Также автор описывает алгоритм для миграции на RSC. Миграция идет сверху-вниз, т.е. от App до конечных компонентов. Наша цель - ставить директиву use server при проходе сверху вниз по дереву компонентов, определяя, что мы можем унести на сервер, а что не можем. Также автор описывает паттерны комбинации двух видов компонентов.

Рекомендую к прочтению React разработчикам

История про оптимизацию перформанса генератора снапшота памяти в V8.

Инженеры bloomberg пытались поймать утечку памяти в своем nodejs приложении, но снапшот памяти на 500МБ снимался полчаса - непозволительно долго. Инженеры запрофилировали работу генератора снапшота и нашли 2 проблемы, решив которые они смогли ускорить генерацию снапшота на 100МБ памяти с 10 минут до 6 секунд (ускорение в 100 раз)

Первая найденная проблема - это алгоритм хеширования строк. V8 сохраняет все строки в отдельной оптимизированной хешмапе. Для чисел, представленных как строки, используется отдельный алгоритм для вычисления ключа для хранения в хешмапе. Этот алгоритм приводил к тому, что часто возникали колизии хешей, из-за чего операции с хешмапой замедлялись. Автор поправил алгоритм, добавив небольшой побитовый сдвиг.

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

Статья про ускорение сайта в 20 раз с применением серверных компонентов React.

Начальная позиция: сайт с документацией на angular.js, у которого LCP - 47 секунд. Конечная позиция: сайт с React Server components, у которого LCP 0.7 секунд. В принципе, конечно, ничего удивительного - 47 секунд LCP это значит что что-то было сделано феноменально плохо и перевод на серверный рендеринг естественно может ускорить сайт в любое количество раз. Однако статья все равно интересная т.к. рассказано о проблемах, с которыми столкнулась команда разработки

Из интересного:

1. Вместо бандлинга JSON в статику, отдают JSON через API
2. Сделали фикс бага в Next.js

Статья про комбинирование React Query и React Context. Сам по себе React Query очень удобен - он позволяет одновременно сделать компонент самодостаточным, но при этом абстрагировать логику запроса и кеширования данных, а также позволяет переиспользовать один кеш для нескольких компонентов. Но в случае с несколькими компонентами возникает проблема неявной зависимости - они могут использовать данные, предполагая, что другой компонент их уже запросил. Для решения этой проблемы автор предлагает использовать React Context

React Context выступает провайдером данных, которые получаются с помощью React Query, это позволяет явно разделить загрузку и получение данных, а также позволяет избежать излишних проверок Typescript.

В статье также разбираются альтернативные паттерны для решения подобной проблемы, например Suspense

Статья на хабре про новый синтаксис using, который призван упростить работу с объектами, которые требуют исполнения кода при прекращении работы с ними (например, соединения к БД).

В статье достаточно просто и наглядно объясняется зачем это нужно, как это использовать и какие подводные камни могут быть.

В целом новый синтаксис призван превратить это:

в это

Кажется, что это не такое уж и важное дело, но в реальности код может быть намного сложнее, нам может потребоваться несколько ресурсов, а люди могут забыть вызвать close.

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

Чтобы использовать эту фичу, resource должен реализовать у себя поле Symbol.dispose или Symbol.asyncDispose (в этом случае нужно использовать async using), в котором как раз будет реализовано освобождение ресурса

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

Чем платформенные команды отличаются от продуктовых? Основное различие в определении пользователя. Для продуктовых команд пользователи - это внешние пользователи продукта. Для платформенных команд пользователи - это другие команды компании

Есть 3 стадии развития платформы:

• Миграция на платформу
• Использование платформы
• Эволюция платформы

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

• Завести задачу в продуктовую команду
• Внедрить инженера платформенной команды в продуктовую (чтобы он сделал изменения). Это называется Tour of Duty
• Сделать изменения самим. Тут есть 2 варианта - если продуктовая команда доверяет платформенной, то это паттерн Trusted Outsider и платформенная команда просто вносит изменения. Либо же продуктовая команда не доверяет внешним инженерам в достаточной мере и будет проверять, что они делают, тогда это Internal Open Source

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

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

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

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