В части 1 мы выяснили, что объекты в Heap не освобождаются сами по себе этим занимается Garbage Collector. Но как именно GC решает, что можно удалить? Если подумать, задача не такая очевидная: объект не нужен - понятие логическое, а GC работает с физическим графом ссылок.

Ответ в том, что GC не пытается угадать намерения программы. Он задаёт более простой вопрос: можно ли добраться до этого объекта из работающего кода? Если нельзя объект недостижим, и никакой код уже не сможет его использовать. Значит, память можно вернуть.

Алгоритм, реализующий эту логику, называется Mark and Sweep.

Последние пару лет изменили то, как пишется код. Copilot, Cursor, ChatGPT, Claude - все это генерирует вполне работающий JavaScript быстрее, чем успеваешь сформулировать задачу. Это удобно. Но у этого удобства есть обратная сторона, сгенерированный код работает правильно в смысле делает что просили, но не всегда правильно в смысле не течет по памяти и не роняет прод под нагрузкой.

Модели хорошо знают синтаксис и паттерны. Они значительно хуже разбираются в том, что происходит под капотом конкретного движка. Closure, захватывающий лишние данные. Event listener, который никогда не снимается. Объект, который непреднамеренно продлевает жизнь половине DOM дерева. Все это - настоящие ошибки, которые реально встречаются в проде и ни один линтер их не поймает.

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

Эта серия состоит из трех частей. Первая - про то, как V8 вообще организует память, что такое Stack и Heap, чем они отличаются и что такое pointer. Вторая - про сборщик мусора, как он определяет, что живо, а что нет и как делает это, не останавливая программу надолго. Третья - практическое применение, откуда берутся утечки памяти, как их искать и как писать код, который не создает лишней работы для GC.

История проекта началась в прошлом (2025) году. Я преподаю JavaScript в HTML Academy, и когда мне предложили взять поток начинающих разработчиков по Angular, я согласился. Мы успешно прошли базу, но когда дело дошло до HttpClient и обработки данных, я столкнулся с проблемой: студентам сложно понять Observable и реактивный подход, имея в багаже только промисы.

На лекции мне задали резонный вопрос: А где посмотреть актуальные и понятные материалы по RxJS?. Я провел небольшой ресерч и понял, что ниша полупустая: видеокурсы - это долго, документация - сложно, а интерактивной практики почти нет.

Так появился мой open-source проект. В этой статье я показываю честную аналитику за 90 дней: как набрать 1000 пользователей без рекламы, почему провалилась моя любимая фича и как пет-проект превращается в полноценный продукт.

Как Angular Ivy находит зависимости за O(1)? Глубокое погружение в алгоритм резолва: от генерации уникальных ID токенов до битовой магии Блум-фильтров. Разбираем, почему строковые токены замедляют ваше приложение и как работает наследование кумулятивных масок в LView.

Пользователи ненавидят спиннеры. Они хотят видеть лайк сразу после клика. Optimistic UI решает эту проблему, но создает новую: что делать, если сервер вернет ошибку?

В императивном коде (Promise/async-await) откат состояния превращается в ад из try/catch и ручных мутаций переменных, порождая Race Conditions.

В этой статье я покажу, как реализовать надежный паттерн Compensating Transaction на чистом RxJS. Мы построим архитектуру, где состояние это поток, который невозможно "сломать" частыми кликами или сетевыми сбоями. Никаких if/else, только чистые потоки.

С нуля создаем Node.js-сервис для GitHub, который использует LLM (OpenRouter) для построчного код-ревью Pull Request. Разберем: верификацию вебхуков, борьбу с непредсказуемостью LLM и превращение хаоса в отказоустойчивый инструмент.

Angular Signals 101 Это не поверхностный обзор, а полное погружение в мир сигналов. Мы разберем всё: от публичного API до внутреннего устройства планировщика в Zoneless.

ControlValueAccessor - это то, что отделяет профессиональную дизайн‑систему от набора костылей. Но как грамотно связать его с состоянием контрола (invalid, touched), не создав циклических зависимостей? Эта статья - не просто «ещё один туториал». Это пошаговое руководство по созданию универсального инпута на современном стеке: Signals, OnPush и безопасный инжект NgControl. Разбираем раз и навсегда.

Dependency Injection (DI) один из столпов, на которых держится фреймворк Angular. Каждый разработчик, так или иначе, сталкивается с ним с первого дня: запрашивает сервисы в конструкторе, добавляет providedIn: 'root' и видит, как «магия» работает. Но именно в этом и кроется ловушка.

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

Эта статья не очередной пересказ официальной документации. Это глубокое погружение в архитектуру и философию Dependency Injection в Angular. Наша цель демистифицировать «магию» и превратить ее в предсказуемый, управляемый и мощный инженерный инструмент в вашем арсенале.

Мы пройдем путь от фундаментальных принципов инверсии контроля (IoC) до тонкостей иерархического инжектора. Мы разберем на атомы все стратегии предоставления зависимостей, научимся управлять их жизненным циклом и областью видимости. Мы изучим продвинутые паттерны с использованием InjectionToken и multi-провайдеров и поймем, как современная функция inject() меняет подход к композиции логики.

В Angular любое изменение в компоненте, которое отображается на экране, является результатом работы механизма отслеживания изменений (Change Detection, CD). За этим процессом стоит Zone.js, который можно представить в роли дирижера, сообщающего компонентам о необходимости обновить DOM.

Zone.js не запускает CD сам. Он лишь создает контекст, в котором Angular потом может его запустить. Его задача только уведомлять Angular о завершении асинхронных операций, после чего Angular решает, нужно ли проверять изменения.

Чтобы понять важность такого подхода, нужно учитывать особенности JavaScript. В JavaScript асинхронные операции, такие как setTimeout или fetch, разрывают стек вызовов. Это значит, что callback-функция, выполняемая после завершения асинхронной операции, не имеет информации о контексте, в котором она была вызвана. Для фреймворка, который отслеживает изменения, это создает определенные трудности: как узнать, что асинхронная операция завершилась и, возможно, изменила данные?

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

Часто в компонентах можно встретить такой код: