Angular обходится всем в миллиарды долларов: почему пора от него избавиться

Бо Бошамп — senior-разработчик и фулстек-архитектор веб-приложений с 20-летним стажем, активный участник опенсорс-проектов и Stack Overflow. А еще — блогер, текст которого о фреймворке Angular практически завирусился. Highload перевел его для вас.

Модные технологии

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

Я больше 20 лет работал разработчиком в самых престижных компаниях Северной Америки. Уже несколько лет я наблюдаю за общим состоянием пользовательского интерфейса и за тем, как он меняется от плохого к худшему. В частности, я говорю о fad-tech («новомодных технологиях») — этих миленьких, но не маленьких кусочках JS и CSS, которые всегда в тренде у новичков, а теперь даже у некоторых опытных инженеров.

Снежный ком культуры использования этих фреймворков, таких как Angular, лавиной обрушил нас в кодовый ад, и не видно конца, когда эта бессмыслица когда-нибудь остановится.

Каждый день я вижу, как мне на электронную почту приходят объявления о работе: компании всех размеров ищут ОПЫТНЫХ разработчиков Angular 4, 5, 6, 7, 8, 10, 12 с как минимум пятилетним опытом создания и поддержки этой ерунды, которую мы называем пользовательским интерфейсом «по последнему слову техники».

Это не «по последнему слову техники». Это ерунда.

Несколько лет назад у меня было интервью в EA (Electronic Arts), во время которого мне сказали, что компания избавляется от всех своих UI-фреймворков и возвращается к написанию простого ванильного ECMA (JavaScript). Я был удивлен, но стало интересно.

Теперь это понятно всем.

Делай проще, тупица

Принцип KISS (Keep it simple, stupid или «Делай проще, тупица» — принцип проектирования, принятый в ВМС США в 1960 году — прим.) полностью утрачен в последних версиях Angular. Это уже не просто UI-фреймворк, но и бэкенд-сервис. Ваши специалисты по пользовательскому интерфейсу теперь должны писать код бэкенда, который выходит за рамки простого HTML-шаблона. Некоторые сказали бы, что это хорошо! Но это не так.

Да, у Angular есть несколько крутых функций — и все они совершенно не нужны для создания эффективного и впечатляющего пользовательского интерфейса или профессионального UX.

SPA (одностраничные приложения) ушли в прошлое. Они сложны в обслуживании и вносят хаос в аналитику и поисковые системы, которые полагаются на то, что URL действительно меняется.

Да, для решения этих проблем есть обходные пути, но в этом-то и суть! Ненормально писать код, чтобы «обойти» то, как на самом деле работает интернет!

Скажите «нет» компиляторам пользовательского интерфейса

Еще одна модная технология, которая существует уже давно и которой тоже пора положить конец — это Sass и LESS. Честно признаюсь, мне нравится организация кода, которую предлагают эти CSS-фреймворки. Что мне не нравится, так это «миксины» и то, что их нужно компилировать для работы.

Я вообще не знаю, почему браузеры не поддерживают SCSS как стандартный способ получения CSS-кода, но это тема для другой статьи.

Суть этих псевдоязыков CSS в том, что они не экономят время, их не проще использовать и изучать, и в конце концов, все, что они делают, — это генерируют красивый и чистый CSS-код, который все мы должны и так писать нативно.

Если вы хотите использовать Sass или LESS и предварительно компилировать их в своей собственной среде разработки — пожалуйста. Но эти файлы не должны попадать в конвейер CI/CD для компиляции во время развертывания.

То же самое относится и к любой другой библиотеке JavaScript или фреймворку, которые в конечном итоге компилируются в простой ванильный ECMA.

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

Angular раздувает пользовательский интерфейс

Считайте меня пуристом, но нынешнее состояние пользовательского интерфейса — это не «искусство», а полный *** (нецензурные выражения опущены автором). Я понимаю, что людям в Google скучно и нужно чем-то заняться, но Angular и другие подобные фреймворки разрушают простоту пользовательского интерфейса, а не делают его проще.

Дело в том, что не нужен раздутый фреймворк для написания чистого, элегантного пользовательского интерфейса или создания эффективного UX. Можно использовать любой нативный механизм шаблонизации, который предоставляет ваш бэкенд, не загромождая фронтенд непонятным и не отлаживаемым скомпилированным JS.

Angular обходится компаниям в миллиарды

В конце концов, фреймворк должен облегчать, а не усложнять кодирование. Он должен экономить деньги компаний за счет простоты использования, а не обходиться им дороже.

Но именно это и происходит — использование Angular стоит дорого.

К сожалению, Angular (как и другие UI-фреймворки) обходится компаниям дорого — много денег уходит на обучение и переобучение сотрудников для изучения и повторного изучения фреймворка, версии которого меняются каждый год или около того. Да, сейчас Angular обещает, что все новые версии будут обратно совместимы. Но опять же — это только увеличит и без того раздутую сложность в ситуации, когда следующий новый «действительно крутой» компонент должен будет снова все изменить.

И да поможет вам Бог, если вы подрядчик, работающий с несколькими компаниями, которые используют различные UI-фреймворки. Теперь вам нужно изучить и знать не только 12 разных вариантов Angular, но и различные версии Vue и React, которые какой-то начинающий программист всучил компании четыре года назад, а теперь ушел разрушать чужой технологический стек.

Пришло время отправить Angular (и других ему подобных) в мусорную кучу неудачных экспериментов, где им самое место.

Что должно заменить Angular?

Ответ довольно прост — заменять его не надо. Избавьтесь от него полностью. Удалите его и пишите простой, легкий в использовании и понимании JavaScript.

Я не против использования библиотек с открытым исходным кодом, таких как jQuery, других компонентов пользовательского интерфейса или CSS-фреймворков, таких как Bootstrap. Их можно «включить» с помощью одной-двух строк кода, и они действительно делают нашу жизнь как разработчиков намного проще!

Но если фреймворк требует Node.js для работы, как Tailwind, или вам нужно обучать и переучивать людей, чтобы использовать его, потому что его продолжают обновлять год за годом, все это стоит вам денег — и ради чего? Это все «супер-круто»?

Суть в том, что Angular мешает работе; он стоит вашей компании тысячи, возможно, десятки тысяч долларов, а если вы компания из списка Fortune 1000, то, скорее всего, он будет стоить вам миллионы в год на поддержку, обновления, обучение и потерю времени, чтобы найти опытных людей (или тех, кто вообще хочет) работать с этим чудовищем.

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

Код на JavaScript, созданный под конкретную цель, обеспечивает идеальное соответствие и баланс между использованием сложностей современного пользовательского интерфейса и сохранением элегантной простоты в DOM.

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

Заключение

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

Ни Google, ни кто-нибудь другой не платят зарплату вашим сотрудникам. Пришло время CTO взять на себя ответственность за технологический стек, отказаться от новомодных технологий и вернуть всех нас к рационально обоснованному пользовательскому интерфейсу, который прост, удобен в обслуживании и красив.