Development

А вы знали что в JS есть метки, которые, по-сути, позволяют сделать GOTO ? Вот многие не знают, а статья объясняет как это работает и для чего может быть полезно. На мой скромный взгляд лучше конечно избегать таких техник (ну хотя бы потому что почти никто в JS сообществе о них не знает), но лучше знать чем не знать.

В статье обсуждается как раз одно из популярных применений ручного управления GOTO. Бывало ли у вас такое, что у вас цикл в цикле (ну вот такой алгоритм, не бейте палками) и вам в случае нахождения ответа во внутреннем цикле, надо завершить оба цикла. Что делать в этом случае? Конечно же выносить оба цикла в функцию и делать return, но если вы хотите козырнуть перед коллегами черными практиками, то можете воспользоваться метками :)

Вот минимальный пример, показывающий как это работает

Вышел Bun 1.0. С момента релиза 0.1.1 прошло чуть больше года. Bun достаточно уверенно прошел за год от состояния "опять хайпожоры придумали новый рантайм для JS", до "это интересное, удобное и производительное решение для использования в пет-проектах и библиотеках".

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

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)

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

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

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

Мысль в статье растекается достаточно широко, поэтому я отмечу основные поинты рассуждений

Мы можем определить "уверенность в поставке" как уверенность здравомыслящего разработчика когда он узнает, что его код скоро будет на проде. У SpaceX нужно тестировать ПО, а github может спокойно раскатить что угодно, в худшем случае напишут "мы полежим 10 минут и восстановимся" и они находятся на разных концах шкалы уверенности в поставке

Если взять 2 оси - уверенность в поставке и критичность, то мы получим 4 квадрата (критично + уверены, некритично + неуверены, критично + неуверены, некритично + уверены)

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

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

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

Хороший гайд про создание оптимизированного докер-образа для 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

Еще одна статья от Мартина Фаулера. На этот раз краткое описание модели Team Topologies. Эта модель описывает команды по разработке и делит их на 4 типа: продуктовые команды (stream-aligned team), платформенные команды (platform team), Enabling Team, команды сложной подсистемы (complicated-subsystem team)

Продуктовые команды - это маленькие автономные и самодостаточные команды, разрабатывающие какой-либо сервис или функционал. Эти команды организованы вокруг сервиса, а не какой-то роли (например: команда тестирования - это как раз организования вокруг компетенции, а не сервиса).

Продуктовые команды должны быть сфокусированы на разработке лучшего сервиса. Чтобы снизить свою когнитивную нагрузку, они интегрируются с различными платформами. Как раз за предоставление удобной платформы для продуктовых команд отвечают платформенные команды. В маленьких организациях платформенная команда может быть одна и отвечать за всё сразу. В больших оргназиациях их может быть много. Их цель: создавать удобные для интеграции платформы. Они могут начинать свое существование в режиме совместной работы с продуктовыми командами, но должны стремиться к концепции X as a Service.

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

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

Team Topologies это одновременно и хорошая и плохая модель. Её можно назвать плохой потому что, как и любая модель, она недостаточно хорошо отражает то, что происходит в реальном мире. Однако эта модель также может сподвигнуть вас улучшить что-то в своей организации, т.к. она неплохо описывает что есть различная работа, для различной работы есть различные паттерны и типы коммуникаций.