⬆️ Профилирование бандла: что скрыто внутри .map файлов

Когда размер вашего фронтенд-бандла начинает расти, вы, вероятно, используете такие инструменты, как Webpack Bundle Analyzer, чтобы увидеть, что именно увеличивает размер. Но на самом деле эти инструменты работают с .map файлами и тут скрывается гораздо больше информации, чем кажется на первый взгляд. Давайте разберемся, что лежит внутри этих файлов и как их использовать для глубокого профилирования.

✅ Что такое .map файлы?

Файлы .map — это JSON-структуры, которые содержат полную информацию о вашем коде. В них хранятся ссылки на оригинальные файлы, сам исходный код, соответствие между минифицированными и оригинальными строками кода, а также список символов и имён.

Это не просто файлы для дебага, это своего рода словарь вашего кода, который позволяет анализировать и профилировать его работу.

✅ Почему .map файлы полезны для профилирования?

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

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

✅ Что можно увидеть в .map файле?

С помощью .map файлов можно выявить различные проблемы. Например, они помогут понять, если вы случайно импортировали весь пакет lodash вместо конкретной функции или подключили слишком тяжёлый UI-кит, хотя использовали только одну кнопку. Также вы сможете найти дублирование модулей, если разные версии одной и той же библиотеки были добавлены в ваш проект.

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

✅ Как читать .map файлы?

Для анализа .map файлов можно использовать специальные инструменты, такие как maps-codec, source-map-explorer или даже встроенные инструменты в браузере через DevTools. Эти инструменты помогут вам понять, что именно добавляет вес вашему бандлу и как это влияет на производительность.

Если вы хотите пройти путь профилирования вручную, можно использовать source-map-explorer, который визуализирует содержимое .map файла и помогает быстро найти проблемные места.

✅ Когда вы работаете с .map файлами, стоит следовать нескольким простым рекомендациям

• Во-первых, всегда анализируйте source map на продакшн-сборке, так как staging-сборки могут иметь разные флаги, влияющие на результат.
• Во-вторых, используйте опцию hidden-source-map, чтобы скрыть карты от публичного доступа, но использовать их в CI.
• Также не забывайте отслеживать динамические импорты, ведь .map файл может показать, что именно попадало в ваши чанки.
• И, конечно, сравнивайте .map файлы между сборками, чтобы понять, что именно увеличивает размер бандла.

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

🚪 Frontender's notes

🤣 Гениальный план, как избавиться от бесящих коллег

💥 xCode Journal

Вот вам план на декабрь

Уже завтра выйдет ежегодный адвент-календарь с задачами и головоломками по программированию — Advent of Code. Календарь в этот раз рассчитан на 12 дней, так что каждый день почти полмесяца будут выходить новые задачи. Решать их можно на любом языке программирования.

А если хочется размять голову перед стартом, можно изучить прошлогодние головоломки и их решение на SQL — забираем.

P.S уже вышел

✖️ xCode Journal

💬 Event Loop в Node.js VS в браузере

Многие считают, что event loop в Node.js и браузере работает одинаково. Однако, несмотря на общие черты, существуют важные различия, которые влияют на асинхронное поведение и производительность приложения. Разобравшись с этими различиями, можно писать более эффективный асинхронный код и избежать лагов и задержек. Давайте разберемся, что именно отличает работу event loop в этих двух средах.

❌ Браузер: всё о пользовательском интерфейсе

В браузере event loop сосредоточен на работе с пользовательским интерфейсом (UI). Его основная задача — обеспечить плавность рендеринга, быстроту реакции на события, выполнение JavaScript и обработку Web APIs.

В процессе работы с UI браузер использует несколько типов очередей задач. Это microtasks, такие как обработка Promise и queueMicrotask, и macrotasks, в которые попадают setTimeout, setInterval и MessageChannel. Также есть отдельная фаза для рендеринга. Браузер обязан поддерживать плавность UI, поэтому между макротасками он обязательно вставляет фазу рендеринга, что позволяет минимизировать задержки при обновлении интерфейса.

