Настя Котова // Frontend & Node.js

Я уже немного писала про Garbage Collection ранее в канале, но цикл про V8 будет неполный без отдельной статьи на эту тему, так что вот: Погружение в v8. Часть 4. Управление памятью и сборка мусора. В новой части разбираемся, как движок управляет памятью, оптимизирует сборку мусора и не только.

Вышла третья часть моего цикла про V8! На этот раз про то, как V8 разбирает код и что происходит ещё до первого его выполнения. Посмотрим на AST, preparser, сканер, скоупы и байткод. Погружение в v8. Часть 3. Парсинг, AST и анализ кода.

Продолжаем разбирать V8 — на этот раз по слоям. Если первая часть была больше про историю, то теперь спускаемся вглубь: как именно движок исполняет JavaScript, какие компиляторы внутри него живут и зачем их так много. Ignition, TurboFan, Sparkplug, Maglev — всё это может звучать пугающе, но на самом деле это слоистая архитектура V8, которую я постаралась разложить по полочкам. Погружение в V8. Часть 2. Из чего состоит движок.

Новый цикл статей уже на подходе!) Мостик между Node.js и браузерным JavaScript — это движок V8. Я попробую разобрать его по кусочкам и заглянуть внутрь: как работает, какие механизмы использует и почему он такой быстрый. Погружение в V8. Часть 1. История. Пока цикл ещё не завершён, можно повлиять на его содержание — пишите в комментариях, какие аспекты V8 особенно интересны, и я постараюсь включить их в следующие части 💫

Вы когда-нибудь задумывались, как работает npx? И что это вообще за инструмент такой? У меня npx появился в жизни внезапно — я сразу начала его использоваться, а вот что это за покемон и как он работает под капотом, изучить не успела. Знала только, что устанавливать ничего не надо — npx идёт в комплекте с Node.js и npm. Давайте попробуем немного разобраться сейчас. Как было раньше Раньше, чтобы запускать CLI-пакеты (например, create-react-app) из любого места, их нужно было ставить глобально:

npm i -g create-react-app

Это добавляло бинарники пакета в системный PATH, но тянуло за собой потенциальные проблемы — например, конфликт версий, если в разных проектах нужна своя версия CLI. Npx решает эту боль. Он может: - использовать локально установленный пакет, - или (если такого нет) скачать временно нужный и сразу запустить. Без глобальной установки и без добавления в PATH. Плюс, можно запускать конкретные версии одного и того же пакета под разные проекты, не ловя конфликты. Окей, а что тогда за команда у Vite такая?

npm create vite@latest my-vue-app -- --template vue

Смотрим информацию о команде:

npm create --help
Create a package.json file

Usage:
npm init <package-spec> (same as `npx create-<package-spec>`)
npm init <@scope> (same as `npx <@scope>/create`)

По факту, npm create — это синтаксический сахар над npx create-<name>, а под капотом — тот же npx. И важный момент напоследок Пакет, который хочется запускать через npx, должен иметь секцию bin в своём package.json. Пример из vite:

"bin": {
  "create-vite": "index.js",
  "cva": "index.js"
}

Это как раз то, что позволяет вызывать его как CLI-команду.

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

Хоть я последнее время и залипаю в Node.js, но трушным фронтендом тоже занимаюсь. Вот, например, на днях впервые использовала фичу container queries в CSS. Сценарий: у нас в интерфейсе есть блок, который пользователь может растягивать по ширине — прямо мышкой, за ползунок. А в этом блоке лежит таблица, и в ней хочется скрывать некоторые колонки, если блок слишком узкий. Обычно мы пишем media-выражения, завязываясь на ширину всего экрана, но тут нужна ширина конкретного компонента. Хвала богам CSS, мы живем в 2025 году, и в наше время есть такая фича, как container queries в CSS. Как это работает (если вы ещё не успели попробовать) 1. Определяем контейнер (родительский элемент):

.container {
  container-type: inline-size;/* Отслеживает ширину */
  container-name: my-container;/* Опционально: имя для обращения */
}
    

2. Пишем запрос (@container):

@container my-container (max-width: 600px) {
  .child-element {
    font-size: 14px;
  }
}
    

