Ви не розумієте Angular. Просто звикли, що воно працює

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Angular — це один із небагатьох фреймворків, який бере на себе величезну кількість складності: change detection, dependency injection, zones, rendering, SSR, signals. І в цьому його головна сила. Але в цьому ж і проблема.

За останні роки Angular зробив дуже сильний ривок вперед: standalone components, signals, new control flow, SSR з hydration, рух у сторону zoneless підходу. Це об’єктивно круто. Команда Angular реально розвиває екосистему і намагається зробити її сучасною та продуктивною. Але є нюанс — темп цього розвитку занадто високий.

Кожні приблизно пів року виходить новий реліз. Нові підходи, нові «правильні» способи писати код. І що робить більшість розробників? Вони пробігаються по changelog, дивляться приклади, копіюють новий синтаксис і інтегрують його у свої проєкти (і це в кращому випадку). Але при цьому не відбувається головного — розуміння того, що реально змінилося під капотом.

Angular поступово перетворився на чорний ящик. Більшість девелоперів не розуміють, як працює change detection, не знають, що саме тригерить перевірку компонентів і коли відбувається ререндер. Zone для багатьох — це взагалі «магія», яка просто існує. Про performance починають думати тільки тоді, коли вже з’являються лаги, і тоді починається хаотичне оптимізування без системного підходу.

Signals — це дуже показовий приклад. Це сильна ідея, яка потенційно спрощує реактивність і робить її більш передбачуваною. Але в реальності більшість використовує signal як заміну BehaviorSubject, не розуміючи саму реактивну модель. Починається змішування signals і RxJS без чіткої архітектури, без розуміння, коли і чому відбувається оновлення. API змінюється, але рівень розуміння залишається тим самим.

І проблема тут не в Angular. Angular якраз стає кращим. Проблема в тому, що фреймворк розвивається швидше, ніж девелопери встигають його осмислити. У результаті з’являються складні проєкти, побудовані на наборах «best practices», які ніхто до кінця не розуміє. З’являються баги, які «виникають самі по собі», проблеми з продуктивністю, оверінжиніринг, де одночасно використовуються NgRx, signals, кастомні сервіси і ще кілька шарів абстракції.

Найцікавіше, що Angular спеціально зроблений так, щоб ти міг не розуміти, як він працює. Він бере на себе складність і дозволяє просто писати код, який «працює». І більшість цим користується. Це зручно, швидко і дає відчуття контролю. Але це і створює ілюзію, що ти розумієш систему, хоча насправді ти просто навчився правильно нею користуватися.

Проблема не в тому, що Angular складний. Проблема в тому, що він занадто добре приховує цю складність. І саме тому більшість розробників не відчуває потреби копати глибше. Поки все працює — питань немає. Але як тільки щось ламається або починає гальмувати, стає очевидно: фундаменту немає. Є лише звичка довіряти магії.