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

💥 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 декабря — патч опубликован, уязвимость раскрыта публично.

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

🎭 Как писать фронтенд-API без боли

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

⬆️ Предсказуемость API

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

⬆️ Документация, которая работает автоматически

Ручная документация быстро устаревает. Используйте инструменты, которые генерируют документацию автоматически. Применяйте OpenAPI или Swagger, JSON Schema, и автоматическую генерацию TypeScript-типов и клиента. Так API и документация будут всегда в актуальном состоянии, и фронтенд станет намного стабильнее.

⬆️ Стабильность типов

Проблемы начинаются, когда поля данных могут быть как null, так и отсутствовать. Это ломает UI и делает приложение нестабильным. К примеру, лучше иметь всегда однотипную структуру с корректным значением, чем случайные поля с разными типами данных. Убедитесь, что данные всегда стабильны и предсказуемы.

⬆️ Избегайте «магических значений»

Пример плохого API: { "status": 3 }. Какое значение означает 3? Это нечитаемо. Лучше использовать понятные значения, например { "status": "blocked" }. Это снижает количество ошибок, делает API легче в поддержке и чтении, а также повышает понимание со стороны разработчиков.

⬆️ Ошибки — это не просто статус коды

Ошибки должны быть обработаны с умом. Базовые коды ошибок 200 и 500 недостаточны для хорошей работы. Вместо этого используйте чёткие коды ошибок с описанием. Например, если сессия истекла, верните:

{
"error": {
"code": "INVALID_TOKEN",
"message": "Token expired"
}
}

Это поможет сделать более эффективное восстановление сессий, ретраи и улучшит UX.

⬆️ Когда пишете API, учитывайте, что фронтенду важно:

• Меньше мелких запросов
• Возможность кэширования
• Нормализованные данные
• Компактные ответы
• Фронтенд не любит, когда API возвращает огромные ответы с лишними данными. Помните о пагинации, батчинге и стабильных ETags для ресурсов.

⬆️ Давайте всё, что нужно для кэширования

API должно поддерживать кэширование. Используйте такие механизмы, как ETag, Cache-Control, Last-Modified и max-age. Это позволяет фронтенду эффективно использовать кэш, уменьшить нагрузку и ускорить работу.

⬆️ Защищайте от over-fetching и under-fetching

Убедитесь, что API не отправляет лишние данные (over-fetching), например, если вам не нужны роли пользователей или их настройки. Также не стоит заставлять фронтенд делать несколько запросов для получения нужных данных (under-fetching). Используйте view-модели, которые заточены под конкретные UI-экраны.

⬆️ Осознанно подходите к версионированию API

Версионирование API должно быть осознанным. Простой путь с номерами версий /v2, /v3 — это ещё не всё. Важно обеспечивать совместимость внутри каждой версии и предусматривать возможность отката. Версионирование должно быть предсказуемым и чётким.

⬆️ Создайте клиентскую обёртку

Фронтенд должен самостоятельно решать такие задачи, как ретраи, отмена запросов, debounce, тайм-ауты и токен-логика. Это не должно быть задачей бэкенда. Создайте единый слой API для клиента с помощью custom fetch wrapper, axios instance или TanStack Query. Один класс для всех запросов поможет добиться более стабильного поведения и улучшить контроль над запросами.

📌 Крутое фронтенд-API — это не просто набор точек входа, а целая система, которая должна быть предсказуемой и стабильной. Давайте создавать API, которое не ломает фронтенд, а упрощает жизнь всей команде.

🚪 Frontender's notes

❌ 10 ошибок в lazy-loading, которые замедляют сайт

Недавно мы писали про lazyLoading в этом посте. Продолжаем тему

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

❌ Ленивая загрузка критичного UI

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

❌ Грузить код лениво, но слишком поздно

Ошибка, с которой сталкиваются многие: компонент загружается лениво, но нуждается в немедленной активации. Из-за этого возникает задержка, и пользователь видит лаги или мерцание. Чтобы избежать этого, используйте предзагрузку (prefetch) вместе с ленивой загрузкой.

<link rel="prefetch" href="/modal.js">

❌ Ленивое загружение там, где нужна отложенная инициализация

Некоторые операции, такие как работа с картами, сложными таблицами или WebGL, требуют, чтобы код был загружен сразу, но его выполнение можно отложить. Для этого используйте requestIdleCallback, setTimeout(0) или Scheduler API.

❌ Ленивая загрузка маленьких модулей

Если модуль весит 1-3 KB, разбивать его на отдельный чанк — это лишняя нагрузка. Модули такого размера не нужно загружать лениво, так как это добавит ненужные сетевые запросы и усложнит граф зависимостей. Ленивая загрузка должна применяться только к тяжелым и ресурсозатратным модулям.

❌ Ленивая загрузка без учета поведения пользователя

Ошибка заключается в том, что модалки или другие элементы функционала загружаются лениво, даже если пользователь почти сразу же взаимодействует с ними. В 2025 году есть инструменты, как prediction-preload в Next.js, Astro или Remix, которые помогают предугадывать действия пользователя и загружать необходимые компоненты заранее.

❌ Ленивая загрузка изображений без настроек fetchpriority

Когда изображения загружаются лениво, они могут быть исключены из нормального потока загрузки, что может привести к исчезновению важного контента с экрана. Используйте fetchpriority="high" для ключевых изображений, чтобы они загружались первыми.

<img src="hero.jpg" loading="eager" fetchpriority="high">
<img src="section.jpg" loading="lazy">

❌ Ленивая загрузка CSS и блокировка first-paint