❌ Node.js: event loop от libuv

В Node.js event loop работает на основе библиотеки libuv, которая используется для асинхронных операций, таких как работа с файловой системой, сетью и другими I/O операциями. В отличие от браузера, в Node.js есть несколько фаз, которые позволяют эффективно управлять этими операциями.

Node.js использует шесть фаз, включая Timers (setTimeout, setInterval), Poll (обработка I/O операций), Check (setImmediate) и другие. Основное отличие заключается в том, что Node.js управляет низкоуровневыми операциями с системой, такими как файлы и сеть, в то время как браузер сосредоточен на рендеринге и UI. Это позволяет Node.js быть более гибким в обслуживании серверных запросов и файловых операций.

❌ Где начинается путаница

Существует несколько распространенных недопониманий между setTimeout и setImmediate. В браузере нет метода setImmediate, в то время как в Node.js он выполняется в фазе Check, а setTimeout — в фазе Timers. Это может привести к путанице, особенно при переносе кода между Node.js и браузером.

Также стоит отметить различие в работе microtasks. В браузере микротаски выполняются сразу после каждого макротаска, а в Node.js они выполняются после каждой фазы event loop, что позволяет их более эффективно управлять и избегать блокировки цикла.

❌ Ещё одним важным отличием является рендеринг

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

Например, repaint может произойти между macrotask, microtask и снова macrotask, что важно учитывать при оптимизации производительности в браузере.

❌ Что важно помнить разработчику

• В Node.js основное внимание уделяется I/O операциям, таким как работа с файлами, сетью и процессами. Эти задачи добавляют свои очереди и обрабатываются в разных фазах event loop.
• В браузере event loop синхронизирован с частотой кадров, что критически важно для обеспечения плавности UI.
• Microtasks в Node.js ведут себя агрессивнее, особенно process.nextTick, который может заблокировать переход между фазами event loop, если заспамить его слишком большим количеством задач.
• setImmediate и setTimeout — это не одно и то же. Порядок их выполнения в Node.js зависит от контекста и фазы event loop, в которой они находятся.

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

🚪 Frontender's notes

GPT-5.1-Codex-Max: Новый кодинг от OpenAI 🍆

OpenAI анонсировала новинку, которая может стать настоящим прорывом — GPT-5.1-Codex-Max. Выглядит как не просто шаг в ответ на бурю вокруг Gemini, а вполне себе уверенный шаг вперёд.

Что же интересного в этой версии? Давайте разберёмся.

Революция для Windows и Powershell
Теперь Codex не просто кодит как обычно. Он понял, как работать в среде Windows, и особенно с Powershell. Это означает, что модель теперь точно разбирается в особенностях файловой системы, путях и всем, что связано с Windows. Но это ещё не всё — появилась новая фича под названием "Agent mode". Эта штука позволяет модели работать автономно в терминале, выполняя задачи без постоянного контроля. Не забудьте, что доступ можно настроить, если надо.

Автономность на новом уровне
OpenAI заявляет, что модель способна работать более 24 часов без остановки. Можете себе представить? Правда, тут стоит напомнить про достижение Anthropic с их Sonnet 4.5, которая обещает 30 часов работы. Но всё равно впечатляет, правда?

Новая память — что это значит?
Модель теперь умеет работать с большими контекстами, благодаря новой фиче "compaction". Что это? Когда окно контекста близко к своему пределу, Codex сжимает старую информацию и переносит её в новое окно вместе с актуальной информацией. Как бы креативная версия краткосрочной и долгосрочной памяти, не так ли?

Результаты и метрики
GPT-5.1-Codex-Max показывает отличные результаты — 77.9% точности на SWE-bench Verified, что превосходит даже Gemini 3 и Sonnet 4.5 от Claude. К тому же, модель теперь тратит на 30% меньше токенов при среднем уровне рассуждений, но результаты всё те же.

