В самой библиотеке часто используется TuiControl, это обертка позволяющая удобно работать с кастомными контролами, однако разработчики в своих проектах продолжают использовать ControlValueAccessor, хотя можно воспользоваться готовым решением из библиотеки.
История проекта началась в прошлом (2025) году. Я преподаю JavaScript в HTML Academy, и когда мне предложили взять поток начинающих разработчиков по Angular, я согласился. Мы успешно прошли базу, но когда дело дошло до HttpClient и обработки данных, я столкнулся с проблемой: студентам сложно понять Observable и реактивный подход, имея в багаже только промисы.
На лекции мне задали резонный вопрос: А где посмотреть актуальные и понятные материалы по RxJS?. Я провел небольшой ресерч и понял, что ниша полупустая: видеокурсы - это долго, документация - сложно, а интерактивной практики почти нет.
Так появился мой open-source проект. В этой статье я показываю честную аналитику за 90 дней: как набрать 1000 пользователей без рекламы, почему провалилась моя любимая фича и как пет-проект превращается в полноценный продукт.
Если Вы до сих пор не перешли с *ngIf, @Input() и ChangeDetectorRef на @if и signal/computed/effects, но подумываете об этом, то прошу под кат. Предполагается, что вы уже имеете опыт в Angular. В статье - небольшая выжимка практического опыта.
Это вторая (и заключительная) часть цикла статей о нашей миграции с Zeppelin. О причинах и первом опыте перехода с Zeppelin я рассказал здесь. В данной статье я хочу большее внимание уделить второму виду Zeppelin notebook, которые срочно нуждались в переносе.
Конечно, отчеты для клиентов не были настолько "забагованы" как рассылки: большая часть проблем с Zeppelin крылась именно в cron-е, который временами работал как хотел (или в интерпретаторах, мы так и не смогли разобраться, но ошибка интерпретатора возникала только когда запускали через cron). В отчетах этого звена не было, поэтому их перенос был плавным и основан скорее на особенностях UI/UX дизайна.
Данная статья может быть полезна аналитикам, которые не знают, какой инструмент использовать для своих задач и думают, что писать графический интерфейс крайне сложно (спойлер, нет), а также для команд, которые устали от Zeppelin как UI-инструмента (и от Zeppelin в целом)
Семь лет в Angular. Позиция lead frontend-разработчика на проекте. Архитектура, оптимизация, legacy-код и Node.js для серверной логики. И при этом — «Гдэ ваши доказатэльства?». Знакомая ситуация? Я прошёл через это и понял, где кроется фундаментальная ошибка.
Это история о том, почему ваш опыт ничего не значит, если вы не умеете его транслировать. Дело не в банальном умении «себя подать» (продать). Дело в том, что нужно сделать это доказательно и желательно быстро, а в GitHub за 7 лет лежит толстый слой пыли. Что показать работодателям, если все это время ты работал? Да, надо было думать раньше, но — «как на охоту, так собак кормить».
Но начнем, конечно, сначала.
Проблема: Пропасть между реальным опытом и его восприятием.
Осознаем простой факт: в современном найме на работу ваш опыт оценивают три разные группы людей, и только одна из них — технические специалисты.
Когда ты в n-й раз получаешь шаблонный отказ от HR-специалиста, ты злишься: «Они ничего не понимают в коде!». И будешь прав, но ошибёшься в другом — ты ожидаешь, что они должны понимать. Их задача иная: отсеять 95% кандидатов по косвенным признакам, чтобы техлидам остались только релевантные.
Что видит HR за 30 секунд просмотра резюме:
Несоответствие уровня и зарплаты. Например, Senior/Lead, указывающий желаемые 2000$ — сумму для Middle-разработчика. Это мгновенно создаёт подозрение в неадекватности или заниженной самооценке.
Размытое описание проектов. Фразы типа «разрабатывал архитектуру» без конкретики масштаба (MAU, количество модулей, команда) звучат пусто.
Отсутствие публичного следа. И это самая большая засада - GitHub с парой заброшенных репозиториев или без него вовсе. Это красный флаг для любого рекрутера в 2026 году.
Как Angular Ivy находит зависимости за O(1)? Глубокое погружение в алгоритм резолва: от генерации уникальных ID токенов до битовой магии Блум-фильтров. Разбираем, почему строковые токены замедляют ваше приложение и как работает наследование кумулятивных масок в LView.
Я не шучу, Илон Маск прав — мы действительно уже существуем в эпоху ИИ-сингулярности.
Что такое сингулярность? По сути — это то, что компьютеры принимают какие-то решения, но мы не можем проверить, почему они это делают, и можем только довериться решению.
Фантастическая литература приучила нас к тому, что это будет выглядеть как что-то вроде ответов на «самый главный вопрос Вселенной и всего такого», прыжков гиперреальности и вообще бога-из-машины.
Но это вовсе не обязательно. Для ИИ-сингулярности достаточен средний или ниже среднего интеллект, чтобы у ИИ было непреодолимое преимущество перед человеком. Поясню, что это значит.
Человек в целом сфокусирован крайне узко. К примеру, технари зачастую знают, как настроить CI/CD-конвейер, но не только не могут отличить Мане от Моне, но даже вообще не знают, что такая отрасль знания существует. И наоборот — пример более практический: хороший маркетолог может не знать ничего о технических сложностях. Основная сложность в бизнесе — это коммуникации. Вообще суть многих видов бизнеса — это соединение ранее несоединимого. Например, дизайн и ЭВМ — и застолбить в своё время неочевидный рынок графических платформ.
И вот тут преимущество LLM проявляется во всей красе. Да, в большинстве сфер его уровень не выше, чем у расторопного и туповатого новичка. Но при этом этих новичков миллионы и миллиарды — во всех возможных сферах, и в роли коммуникатора выступают сами языковые модели. На этом построен принцип thinking-моделей. Помните, как ещё года 2 назад насмехались над тем, что, дескать, тупой ИИ не способен перемножить 2 числа и невпопад угадывает? Стоило под капотом связать его с Python, и для его эффективности оказалось достаточным просто переформулировать запрос и передать его дальше системе. Поэтому как бы небольшие улучшения в модели делают рывок не на 20%, а сразу экспоненциально.
За последние годы фреймворк пересмотрел архитектурные решения и предложил новые подходы, которые не всегда очевидны из документации. В этой статье - взгляд опытного фронтенд-разработчика на текущее состояние платформы и прогнозы на ближайшее будущее.
MDN Baseline badges и влияние на поддержку браузеров в Angular
Начать стоит не с самого Angular, а с важного обновления в веб-документации MDN (Mozilla Developer Network). Там появились Baseline badges (метки), которые позволяют быстро оценить, насколько целесообразно использовать новую фичу — например, часть браузерного API.
TreeMap — это визуализация, где площадь прямоугольника = вес, а цвет = метрика. Отлично подходит для market heatmap (карта рынка), портфелей, иерархий ресурсов и любых “взвешенных деревьев”.
Мне TreeMap понадобился в Angular-проекте под “тепловые карты” и разные иерархические отчёты. Казалось бы — задача стандартная, значит решение должно быть “в один npm install”. Но реальность оказалась неожиданной: готовых TreeMap-решений именно для Angular практически нет.
В итоге я сделал свой standalone компонент и оформил его в npm-пакет: stockchart-treemap.
Дома у меня лежали несколько старых Android-устройств. Они работают, но давно не используются и просто лежат без дела.
Я стал думать, как их можно использовать. Хотелось чего-то простого и полезного: показывать информацию и иногда вводить данные. Ничего сложного, просто что-то, что реально будет использоваться. Так появилась идея превратить их в дашборды.
Потом я понял, что для этого нужна веб-часть и мобильное приложение. Сделал веб-приложение на Analog и Android-клиент на Ionic Framework. В разработке активно помогал AI-ассистент из Qoder — он сильно ускорял работу и решал много задач сам.
Проект пока ещё в процессе, но я решил написать о нём пост. Возможно, кому-то пригодятся мои наработки.
Это интервью — разбор реального опыта миграции фронтенда Compo B2B Platform с Angular 13 на актуальные версии фреймворка (в итоге — Angular 19). Команда Compo Soft прошла путь через несколько мажорных апдейтов, замену и переписывание зависимостей, рефакторинг архитектуры и внедрение новых возможностей Angular — от Standalone Components до Vite и non‑destructive hydration.
Пользователи ненавидят спиннеры. Они хотят видеть лайк сразу после клика. Optimistic UI решает эту проблему, но создает новую: что делать, если сервер вернет ошибку?
В императивном коде (Promise/async-await) откат состояния превращается в ад из try/catch и ручных мутаций переменных, порождая Race Conditions.
В этой статье я покажу, как реализовать надежный паттерн Compensating Transaction на чистом RxJS. Мы построим архитектуру, где состояние это поток, который невозможно "сломать" частыми кликами или сетевыми сбоями. Никаких if/else, только чистые потоки.
Давайте начистоту. Большинство Angular-приложений пишутся по инерции. Мы используем паттерны, которые выучили на заре второй версии, и продолжаем тащить их за собой, игнорируя всё, что фреймворк предложил за последние годы.
Фреймворк постоянно обновляется и дополняется, и уследить за всеми лучшими практиками почти нереально. В итоге даже опытные разработчики продолжают делать ошибки, которые когда-то не считались ошибками. В небольшом проекте это не страшно, но в крупном такие просчеты накапливаются и превращают код в трудноподдерживаемый легаси. Проблема в том, что фреймворк меняется, а привычки остаются.
В этой статье мы не будем говорить о базовых синтаксических ошибках или разбирать, где вы точку с запятой забыли. Речь пойдёт о более глубоком уровне, об архитектурных просчётах и антипаттернах, которые тиражируются из проекта в проект. Многие из этих привычек были допустимы в прошлом, но с приходом новых версий, вроде Angular 20, от них пора избавляться.
Команда JavaScript for Devs подготовила перевод статьи о том, почему веб-команды застревают на орбите фреймворков и забывают о возможностях самой платформы. Автор убеждён: браузеры развиваются быстрее, чем экосистемы вокруг них, а зависимость от React и других инструментов тормозит инновации. Пора снова смотреть на веб как на платформу, а не как на “внутренность” фреймворка.
Привет, меня зовут Дарина. Два очень увлекательных года я работала в команде разработки дизайн-системы Prizm.
Это был мой первый опыт работы над «библиотечным» проектом, и он сильно расширил мой угол зрения и представления о том, как можно работать с кодом. Ещё он подарил множество интересных открытий, которые помогают мне в ежедневной работе и сейчас.
Всем привет!
Меня зовут Илья Чубко, я — технический архитектор в направлении, которое занимается внедрением CRM-системы на low-code платформе BPMSoft для автоматизации и управления бизнес-процессами крупных и средних компаний в единой цифровой среде вендора «БПМСофт».
В статье «Как с помощью Angular доработать CRM-систему: наш опыт с BPMSoft» мы уже рассказывали, как можно создать Angular-приложение и встроить его в систему.
А что, если таких компонентов становится всё больше, они зависят друг от друга и используются как строительные блоки в архитектуре платформы и создаваемых на ней решений?
В этой статье я поделюсь опытом, как мы в К2Тех построили единую экосистему Angular-компонентов — с общей инфраструктурой, управлением зависимостями и автоматической сборкой на базе монорепозитория Nx.
Angular v21 подъехал — и это один из самых насыщенных релизов за последние годы.
Главные нововведения:
🔥 Signal Forms — реактивные формы на сигналах с полной типизацией и упрощёнными кастомными компонентами.
🎨 Angular Aria (Developer Preview) — headless-компоненты с приоритетом на доступность и вашей собственной стилизацией.
🤖 Angular MCP Server стал стабильным — теперь ИИ-агенты могут понимать ваш код, искать примеры, обновлять проект и даже обучать Angular.
🧪 Vitest — новый стабильный test runner по умолчанию.
⚡ Zone.js больше нет в новых приложениях — Zoneless теперь стандарт, что даёт меньше магии, больше производительности.
📚 Обновлённая документация: новый Signals tutorial, переработанный Routing, улучшенное DI, Material-темизация и полноценный гайд по Tailwind.
➕ Плюс десятки мелких улучшений: CLDR v47, RegExp в шаблонах, новый formatter сигналов, улучшения CDK, анимаций и DevTools.
Angular продолжает разворачиваться в сторону реактивности, AI-first разработки и отказа от лишней магии.
Если ещё не пробовали — самое время запустить ng update и посмотреть, что может v21.
Раньше глобальные изменения — обновление Angular, смена сборщика или миграции — превращались в мини-кризис: кто тестирует, кто делает ревью, релиз мог сломать всё. Теперь у нас прозрачный процесс с RFC, согласованием с лидами, SLA на ревью и тестирование, чётким планом релиза и отката.
Результат: меньше хаоса, больше прозрачности и уверенности, что глобальные изменения проходят безопасно.
React — популярная библиотека JavaScript, которая заслуженно пользуется популярностью у фронтендеров. А вот Angular часто называют избыточно усложненным и даже отчасти устаревшим. Мне довелось поработать на реальных проектах и с тем, и с другим, каждый раз проходя путь от «да как на этом вообще можно работать» до «человечество не придумало ничего лучше».
Привет! Я Полина, фронтенд-разработчик в Selectel. В этой статье я решила залезть в темные уголки React и Angular, чтобы лично посмотреть, что же там происходит. Для чистоты эксперимента я выбрала шесть типовых несложных задач, для решения которых подойдет и фреймворк, и библиотека. Подробности под катом.
Когда я только начал осваивать Angular, мне не было до конца понятно, что это за зверь такой — Pipe, и зачем вообще его использовать. Официальная документация гласит следующее:
Pipes представляют специальные инструменты, которые позволяют форматировать отображаемые значения
Да, это действительно объясняет, что делают Pipes. Но в тоже время не отвечает на вопрос, а зачем их использовать? Почему нельзя воспользоваться обычным методом класса? Pipes для меня какое‑то время был тёмной лошадкой. Но потом я узнал «страшный секрет» о Pipes, который всё расставил на свои места
Небольшой спойлер, чтобы не словить минус карму за кликбейт: речь пойдет о том, что чистые Pipes кэшируют результат трансформации (в документации это указано не так явно, как хотелось бы). В статье рассказано, как использовать эту особенность, чтобы избегать проблем во время проверки изменений (Change Detection)
