Как 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, от них пора избавляться.
Привет, меня зовут Дарина. Два очень увлекательных года я работала в команде разработки дизайн-системы 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)
Я был программистом больше 20 лет. Начинал с плюсов и геймдева, но работал и с HFT, и с мобильными играми на Java, писал под Unity и C#, трудился на банки и автоматизировал бизнес.
В конце 2023 года я конкретно выгорел и, имея на счету средства, чтобы не работать несколько лет, решил отдохнуть. Примерно в это же время начал усиливаться хайп вокруг нейросетей, к которым я всегда относился очень скептически, поскольку помнил их возможности ещё со времён универа. Для меня это была полузабытая технология из 50-х.
Первая модель, с которой я решил поиграться, — это был GPT-3.5, ретранслировавшийся в телеграм-канал. Особо ничего не ожидая, я попросил его написать код, который делит отрезок пополам. И... у меня отвисла челюсть, когда он действительно это сделал. Дрожащими руками я скопировал и вставил код небольшого контроллера и попросил его запилить в Angular-сервис. И опять он справился на отлично! Назад дороги не было. В первый же день я твёрдо решил бросить опостылевшее программирование и полностью переложить на нейросети написание кода, оставив себе только генерацию идей и тестирование (там, где это необходимо).
Аргументы, что, дескать, «тупая железяка никогда не заменит человека», меня всегда веселили. Да мне плевать, кто там и где кого заменит. Если раньше при сборке приложения вываливались непредвиденные ошибки и я, чертыхаясь, откладывал задачу, то теперь я просто на автомате копипастил код, шёл на кухню за кофе и вставлял правки, которые предлагала та самая «тупая железка».
Первый проект, на котором я решил опробовать нейросети, — это ru-ticker.com. Он много лет кормил меня, но конкуренты выросли в большие корпорации с капитализацией в миллиарды, и мне уже было не угнаться со своим пет-проектом, который принёс только несколько миллионов, но рублей. Задача была портировать его на Angular, который я знал посредственно — на уровне «поправить баги в корпоративном проекте». В итоге примерно за полтора-два месяца я полностью портировал фронт проекта, который до этого ковырял пару лет, плюс походя реализовал такие плюшки, как автоматический парсинг данных и текста с преобразованием нейросетью для лучшей индексации поисковиками.
Решил мигрировать с WebStorm на VS Code, но обнаружил, что нет поддержки автоимпорта Angular-компонентов. В WebStorm это работало из коробки — начинаешь писать <app-, IDE сразу подсказывает компоненты и автоматически добавляет импорт. В VS Code такого не было.
На первый взгляд задача выглядела несложной — пару регулярок накидать и можно сделать своё решение.
Но пока я разбирался с регулярками, Angular-разработчики выпустили официальную поддержку: добавили импорты на автокомплит и диагностику. Можно было опустить руки, но официальная реализация оказалась неидеальной, и у меня было несколько идей фич, которые позволяют сохранить актуальность проекта и приблизить опыт работы к WebStorm.
Привет, Хабр!
Каждый, работавший с формами в Angular, рано или поздно сталкивается с ситуацией, когда стандартных полей ввода недостаточно. Хочется сделать что-то свое: например, красивый рейтинг в виде звёздочек, компонент для ввода телефона с маской или даже кастомный текстовый редактор на базе contenteditable. Однако просто создать компонент недостаточно, Angular Forms не поймет, как работать с вашим контролом без дополнительных вмешательств.
Миграция с одного фреймворка на другой, например, с Angular на React, — задача, с которой сталкиваются многие команды. Причины могут быть разными: устаревший стек, проблемы с поддержкой, нехватка специалистов на рынке или потребность в более современных инструментах. Так или иначе, в какой-то момент становится очевидно: продолжать развивать проект на старом фреймворке становится дороже и рискованнее, чем перенести его на новый.
Меня зовут Александр Марченко. Я руководитель команды Frontend-разработки в ОК. В этой статье я расскажу о особенностях и способах миграции Angular приложения на React, а также поделюсь своим опытом.
Переменные Bootstrap — мощный инструмент для управления стилями, но без правильной структуры их тяжело использовать.
В этой статье я расскажу, как организовать SCSS-файлы, подключать глобальные переменные и сделать их доступными во всех компонентах Angular. Такой подход не только экономит время, но и делает проект более понятным для команды. А для больших проектов на NX вы узнаете, как делиться стилями между разными приложениями и библиотеками.
Фронтенд давно упёрся в потолок оптимизаций. Мы научились грамотно мемоизировать, батчить обновления, выносить тяжёлые вычисления в воркеры, но каждый раз упираемся в одну и ту же проблему: компоненты всё ещё перерисовываются чаще, чем нужно.
React стал символом этой модели. Благодаря Fiber и Concurrent Mode он действительно стал быстрее, но его архитектура по‑прежнему опирается на дерево компонентов и диффинг виртуального DOM. Даже с умным планировщиком React всё ещё «пересчитывает дерево», а не конкретные зависимости данных.
И вот на этом фоне появилась Signals — архитектура, которая предлагает другой путь.
Не оптимизировать старую модель, а избавиться от неё, сделав обновления атомарными и точечными. Без VDOM, ререндеров и догадок.
В этой статье мы разберём, чем «сигнальная реактивность» отличается от компонентной, и на реальных примерах из Solid.js и Angular Signals посмотрим, где именно проходит граница между «умным диффом» и «fine‑grained реактивностью».
