И еще про оптимизации в V8
(статья с блога v8, она актуальна по состоянию на 2026)

👉 https://v8.dev/blog/pointer-compression

- Большая часть памяти V8 хранит указатели и небольшие значения (SMI)
- SMI означает Small Integer, то есть небольшое целое число
- SMI хранится прямо в ячейке значения без создания отдельного объекта в куче
- Сжатый указатель хранит небольшое смещение адреса вместо полного 64-битного адреса
- Один изолят V8 должен хранить свою кучу в области памяти размером до 4 ГБ
- Сжатые указатели и SMI занимают 32 бита в памяти
- V8 разворачивает указатели при чтении и сжимает их при сохранении
- V8 хранит базовый адрес кучи в регистре CPU для быстрого разворачивания указателей
- Сжатие указателей уменьшает диапазон целых чисел SMI и ограничивает прямое значения double
- Это может уменьшить размер кучи V8 до 43%, а использование памяти процессом рендеринга браузера до 20%

Трехконтурная разработка: вместо того, чтобы генерировать с помощью AI миллионы строк кода в одном репозитории можно разделить это на 2 или три цикла.

Первый контур: технологический стек

Здесь сосредоточены основные инженерные усилия: runtime, протоколы, хранение данных, безопасность, наблюдаемость производительность, управление памятью и конкурентностью, инфраструктура, стабильные контракты и точки расширения. Этот код пишется редко, долго и дорого. Его создают лучшие инженеры вместе с AI, тщательно тестируют, профилируют и переиспользуют во множестве продуктов. Первый контур уменьшает кодовую базу второго на несколько порядков.

Второй контур: параметризованные модули

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

Третий контур: продукт

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

Основная идея:
- Каждый следующий контур сужает пространство решений
- AI особенно эффективен, когда работает внутри заранее подготовленной системы ограничений
- Чем сильнее первый и второй контуры, тем меньше кода требуется третьему, тем меньше контекста нужно AI, тем проще ревью, тестирование, сопровождение и миграции.

Эти и другие вопросы обсуждаем каждый четверг на созвоне сообщества https://www.patreon.com/c/tshemsedinov

Object.freeze / seal / preventExtensions: сколько это стоит в V8

Бенчмарк на create / read / write для обычного объекта {} и трех режимов защиты: freeze, preventExtensions, seal.

- create: защита дороже обычного объекта ~в x4: {} 5.7 ns, а для freeze/seal ~25 ns
- read: разницы почти нет, все ~1.4–1.6 ns
- write: preventExtensions и seal пишут в существующие поля так же быстро, как {}, а freeze в кидает исключение ~2245 ns (долго)

Вывод: читать frozen можно спокойно, дорого создавать (это обычно редко), а писать в freeze через try/catch не нужно, но в коде freeze может быть, если есть тесты, подтверждающие, что не пишем в поля

https://github.com/HowProgrammingWorks/Object

Что я понял по итогам работы над структурами данных для стандартной библиотеки Metarhia

Это же классическая тема, но ее мало кто хорошо осваивает в наше время, тем более в мире JS/Web разработки и во времена, когда все пишет AI. И даже если учили и знают, как делать хотябы простейший список, то нет привычки его использовати и знания остаются аккадемической теорией, невосстребованными вообще, а в коде массивы и объекты, ну максимум Set/Map. Почему же так случается?

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

Я за последний месяц собрал свои наработки за последние 15 лет и сделал и продакшен-версии кода и учебные примеры, записал много лекций и стримов по структурам данных. Буду делать примеры и скилы, а пока вот продакшен-реди реализация самых нужных структур тут https://github.com/metarhia/metautil

Passkey (вход без пароля)

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

При входе устройство подписывает запрос - фишинг и утечка пароля остаются в прошлом.

Минимальный пример на чистом Node.js и WebAuthn API: регистрация, вход, сессия.
https://github.com/HowProgrammingWorks/Passkey

А тут альтернативный вариант входа без пароля:

- Хранение ключей в OPFS (в браузере)
- Для генерации Web Crypto (ECDSA P-256)
- Без использования Web Authn, Passkey

https://github.com/HowProgrammingWorks/ChallengeSignIn

🧑‍💻 AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда

Структуры данных в JavaScript обычно объясняют через их внутреннее устройство, API и оценку сложности Big O. А мы пойдем от реальных инженерных проблем: написание бизнес-логики, кода на JavaScript и TypeScript для backend и frontend, типовые проблемы в разработке: коррапт глобальных данных, гонку состояния, очереди, кеширование, история изменений, управление памятью и ресурсами.

Мы разберем, почему каждая структура решает определенную проблему, и уже как следствие, то что она что-то запрещает и чем за это приходится платить, но и какие плюсы мы получаем. От обычных Array, Object, Map и Set до Linked List, Persistent List, Heap, Circular buffer, Bloom filter, Stack, Queue, Append-only, Immutable lists and Records. Отдельно классифицируем структуры для доменного, продуктового, платформенного и системного кода.

https://www.youtube.com/live/qNAjrZ07un0