Так что, эта версия уже доступна для использования в IDE и Codex CLI. Ждете API? Обещают скоро добавить.

Data Science

⚡️ Анти-паттерны больших фронтенд-проектов

Большие фронтенд-проекты не рушатся из-за одной ошибки. Чаще всего их «убивают» мелкие, но системные ошибки в архитектуре, которые приводят к бесконечным поломкам. Давайте рассмотрим самые частые анти-паттерны, с которыми сталкиваются реальные команды.

ℹ️ «Глобальное всё»

Когда всё в проекте глобальное: стили, состояния, утилиты. Это создаёт цепочку зависимостей, и любая правка может привести к непредсказуемым поломкам.

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

ℹ️ «Компоненты-монолиты»

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

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

ℹ️ «Push-архитектура»

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

Решение: централизованный слой данных. Используйте query-клиенты, сервисы или модели для эффективного управления данными.

ℹ️ «Секретные зависимости»

Компоненты, которые используют скрытые зависимости, такие как localStorage, window, сторонние сервисы или скрытые контексты, не указаны явно.

Решение: всегда документируйте зависимости и явно описывайте их в коде. Это упростит тестирование и переносимость компонентов.

ℹ️ «Тяжёлые re-render цепочки»

Когда один компонент меняет state, и пол-страницы перерисовывается, вызывая лаги и замедление интерфейса.

Решение: используйте signals, selectors и fine-grained реактивность. Архитектурная изоляция поможет минимизировать лишние ререндеры.

ℹ️ «Всё через Redux / Context / глобальный стор»

Когда вы храните глобальный стейт там, где он должен быть локальным. В итоге глобальное состояние становится тяжёлым и трудным для управления.

Решение: минимизируйте использование глобального стейта. Локальные состояния должны храниться локально.

ℹ️ «Типизация по настроению»

Когда часть кода типизирована, а часть — нет, или используется any. В итоге типизация не защищает, а мешает.

Решение: установите единые правила типизации и используйте строгий линтинг для соблюдения этих правил.

ℹ️ «Сложность вместо простоты»

Когда для решения простых задач используются сложные абстракции, кастомные DI, самописные хуки и роутеры, что усложняет поддержку кода.

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

ℹ️ «Отсутствие архитектурных границ»

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

Решение: используйте feature-sliced или modular архитектуру, следите за слоями, внедрите статический анализ зависимостей и запретите пересечения между слоями.

📌 Большие проекты не рушатся на раз-два. Они как бы потихоньку «гниют», но если у вас хорошая архитектура, дисциплина и вы регулярно что-то улучшаете, то можно избежать многих проблем.

🚪 Frontender's notes

JavaScript сегодня отмечает 30-летие 🎂

Именно 4 декабря 1995 года миру показали язык под знакомым нам названием — JavaScript.

❌ Вот история именинника:

• У языка было три имени за пару месяцев.
Сначала его назвали Mocha, потом переименовали в LiveScript, и только затем закрепилось финальное — JavaScript.

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

• JS слепили всего за 10 дней.
Брендан Эйх в бешеном темпе собрал первую версию, когда в Netscape решили: «нам срочно нужен язык для скриптов в браузере».

• Создатель языка успел стать CEO Mozilla — и быстро лишиться должности.
Из-за скандала вокруг его гомофобных взглядов Эйху пришлось уйти с поста, хотя имя JavaScript уже навсегда вписано в историю.

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

🚪 Frontender's notes

📣 Синхронизация состояния между вкладками: BroadcastChannel, SharedWorker и localStorage

Когда пользователь открывает несколько вкладок одного приложения, часто возникает проблема синхронизации состояния. Например, пользователь может выйти из аккаунта в одной вкладке, но в других вкладках приложение продолжит считать его авторизованным. В 2025 году у нас есть несколько инструментов, которые помогают решить эту задачу: BroadcastChannel, SharedWorker и, для старых браузеров, localStorage.

➕ BroadcastChannel — простое решение для синхронизации сообщений

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

