Почему пора убивать Angular?
Текст публикуется в переводе, автор оригинальной статьи Beau Beauchamp.
Я занимаюсь разработкой уже более 20 лет в самых престижных компаниях Северной Америки. И последние несколько лет я наблюдаю за тем, как деградирует разработка пользовательских интерфейсов. Я говорю о "fad-tech" – модных технологиях, милых и не очень маленьких кусочках CSS и JS, которые так любят новички и даже некоторые опытные инженеры, хотя, казалось бы, они должны понимать, с чем имеют дело.
Стремительно развивающаяся культура использования фреймворков вроде Angular завела нас в настоящий кодовый ад, и этому бреду не видно конца.
Каждый день на мою электронную почту приходят вакансии от компаний всех мастей и размеров, которые страстно желают нанять ОПЫТНЫХ разработчиков Angular 4, 5, 6, 7, 8, 10 и 12 со стажем работы не менее пяти лет. Все это поддерживает и укрепляет тот ужас, который мы называем искусством создания современных интерфейсов.
Несколько лет назад я проходил интервью в Electronic Arts, и в ходе него мне сказали, что компания отказывается от всех UI фреймворков и возвращается к простому ванильному ECMA (JavaScript). К плагинам для jQuery-людей вроде меня. Я был удивлен и заинтригован.
Теперь я понял, почему они были правы. Теперь все поняли.
KISS: Keep it Stupid-Simple
Мне не нравится называть людей тупицами, поэтому я немного переиначил классический акроним, извините.
Так или иначе, принцип KISS был полностью утрачен в последних версиях Angular. Это уже не только UI-фреймворк, но и бэкенд-сервис. Вашим UI-разработчикам теперь приходится писать серверный код, который выходит за рамки простой HTML-шаблонизации. Конечно, кто-то может сказать, что это хорошо, а не плохо, но я так не считаю.
SPA (одностраничные приложения) остались в прошлом. Их трудно поддерживать, они вредят аналитике и SEO. Поисковые роботы больше полагаются на фактическое изменение URL-адреса.
Да, проблемы SPA можно решить обходными путями, но в этом-то и дело! Зачем писать дополнительный код, чтобы веб работал так, как он и без того работает на нормальных сайтах.
Просто скажи Нет компиляторам UI
Еще парочка модных технологий, от которых пора отказаться – Sass и Less. На самом деле, мне нравится организация кода, которую предлагают эти CSS-фреймворки. Но мне очень не нравятся "миксины", а точнее то, что их необходимо компилировать, чтобы они работали.
Я считаю, что браузеры просто изначально должны поддерживать формат написания стилей, который используется в SCSS , но это тема для другой статьи.
Все эти "псевдоCSS" не экономят ваше время. Их не просто изучать и использовать. И в конце концов они лишь генерируют хороший, чистый, правильный CSS-код, который мы изначально должны писать сами. Если вы хотите использовать Sass или Less и предварительно компилируете их в собственной среде разработки, нет проблем. Но эти файлы не должны попадать в CICD-пайплайн для компиляции во время развертывания приложения.
То же самое относится и к любой JS-библиотеке или фреймворку, которые в конечном итоге также компилируются в обычный ванильный ECMA. Каждый шаг, который вы добавляете в CICD, растягивает и раздувает то, что должно быть очень простым и быстрым. Мы должны искать способы уменьшить количество шагов в этом процессе, а не накапливать их только потому, что Jenkins нам это позволяет.
Angular раздувает UI
Вы можете назвать меня пуристом от UI, но я не считаю, что то, что мы имеем сейчас, это "искусство". Очевидно, работникам Google скучно и хочется чем-то заняться, поэтому они создали Angular. Но этот и другие подобные фреймворки разрушают простоту UI, а не делают его проще.
Angular обходится компаниям в миллиарды
В конце концов, фреймворк должен облегчать, а не усложнять разработки. И предполагается, что эта простота сэкономит компаниям кучу денег, а не наоборот.
Однако в реальности все не так – Angular стоит очень дорого.
Нужно тратить очень много денег на обучение и переобучение сотрудников, работающих с современными UI-фреймворками, ведь их создатели имеют привычку каждый год выпускать новые версии. Да, Angular обещает, что все изменения будут обратно совместимы, но это лишь добавляет еще больше сложности. Каждый новый "реально классный" компонент опять меняет весь налаженный процесс разработки.
И пусть вам помогут высшие силы, если вы подрядчик, работающий с несколькими проектами на разных UI фреймворках. Вам нужно не только изучить все 12 вкусов Angular, но и разные версии React и Vue, которые какой-то энтузиаст начал использовать 4 года назад, а потом ушел, чтобы разрушить еще чей-нибудь стек технологий.
Пришло время отправить Angular (и другие ему подобные проекты) на свалку неудачных экспериментов, где им и место.
Чем же заменить Angular?
Я ничего не имею против использования открытых утилитарных библиотек вроде jQuery, или библиотек компонентов, или CSS-фреймворков вроде Bootstrap. Их можно добавить в проект одной строчкой кода, и они действительно очень облегчают жизнь разработчиков.
Однако если фреймворк нуждается в Node.js, чтобы работать, как Tailwind, он будет постоянно обновляться, и вам придется постоянно обучать и переобучать людей для его использования. Это будет стоить вам кучу денег – разве это круто?
Я вижу множество компаний, ищущих UI-инженеров, которые убеждены, что им обязательно нужен кто-то с пятилетним стажем работы с Angular. Это полный бред. Я могу создать элегантный и функциональный UI на простом JS, без всяких фронтендно-бэкендных сложностей Angular и за меньшее время.
Обычный JavaScript при толковом применении обеспечивает идеальный баланс между сложными интерфейсами и элегантной простотой в DOM.
Если что-то ломается в таком приложении, вам нужна пара секунд, чтобы найти проблему, используя инструменты разработки в любом браузере. И нет необходимости устанавливать новые инструменты или добавлять новый слой раздувания, чтобы отлаживать скомпилированный код.
Святой Грааль написания любого программного кода заключается в его простоте. Но мы, современные разработчики, полностью про это забыли. Мы окружили себя блестящими "современными" технологиями, которые обещают сделать нашу работу проще, но по факту лишь усложняют ее.
Помните, что ни Google, ни другой создатель UI-фреймворков не будут оплачивать ваши счета за персонал и поддержку проекта. Берите на себя ответственность за технологический стек и вернитесь к рациональному пользовательскому интерфейсу, который красив, прост и удобен в обслуживании.
Комментарии