При ленивой загрузке тем и дополнительных стилей можно столкнуться с проблемой «unstyled flash» — когда контент появляется без стилей. Чтобы этого избежать, применяйте технику ленивой загрузки для стилей:

<link rel="stylesheet" href="theme.css" media="print" onload="this.media='all'">

❌ Ленивая загрузка маленьких иконок и SVG-спрайтов

Ленивая загрузка маленьких графических ассетов, таких как иконки или SVG-спрайты, приводит к лишним сетевым запросам, но почти не экономит ресурсы. Вместо этого используйте inline SVG, спрайты в <defs>, или пакуйте через Vite или Next.js.

❌ Неправильный threshold в IntersectionObserver

Если вы ставите threshold слишком низким, например, компонент загружается только когда он вошел на 1 пиксель в видимую область, пользователь может увидеть задержку в подгрузке контента. Лучше использовать более высокий порог, чтобы загружать элементы заранее, например:

new IntersectionObserver(callback, { rootMargin: '200px' });

❌ Отсутствие fallback UI

Когда чанк ещё грузится, а пользователь уже видит пустое пространство, это создаёт ощущение тормозящего приложения. Чтобы этого избежать, всегда добавляйте skeletons, placeholders, мини-лоадеры или заранее зарендеренные контейнеры. Это сделает загрузку более плавной и улучшит восприятие приложения.

📌 Правильная ленивая загрузка — это не просто отложить всё на потом. Это умение понять, что можно подождать, а что лучше сразу загрузить.

🚪 Frontender's notes

💥 Нас кинули на курсах — но мы не сдались!

Потратили деньги и нервы — в итоге доучивались сами.
Не ведитесь на курсы: всё нужное уже есть в бесплатных каналах.

Выбирай направление:

👩‍💻 C# 🤖 DS/ML

👩‍💻 C/C++ 😀 1C

👩‍💻 Java 👩‍💻 Python

🖥 PHP 🖥 Frontend

👣 Rust 👣 Golang

👩‍💻 Node.js 💻 DevOps

👩‍💻 QA 👩‍💻 Android

🖥 BA/SA 👩‍💻 Game Dev

👩‍💻 iOS 👨‍💻 Вакансии

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

📌 Подпишись, чтобы не потерять!

🔫 CI/CD для фронтенда: как сделать процессы безболезненными

Когда проект растёт, настоящая боль для команды не всегда в коде, а в процессе CI/CD. Долгие сборки, случайные ошибки, непонятные артефакты — всё это превращается в ежедневную головную боль. Однако, правильно настроенная система CI/CD может быть гораздо проще и эффективнее, чем кажется.

👨‍🎨 Линтить → тестировать → билдить

Частая ошибка команд — начинать с билда и только потом замечать пропущенные ошибки. Это может привести к ситуациям, когда сборка занимает 5 минут, а где то одна недостающая запятая. Правильный порядок: линтинг с ESLint и TypeScript, юнит-тесты, E2E и интеграционные тесты, и только потом билд. Так вы сэкономите время и ресурсы.

⚡️ Кеш — ваш лучший друг

Использование кеша для ускорения процессов стало нормой. Не стоит недооценивать его влияние на скорость работы. Настроенные кеши в pnpm, npm, yarn, Turbo, Nx, Bun, Vite, и GitHub Actions помогут значительно ускорить процессы и сократить время на каждом пуше.

🗳 Разделяйте CI и CD

CI (Continuous Integration) и CD (Continuous Deployment) — это два разных процесса. CI отвечает на вопрос: «Можно ли собрать код и пройти тесты?» CD же решает, готов ли код к деплою в продакшн. Когда эти процессы объединяются в один пайплайн, только добавляется хаос.

💡 Feature Environments

Каждая ветка должна иметь свою отдельную превью-среду, как например в Vercel, Netlify, Cloudflare Pages или Render. Это помогает PM увидеть изменения до мерджа, QA не зависеть от локальных настроек, а дизайнерам проверять анимации. Без этой практики рецензировать UI-фичи становится крайне сложно.

🔄 Деплой должен быть атомарным

Каждый коммит должен приводить к одному артефакту и одному деплою. Без «подправил на сервере» и «почему на проде другая версия файла?». Артефакты должны быть воспроизводимыми, неизменяемыми и версионируемыми.

❌ Прерывание старых джобов

При каждом новом пуше в PR старые CI процессы должны отменяться, чтобы избежать лишних билдов подряд. Это можно настроить в GitHub Actions с помощью простого конфигурационного кода.

📦 Проверка бандла — часть CI, а не когда вспомним

Проверка бандла на каждом этапе CI с помощью таких инструментов как Bundlephobia API, Webpack Bundle Analyzer, Lighthouse-ci поможет избежать случайных увеличений размера бандла.

🤚 Rollout фичей — через feature flags

Деплой не всегда означает релиз. Фича-флаги позволяют постепенно выкатывать изменения, откатывать без деплоя, тестировать экспериментальные сценарии и проводить A/B тестирование.

🔄 Автоматический откат

Настройте автоматический откат на таких платформах, как Cloudflare или Vercel, чтобы обеспечить стабильность в случае ошибок.

💼 CI/CD должен быть другом, а не врагом

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

📌 CI/CD не просто про автоматизацию, это про создание комфортной среды для разработчиков. Правильно настроенная система CI/CD ускоряет процесс разработки и помогает команде работать с минимальными проблемами.

🚪 Frontender's notes

😎 Найдено самое оригинальное портфолио

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

Все ассеты, кстати, тоже сделаны с нуля.

✖️ xCode Journal