Преимущества: простота, быстрая доставка, работа в фоновом режиме.
Ограничения: не поддерживает общее состояние и сложные операции.

➕ SharedWorker — когда все вкладки работают как одно приложение

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

Преимущества: централизованное хранилище состояния, разделение ресурсов и снижение повторных API-запросов.
Ограничения: не поддерживается в Safari, требует сложного дебаггинга и продуманной архитектуры.

➕ LocalStorage + storage event — старый, но работающий способ

Один из самых простых методов синхронизации данных. Этот подход подходит для проектов, требующих поддержки старых браузеров и не использующих Service Worker или SharedWorker, а также для простых случаев синхронизации между вкладками.

Преимущества: простота реализации и широкая совместимость.
Ограничения: хранит только строки, событие storage срабатывает в других вкладках, а не в той, где произошли изменения, и может быть медленнее, чем BroadcastChannel.

✅ Примеры:

// BroadcastChannel
const channel = new BroadcastChannel("session");

channel.onmessage = (e) => {
console.log("message:", e.data);
};

channel.postMessage({ loggedOut: true });

// SharedWorker
// main.js
const worker = new SharedWorker("worker.js");
worker.port.postMessage({ type: "ping" });
worker.port.onmessage = (e) => console.log(e.data);

// worker.js
onconnect = (e) => {
const port = e.ports[0];
port.onmessage = () => port.postMessage("pong");
};

// LocalStorage + storage event
window.addEventListener("storage", (e) => {
if (e.key === "logout") {
// синхронизация
}
});

📌 Для синхронизации состояния между вкладками используют BroadcastChannel для уведомлений (например, для событий входа/выхода), SharedWorker для разделения состояния в PWA и дашбордах, а в старых браузерах — localStorage с событием storage. У каждого инструмента своя фишка, и выбор зависит от того, насколько замороченный у тебя проект, какие браузеры поддерживаешь и с какими данными работаешь.

🚪 Frontender's notes

🌎 Google не разрешает сотрудникам использовать свою же недавно выпущенную IDE Antigravity

И, видимо, не зря — реддитор рассказал, что ИИ-агент Antigravity случайно удалил весь его диск, пока пытался исправить баг:

«Я просматриваю журналы с предыдущего шага и с ужасом вижу, что команда, которую я выполнил для очистки кэша проекта (rmdir), по всей видимости, ошибочно указала на корень вашего диска D:, а не на конкретную папку проекта.
Мне очень, очень жаль.»

✖️ xCode Journal

⬇️ Modern lazy-loading: что грузить первым в 2025

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

❌ First-party UI: что грузить первым?

В 2025 году при разработке UI важно сосредоточиться на быстрой загрузке ключевых элементов — каркаса, кнопок, инпутов и навигации. Это улучшит метрику Interaction to Next Paint (INP), ставшую приоритетом для браузеров. Критичные стили и UI-код также должны загружаться немедленно.

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

➡️ Всё, что ниже сгиба, можно загружать лениво

Ленивую загрузку можно применять ко всем тяжелым секциям, изображениями с атрибутом loading="lazy", а также к модулям, которые загружаются после первого скролла. Новый IntersectionObserver 2 делает отслеживание видимости элементов более надёжным и быстрым, что идеально подходит для массового отслеживания lazy-load.

❗️ Библиотеки и UI-компоненты — только по мере необходимости

Если пользователь не взаимодействует с модалкой, зачем грузить библиотеку для порталов, анимаций или форм? Используйте React.lazy или его аналоги для ленивой загрузки компонентов. Золотое правило: никогда не грузите компоненты без необходимости.

↗️ Статические ассеты: как загрузить их умнее

В 2025 году можно расставлять приоритеты для загрузки ассетов. Для критичных изображений используйте атрибут fetchpriority="high", для шрифтов — preloading, для сторонних API — preconnect, а для фоновых картинок — приоритет low.

📣 Не забываем про «delayed-init»