3. Вы восхитительны! Самое крутое, что у этой фичи хорошая браузерная поддержка. Значит, можно брать — и делать. Может, я и не открыла Америку, но как человек, который до сих пор пребывает в лёгком шоке от того, что IE11 умел в grid-ы, я каждый раз радуюсь, когда новые возможности CSS можно использовать на проде. Так что, может и вы порадуетесь сегодня вместе со мной:)

В своём докладе я рассказывала о том, как мы обновляли легаси-проект, вместо того чтобы переписывать его с нуля. Да, доклад назывался «Не переписывай — обнови», и я действительно продвигаю эту идею. Но и сама не раз попадала в ситуации, когда обновление невозможно. Чаще всего это касается старых проектов, написанных не на чём-то из «большой тройки» (React, Angular, Vue). В таких случаях зачастую просто не остаётся другого выхода, кроме как переписывать всё заново. Если проект построен на кастомном фреймворке или устаревшем решении, то он обречён на тяжёлую поддержку: современные библиотеки не интегрируются или делают это через боль, разработчики стараются обходить такие задачи стороной (типичная оценка «10 sp за простой баг» и привет вечный бэклог), а ещё продать такой проект при найме будет крайне сложно. Совсем другое дело, если проект написан на React, пусть даже на версиях 16 или 17. Здесь ключевое преимущество в том, что обновление не требует перестраивать архитектуру и саму идеологию кода: как были компоненты — так они и остаются. Да, классовые, но это те же самые компоненты, которые можно переписывать и переносить постепенно, параллельно занимаясь и продуктовыми задачами. На старте обновления важно сосредоточиться на тех вещах, которые напрямую влияют на то, как вы пишете код, и которые открывают путь к новым фичам. В нашем случае это было, например, внедрение нового стейт-менеджера. Как только эти базовые блоки обновлены, новые компоненты можно писать уже по современным подходам, а старые переписывать постепенно, по мере необходимости. А такие задачи, как переезд с Webpack на Vite или обновление сборки в целом, можно отложить на потом — они не меняют сам код и не блокируют разработку. Вопрос, который мне задали на докладе, оказался очень в точку: что делать, если проект стареет быстрее, чем вы его обновляете? Тут важно определить для себя критерии «легаси». Например, если у вас библиотека пятой версии, а недавно вышла шестая — это не значит, что проект мгновенно стал легаси. Но если версия 5 уже три года официально считается устаревшей и реально мешает работе (замедляет сборку или использует подходы, которые давно вышли из употребления, как это было с классами против функциональных компонентов), вот тогда пора действовать. И напоследок. Если у вас всё же тот самый первый вариант, когда переписывать приходится с нуля, продумайте стратегию постепенного перехода. На одном из проектов мы буквально переписывали его «по страницам». Да, и это проходило не без проблем, но так задачу можно было декомпозировать и оценивать. Параллельно брали продуктовые истории — иногда в новые страницы, иногда даже в старые (компромиссы неизбежны). Никто не согласится на план «нам нужен год, никакие фичи не делаем, и не факт, что даже уложимся». Любое обновление должно быть разбито на понятные этапы. Так и прогресс виден: не как мифические «0 и вдруг 100%», а постепенно, по шагам. И для команды, и для менеджмента это куда легче и понятнее.

Минутка саморекламы: в этом году я выступаю на FrontendConf! Буду рассказывать про нехайповую, но, на мой взгляд, интересную тему — нативные модули в Node.js. Даже официальный анонс уже вышел, так что больше скрывать не буду: https://t.me/FrontendConfChannel/1197

Вы когда-нибудь пользовались corepack? Corepack — экспериментальный инструмент в экосистеме Node.js для управления версиями менеджеров пакетов (npm, yarn, pnpm) в проектах. По сути, он позволяет жёстко контролировать, какой именно пакетный менеджер и в какой версии используется. Сейчас corepack поставляется вместе с Node.js, но начиная с версии 25 перестанет быть его частью. Я всего один раз видела использование corepack на проекте и читала о нём довольно противоречивые отзывы. С одной стороны, кому-то он помогает гарантировать нужную версию пакетного менеджера — особенно при сборке Docker-образов в CI. С другой — кажется избыточным (шутки про “пакетный менеджер для пакетных менеджеров”). В Dockerfile при использовании corepack это может выглядеть так:

FROM node:18-alpine

# Включаем corepack
RUN corepack enable

WORKDIR /app

# Копируем package.json (с указанием packageManager)
COPY package.json package-lock.json ./

# Corepack автоматически использует нужную версию pnpm
RUN corepack pnpm install --frozen-lockfile

Да, это защищает от необходимости вручную указывать версию pnpm, но при этом установка нужной версии менеджера всё равно должна происходить. К тому же, после исключения corepack из Node.js, он больше не будет ставиться по умолчанию — его придётся устанавливать отдельно, с указанием версии. В общем, лично я пока так и не прониклась этим инструментом — его преимущества не кажутся мне весомыми. Если у вас был другой опыт — пишите в комментариях, может, я что-то упускаю.

Уже завтра я выступаю в Минске 💫 Регистрируйтесь, доклад можно будет также посмотреть онлайн а трансляции.

Завершающая часть цикла про libuv здесь! Рассмотрим некоторые другие интересные функции libuv, и поговорим про их использование внутри Node.js. Погружение в libuv. Часть 4. Другие функции. #startpoint_dev_nodejs

Третья часть про libuv. Смотрим, как реализован Event Loop внутри libuv, и как с этим жить простому разработчику. Погружение в libuv. Часть 3. Опять Event Loop. #startpoint_dev_nodejs

Продолжаю покорять сцены конференций — на этот раз уже оффлайн и в Минске! 🎤 Выступаю на Яндекс.Субботнике с докладом о том, как мы провели большое техническое обновление без остановки разработки 💫 Будет и трансляция — так что можно смотреть из любой точки мира. Чтобы прийти лично или подключиться онлайн, достаточно зарегистрироваться: 🔗 https://events.yandex.ru/events/ya-subbotnik-2025-07-26

Продолжение цикла про libuv. На этот раз полезем прямо в кишки операционных систем ⚰️ Как бы мне ни хотелось обойти эту тему стороной, но реализация неблокирующего ввода-вывода — это не просто внутренняя деталь, а один из главных столпов и libuv, и всего Node.js. Обещаю, дальше будет легче!) Погружение в libuv. Часть 2. Неблокирующий ввод-вывод. #startpoint_dev_nodejs

Вы не ждали, а мы припёрлись тут опять с циклом статей. Как же мне понравилось разбираться в каком-то вопросе путём ресёрча и написания статьи на эту тему. Так я, после цикла про Event Loop, когда меня в очередной раз занесло в исходники Node.js, решила чуть лучше познакомиться с libuv — той самой культовой библиотекой, на которой, кажется, построен весь Node.js. На этот раз, по моим планам, он должен получиться короче, буквально на 3 (может 4) статьи. Как принято говорить на ютубе, заваривайте себе чаёк или кофеёк, и присоединяйтесь, будем постигать libuv вместе 💫 Погружение в libuv. Часть 1. Зачем он нужен? #startpoint_dev_nodejs

Из чего состоит память в Node.js? Любой процесс в Node.js использует несколько разделов памяти: - Стек (stack) — область для хранения вызовов функций и локальных переменных, управляется ОС. - Куча (heap) — основная память для JS-объектов, управляется движком V8 и сборщиком мусора (GC). - Нативная память — сюда входят буферы (Buffer в Node.js), C++-addons, другие служебные сущности (для libuv, Event Loop и т.д.). Все эти разделы вместе образуют RSS (Resident Set Size) — общий объём памяти, выделенный процессу ОС. Чтобы посмотреть, сколько памяти сейчас используется, можно вызвать process.memoryUsage(). Этот метод возвращает объект с такими полями: - rss — вся память процесса, включая всё нативное. - heapTotal — объём JS-кучи, зарезервированный V8. - heapUsed — реально используемая память в куче. - external — нативная память. - arrayBuffers — конкретно память ArrayBuffer и Buffer (часть external). #startpoint_dev_nodejs