Иногда нужно загрузить код сразу, но выполнить его позже для минимизации нагрузки на UI. Это важно для аналитики, сложных элементов (карт, списков) и операций, которые могут «заморозить» основной поток.

Используйте requestIdleCallback, setTimeout(..., 0), Web Workers и scheduler API для снижения нагрузки на UI. Этот подход не является настоящей lazy-load, но эффективно помогает оптимизировать работу интерфейса.

💡 AI-предсказания: предсказываем, что загрузить

Фреймворки начинают использовать данные о поведении пользователей, чтобы предсказать, какие ресурсы будут востребованы. Например, Next.js, Remix, и Astro могут предварительно загружать ссылки при наведении, использовать гироскопические данные для prediction-preloading и статистическое кеширование переходов.

📝 Пример кода:

// Пример кода для React:
const FancyModal = lazy(() => import("./FancyModal.js"));

// Для ванильного JS:
if (needsModal) {
import('/modal.js').then(initModal);
}

// Ленивую загрузку стилей тоже стоит включать с использованием атрибута media (html):
<link rel="stylesheet" href="theme-extra.css" media="print" onload="this.media='all'">

📌 Логика lazy loading стала более сложная. Понимание, что и когда грузить, поможет вашей странице работать быстрее и юзеры будут довольны.

🚪 Frontender's notes

Критическая уязвимость в React Server Components (CVSS 10.0). Рекомендуется обновление

🚨 React-команда официально сообщила о серьёзной проблеме безопасности в React Server Components.
Уязвимость позволяет выполнить произвольный код на сервере без аутентификации — достаточно отправить специально сформированный HTTP-запрос.

Даже если вы не используете React Server Functions напрямую — вы всё равно можете быть уязвимы, если ваш проект поддерживает React Server Components.

Уязвимость получила идентификатор CVE-2025-55182, оценку CVSS 10.0, и затрагивает версии 19.0, 19.1.0, 19.1.1 и 19.2.0 следующих пакетов:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

🔘Что делать прямо сейчас

Патч уже опубликован. Нужно обновиться на версии: 19.0.1, 19.1.2, 19.2.1.
Если ваш React-код вообще не работает на сервере, или вы не используете фреймворки/бандлеры с поддержкой RSC, то вы не затронуты.

Некоторые экосистемы зависели от уязвимых пакетов. В зоне риска:

Next.js
React Router (нестабильные RSC-API)
Waku
@parcel/rsc
@vitejs/plugin-rsc
Redwood SDK

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

🔘В чём суть уязвимости

React Server Functions позволяют клиенту вызывать функции на сервере. На стороне клиента вызов превращается в HTTP-запрос, который React затем десериализует и мапит на вызов серверной функции.

Проблема — в том, как React декодирует payload от клиента.
Атакующий может создать вредоносный HTTP-запрос, который при десериализации приводит к удалённому выполнению кода.

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

🔘Инструкция по обновлению Next.js

Установите патч в рамках вашей версии:

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7

Если вы сидите на 14.3.0-canary.77 или выше — откатитесь на стабильную 14.x:

npm install next@14

React Router (нестабильные RSC API)

Обновите зависимости:

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

Expo
См. changelog на expo.dev.

Redwood SDK
npm install rwsdk@latest
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Waku
npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

Vite RSC
npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

Parcel RSC
npm install react@latest react-dom@latest react-server-dom-parcel@latest

Turbopack RSC
npm install react@latest react-dom@latest react-server-dom-turbopack@latest

Webpack RSC
npm install react@latest react-dom@latest react-server-dom-webpack@latest

📅 Таймлайн

29 ноября — уязвимость найденa и отправленa в Meta Bug Bounty.
30 ноября — Meta подтвердила и начала работать над фиксом с командой React.
1 декабря — фикc готов, идёт работа с хостингами и OSS-проекта́ми над валидацией и mitigations.
3 декабря — патч опубликован, уязвимость раскрыта публично.

📍 Ссылка на оригинал статьи...