Я занимаюсь программированием более 20 лет, работал в некоторых из самых приличных североамериканских компаний. Вот уже несколько лет я наблюдаю за тем, что происходит в сфере разработки интерфейсов. Ситуация здесь постоянно ухудшается. В частности, я говорю о «модных технологиях», о довольно крупных фрагментах JS- и CSS-кода, претендующих на остроумное исполнение, которые вроде как должны пользоваться неистовой популярностью у толп новичков. Теперь в эти толпы включают даже и опытных разработчиков, которым полагается что-то понимать в том, чем они пользуются.
Количество случаев практического применения фреймворков, выдающих подобный код, наподобие Angular, растёт как снежный ком. В результате разработчиков подхватила лавина, ввергнувшая их в настоящий «ад программного кода». При этом события развиваются по нарастающей. Сейчас нельзя заметить даже признаков того, что всё это безумие хотя бы выходит на какой-то постоянный уровень.
Каждый день мне на почту приходят вакансии. Компании всех размеров и мастей рыщут в поисках ОПЫТНЫХ Angular 4, 5, 6, 7, 8, 10, 12-разработчиков, которые как минимум 5 лет занимались разработкой и поддержкой того дурдома, который все называют «современнейшими пользовательскими интерфейсами».
Это — не нечто «современнейшее». Это — дурдом.
Несколько лет назад я был на собеседовании в EA (Electronic Arts). Там мне сказали, что компания избавляется от всех своих UI-фреймворков и возвращается к написанию кода на чистом JavaScript (речь идёт о модулях, или о том, что тот, кто работает с jQuery, назвал бы JS-плагинами). Я был удивлён и заинтригован.
Теперь о причинах подобного хода знают не только в EA, но и во всех остальных компаниях.
KISS, но без «тупиц»
Мне не нравится обзывать людей «тупицами», как это делается в названии принципа KISS («Keep It Simple, Stupid» — «Делай проще, тупица»). Поэтому я немного переделал предложение, лежащее в основе акронима KISS. У меня получилось «Keep It Stupid-Simple» — «Делай предельно просто». KISS — хорошая штука, но этот принцип в последних версиях Angular совершенно потерян. Angular — это уже не просто UI-фреймворк. Это теперь ещё и бэкенд-сервис. А значит — разработчикам Angular-интерфейсов, вдобавок к их основным задачам, приходится решать ещё и задачу написания серверного кода, которая выходит за рамки написания HTML-шаблонов. Кто-то может сказать, что это хорошо. Но, на самом деле, это не так.
Конечно, в Angular имеются кое-какие «замечательные» возможности, но все они совершенно не нужны для того чтобы создавать эффективные и привлекательные интерфейсы, или чтобы обеспечивать сайтам UX профессионального уровня.
Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
Конечно, эти проблемы можно обойти. Но в том-то всё и дело! У того, кто занимается разработкой интерфейсов, не должно возникать необходимости в написании кода для обхода особенностей используемых им инструментов, не соответствующих принципам работы веба!
Просто скажем «нет» UI-компиляторам
Ещё одна «мода», которая существует уже какое-то время, и которой тоже надо бы уйти в прошлое — это мода на Sass и LESS. Если говорить честно, то мне нравится тот подход к организации кода, который предлагают эти CSS-инструменты. А вот что мне в них не нравится — так это «миксины», и то, что этот код, перед использованием на сайтах, надо компилировать.
Если говорить об удобстве, то я не знаю о том, почему разработчики браузеров до сих пор не добавили в них поддержку SCSS в виде стандартного механизма для работы с CSS-кодом, но это — отдельная тема.
В итоге о псевдо-языках, имеющих отношение к CSS, можно сказать, что их применение, на самом деле, не приводит к экономии времени. Изучать и использовать их не легче, чем обычный CSS. И, в конечном счёте, реальным результатом их использования является генерирование качественного CSS-кода, чётко ориентированного на стилизацию определённых элементов, такого кода, который любой веб-разработчик, в любом случае, должен уметь писать самостоятельно.
Если кто-то хочет применять Sass или LESS, используя результаты их предварительной компиляции в своём окружении разработки, я не вижу в этом проблемы. Но полагаю, что мы никогда не должны сталкиваться с проникновением этих материалов в CI/CD-цепочки для их компиляции в ходе развёртывания проектов.
То же самое касается и любых других JavaScript-библиотек или фреймворков, код которых, в итоге, тоже компилируется в обычный JavaScript.
Каждый дополнительный шаг, добавленный в CI/CD-цепочку, просто засоряет и неоправданно удлиняет процесс развёртывания проекта, который должен быть очень простым и быстрым. И разработчикам стоит искать пути сокращения количества шагов в этом процессе, а не добавлять в него что-то новое только из-за того, что нечто вроде Jenkins это позволяет.
Angular «раздувает» код интерфейсов
Можете называть меня «интерфейсным пуристом», но то, что происходит сегодня в сфере программирования интерфейсов, нельзя называть «передовым ИТ-достижением». Это скорее результат применения некоей «кучи технологий». Я понимаю, что программистам в Google скучно, что им надо что-то делать, но Angular и подобные ему фреймворки лишь усложняют код пользовательских интерфейсов, разрушая его «природную» простоту.
Смысл тут в том, что для написания чистого и аккуратного UI-кода, для создания эффективного UX, не нужен фреймворк, под завязку набитый сомнительными возможностями. Для этих целей можно пользоваться любым движком для работы с шаблонами, предоставляемым бэкендом, и при этом не перегружать фронтенд невразумительным скомпилированным JS-кодом, практически не поддающимся отладке.
Компании тратят на Angular миллиарды долларов
Цель применения любого фреймворка заключается в том, чтобы упростить, а не усложнить программирование. Предполагается, что переход на некий фреймворк должен помочь компании сэкономить за счёт упрощения работы, а не становиться причиной новых затрат.
Но в реальности оказывается, что переход на Angular не приводит к экономии.
К сожалению, Angular, да и другие UI-фреймворки, стоят компаниям больших денег. В частности, речь идёт о постоянном обучении и переобучении персонала в условиях, когда, можно сказать, ежегодно, выходят новые версии фреймворка. Конечно, теперь разработчики Angular обещают, что все его новые версии будут обратно совместимы со старыми, но, опять же, речь идёт о добавлении чего-то нового к и без того перегруженному возможностями инструменту, когда для обеспечения работы очередного нового «просто замечательного» компонента всё снова придётся менять.
И — Бог вам в помощь, если вы — подрядчик, работающий с несколькими организациями, использующими разные UI-фреймворки. Вам нужно будет знать не только 12 разновидностей Angular, но ещё и разные версии Vue и React, так как какой-то новичок «подсадил» некую компанию на нечто подобное 4 года назад, а теперь ушёл оттуда, чем разрушил чей-то технологический стек.
Пришло время отправить Angular и другие подобные разработки на свалку неудавшихся экспериментов, где им и место.
Чем заменить Angular?
Ответ на вопрос, вынесенный в заголовок этого раздела, очень прост: Angular не надо ничем заменять. От него надо полностью избавиться. Его надо выбросить и написать вместо него простые, лёгкие в использовании и понятные JavaScript-модули (или плагины — называть их можно по-разному).
Я не являюсь противником использования опенсорсных библиотек вроде jQuery, или других UI-компонентов, или CSS-фреймворков вроде Bootstrap. Их можно «включить» в состав проекта, написав буквально пару строк кода. И они по-настоящему серьёзно упрощают жизнь разработчиков.
Но если фреймворку, вроде Tailwind, нужна для работы платформа Node.js, или если нужно учить и переучивать персонал из-за того, что разработчики фреймворка каждый год его переделывают, то всё это выливается в серьёзные затраты. И за что приходится платить? Лишь за то, чтобы пользоваться чем-то «сверхсовременным»?
Суть тут в том, что Angular засоряет рабочие процессы. Его применение обходится компаниям в тысячи, а может — и в десятки тысяч долларов. А если говорить о компаниях из списка Fortune 1000, то речь уже может идти о миллионах, которые каждый год тратятся на поддержку проектов, на обновления ПО, на обучение программистов. К этому добавляются затраты времени на поиск опытных программистов, или хотя бы тех, кто готов пойти на поддержку существующих монструозных проектов.
Когда я вижу, что компания отчаянно ищет UI-программистов, она неизменно нуждается в специалистах, обладающих 3-5 годами опыта разработки на Angular. Это — абсурд. Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик. При этом мне не придётся сталкиваться со всеми фронтенд- и бэкенд-сложностями, характерными для Angular.
Узкоспециализированные JavaScript-модули отлично подходят для разработки современных интерфейсов, позволяя достигать баланса между сложностью этих интерфейсов и элегантной простотой лежащей в их основе DOM.
Если в продакшн-варианте проекта, основанного на чистом JavaScript, что-то «поломается», на поиск проблемы уйдут буквально секунды, а пользоваться при этом можно инструментами разработчика любого браузера. Для решения проблемы не придётся устанавливать нечто лишь для того, чтобы получить возможность отлаживать скомпилированный код.
Итоги
Святой Грааль написания кода, любого кода, заключается в простоте. Но мы, современные программисты, совершенно потеряли это из виду. Нас захватывают новые сверкающие технологии, которые выпускают технологические гиганты, мы считаем правильным и современным то, что нам, как данность, предлагают в учебных заведениях.
Но Google или некий университет не будут платить зарплату программистам. Поэтому техническим директорам компаний пора перетряхнуть используемые в них технологические стеки, убрать из них всякие «модные» вещи и вернуться к рационально обоснованным пользовательским интерфейсам, к интерфейсам простым, поддерживаемым и привлекательно выглядящим.
Как вы относитесь к использованию UI-фреймворков в веб-разработке?
Комментарии (196)
Houston
03.08.2021 20:27+33Хотелось бы посмотреть на примеры прекрасных и богатых веб-приложений, не использующих никаких UI-фремворков...
dsrk_dev
03.08.2021 22:11-1GitHub?)
Houston
03.08.2021 23:14+2У них там из последнего Catalyst, это библиотека вполне себе уровня React, Angular, VUE и т.д.
https://github.blog/2021-05-04-how-we-use-web-components-at-github/
kirillplatonov
04.08.2021 09:45+2Не знаком с Catalyst, но он очень похож на Stimulus JS. А Stimulus я использую последние пару лет во всех проектах. Это реально очень простой и удобный микро-фреймворк для JS. Он работает поверх HTML, сгенерированного сервером. Позволяет легко добавлять интерактивность, при этом сохраняя основную бизнес логику-на бекенде.
Druu
06.08.2021 12:06Ну у гитхаба сам по себе как приложение предельно простой. А вот условную 1с-ку на жквери я бы глянул :)
Aketca
03.08.2021 20:52-20Ангулар помойка, согласен. Но есть легчайший vue и react, которые выпоняют строго отведенную роль, работа с ними не вызывает боль ниже спины. Просто поделка от гугл не нужна.
А вот отказаться от препроцессоров это большой шаг назад, тут не согласен
vanxant
03.08.2021 21:13+34Легчайший реакт? С хуками, редуксом и 50 копированиями всего на каждый чих? Лiл)
kalyukdo
03.08.2021 21:22+1реакт - шаблонизатор, именно так его нужно рассматривать, он прекрасно ложиться в MVC паттерн, если к нему прикрутить Mobx+ DI
sovaz1997
03.08.2021 21:37+9Почему если React, то сразу значит "+Redux"? Вовсе необязательно :)
YaroslavMik
04.08.2021 11:35Без Redux будет очень сложно следить и управлять State если проект становится большим. Раньше я тоже считал, что Redux не нужен но увы в крупных проектах он упрощает жизнь.
Sakhyanova
09.08.2021 11:58+2Без Redux будет очень сложно следить и управлять State
Не без Redux, а без глобального управления состоянием. Имхо MobX вполне себе альтернатива.
sovaz1997
27.08.2021 11:41+1Если проект становится большим, это вовсе не означает, что State Manager надо превращать в коробку для хранения всего. Есть глобальное состояние приложения (его много не бывает), есть локальное состояние. На MobX у вас есть возможность создавать нормальное локальное состояние без проблем. Хотя в последнее время я больше тяготею к хукам, у MobX есть свои плюсы. А вот для чего мне Redux тогда я не понимаю. Думаю, его используют в основном не потому, что он нужен, а потому, что "все используют". Карго-культ)
Aketca
03.08.2021 22:02В чем проблема хуков? Зачем копировать всё 50 раз? Даже если и так, это хуже ангулара?
vanxant
03.08.2021 22:16+5В чем проблема хуков?
В многочисленных подводных камнях, тормознутости и часто неочевидности
Зачем копировать всё 50 раз?
Не знаю, спросите у Абрамова и того, кто придумал идею flux/redux/*ux. Но с этой идеей любое нетривиальное действие, модифицирующее состояние, вызывает просто лавину обновлений и перерисовок.
Даже если и так, это хуже ангулара?
не знаю, имо оба хуже. Путь, предлагаемый в статье - рендерить всё руками - может потенциально и быстрее, но уж точно глючнее и трудоёмче. Vue и vue+jsx более-менее норм для мелких и средних проектов, но для крупных (10+ фронтовиков), вполне возможно, будет не очень.
beezy92
04.08.2021 09:02+1так Абрамов бомбит от всяких state'ов. он наоборот, пропагандирует использование чистого JavaScript в проектах, а React использовать только как библиотеку для работы над DOM
Alexandroppolus
03.08.2021 22:24+2В связке с MobX - таки легчайший. Хуки, если в меру, то вполне съедобны.
vanxant
03.08.2021 22:31+2Если хуков в меру, то норм.
Я видел, как норот пихает по сотне хуков в один компонент. Потому что за классы вчерашние джуны засмеют. Ну да, за классы с 50+ полей тоже, скорее всего, не погладят, теперь уже старшие, но там хотя бы очевидна необходимость дробить и рефакторить.
Alexandroppolus
03.08.2021 23:04Я видел, как норот пихает по сотне хуков в один компонент.
Да, проблема имеется. Точнее, две проблемы. Во первых, слишком большие компоненты (но, кстати, функциональные компоненты легко распиливаются, а конструкции из базовых элементарных хуков прячутся в кастомные хуки, и всё становится красиво). Во вторых, попытки реализовывать бизнес-логику в хуках (чему редукс весьма способствует). Тут уже сложнее, это отдельная песня.
Xuxicheta
03.08.2021 22:14+11реакт несомненно легчайший, только написать приложение на нем довольно проблематично. Нужно добавить в него еще кучу костылей, если все пройдет удачно и хорошо получишь что-то вроде своего Angular, на котором наконец можно писать. Если...
lrsvolk
04.08.2021 11:35+8А можно какую-то обоснованную критику ангулара-то? Пишу на нем уже года три, а тут оказывается его выбросить нужно. До этого писал на реакте и знаю его очень неплохо, а недавно делал тестовое на vue - и то, и другое тоже хорошо, но чтоб прям принципиально лучше ангуляра - даже близко не представляю о чем речь. Вернее, есть пару претензий к ангуляру, но, как правило, чтобы их назвать нужно очень глубоко знать фреймворк, и те, кто выдает такие комментарии, обычно ничего перечислить не могут
atomic1989
04.08.2021 15:10Тут многое зависит от того к каким проектам применяют то или иное решение. Сам занимаюсь разработкой крупного клиентского проекта. Я не могу представить как пришлось бы разрабатывать без всего того, что предлагает и рекомендует мир angular + mobx. Но в то же время даю себе отчёт, что в небольшом, да и в среднем проекте angular избыточен. 80% проектов являются таковыми. Отсюда и такой негатив в сторону angular.
pshhpshh
04.08.2021 17:07Так что за претензии-то? Интересно.
lrsvolk
04.08.2021 18:06+1Самая большая - сложность обучения, из-за которой многие негативно относятся к этой платформе:
Непрозрачность того, как работает cdr и zone [ну многие так говорят, хотя мне кажется, что это очевидные вещи какие-то]
Такие штуки, как DI и rx - это сложно, хотя я уже представить не могу, как без этих штуковин (паттернов) решать свои задачи настолько же изящно
Что еще за модули? Гарды и резолверы?! Пайпы?!!!! - я тута тока реакт-комопнент-писака, не понимац, надо тока компонент, остальное сложна (сорри, что упомянул реакт как будто в негативном ключе - это наоборот круто, что в реакте можно обходиться без лишних сущностей)
Наверно, что-то еще (и даже много), но я уже не могу сказать, что сложно, а что просто, надо спросить у тех, кто пробует войти в ангуляр
Как следствие популярность инструмента падает, сообщество растет медленно, меньше готовых решений. Кроме того сейчас многие перешли на "функциональную" парадигму, и вот есть такая либа как twilio -- в ООП она прям плохо вписывается, хотя это дико популярный инструмент для видео-аудио-звонков.
Остальное мелочи, к примеру:
Почему нет типов на ngOnChanges?
Почему нет типов на Provider?
Почему нет типов у FormControl?
Почему нельзя стилизовать диррективу?
Как мне пробросить аттрибуты на дочерний шаблон так же красиво, как во vue или react?
В качестве расширения комопнентов есть только наследование, а вот всякие крутые решения по типу composition api (vue) или hooks (react) -- отсуствуют;
В ssr нет возможности проставить custom-property (css);
pshhpshh
05.08.2021 11:54+1Насчет сложности обучения в целом, например, .Net фулстекам довольно легко вкатываться. Не знаю, по мне, так сложнее собирать конструктор с десятков либ, каждая со своим АПИ, чем через angular cli жахнуть ng new и получить очень многое «изкаробки».
«cdr и zone» — а вот тут согласен, по воспоминаниям, это занимает первые места по боли в работе с ангуляром, помню еще какие-то хаки писали в ончейндж везде.
«DI и rx» — не вызывало никаких проблем при изучении, но может, опять же из-за .Net бекграунда. Ну, rx-ом можно себе в ногу выстрелить, конечно, что-то сложнее банальщины читается оче тяжко, поэтому стрались не переусердствовать.
«надо спросить у тех, кто пробует войти в ангуляр»
Да, ну может еще тайпскрипт. Еще вспоминается, да, скудная база библиотек (ну в сравнении с первым ангуляром или того более просто жиквери).
И лично моя боль и вопрос, а что на счет не SPA? Помню, раньше это была проблема, как минимум из-за тяжелого инита. Да и в целом ангуляр себя позиционирует как SPA фреймворк. Сейчас с этим как?lrsvolk
05.08.2021 13:28angular 2 никогда не был встраевымым, ничего не изменилось к текущему моменту, и, мне кажется, никогда не изменится - из пушки по воробьям не стреляют) В кейсах, когда нужно что-то среднего объема поднять сам я использую vue.
А про бэкграунд с .net -- это, разумеется, хорошо подмечено. Многие разработчики с базой в виде c# или java легко вкатываются в этот фреймворк.
Sun_Day
09.08.2021 11:57-1"Непрозрачность того, как работает cdr"
"мне кажется, что это очевидные вещи какие-то"
Думаю вам это очевидно просто в силу того, что у вас не было желания/необходимости копнуть чуть глубже того, что написано в доке(достаточно общими словами, кстати).
"rx"
"изящно"
Выберите что-то одно.lrsvolk
09.08.2021 12:32Думаю вам это очевидно просто в силу того, что у вас не было желания/необходимости копнуть чуть глубже
Так я ж про публичный интерфейс говорю, понятно, что внутри сложная инкрементальная проверка через всякие побитовые сравнения. Да, на практики у меня необходимости в этом знании не было.
"rx""изящно"
Выберите что-то одно.
Ну тут уж дело практики, кмк. Ну либо можно пример того кода с rx, который написан приемлимо, и при этом, если переписать его без использования этой либы, он будет гораздо лучше?
Sun_Day
09.08.2021 15:20Так я ж про публичный интерфейс говорю
Как только встают какие-то небанальные задачи и нужно подумать о перформансе, то там далеко не всё так очевидно.lrsvolk
09.08.2021 16:00Можно пример такой "небанальной" задачи, ради которой мне нужно лезть разбираться в кишках ангуляра? А то, вот буду сидеть теперь и думать о том, какой же я банальный разработчик, банально решающий банальные задачи)
Кроме шуток, не пойму о чем идет дискуссия - я изначально сказал, что cdr и zone - это сложность фреймворка, мол, даже с публичным интерфейсом из 5 методов, надо поразбираться по началу.
Alexandroppolus
09.08.2021 13:27"rx""изящно"
Выберите что-то одно.
Там и в самом деле получается изящно, только с вывихом мозга для "не-ФП-шника", если кейс не совсем банальный.
Sun_Day
09.08.2021 15:30-1Работал в двух проектах, в одном rxjs тащили вообще везде, где только возможно. В другом использовали только на тех местах, где реактивность уже шла из ангуляра.
В первом случае, где все покрыто реактивностью - получился спагети код. Который абсолютно все читали с трудом.
Я быстрее прочитаю 100 строк ванильного жса, чем 20 строк всратого rxjs'a, десять свитч мапов, вложенных в пять мерж мапов, обёрнутых в комбайн латест, на асинк сабжектах. Rxjs делает плохой код хуже.
Имхо, если и тащить его в проект(а штука в принципе оч.полезная в некоторых ситуациях), то с серьезными ограничениями.
dshabalin
11.08.2021 11:17-1Три года разработки - не срок. Еще лет 10 и никто не вспомнит, что был такой Ангуляр. Умрет, как и многое другое, которое уже умерло. Проблема - как поддерживать все то, что на нем было сделано? Легче выбросить...
Flaksirus
03.08.2021 20:58+15Дичь какая, и вместо десятка популярных фреймворков с хорошей документацией мы получим свой велосипед с дырявой документацией и пачкой багов в каждой отдельной компании.
То есть, если было "
подрядчик, работающий с несколькими организациями, использующими разные UI-фреймворки", то теперь нужно знать разные велосипеды в каждой отдельной компании. Таким образом привлекая новых специалистов компания всегда будет тратить тысячи денег на то, чтобы новый специалист разобрался сначала с велосипедом и потом уже начнет пилить фичи.
raamid
03.08.2021 21:17+12Все равно поверх фреймворка будет велосипед и с ним нужно будет разбираться.
Flaksirus
04.08.2021 17:56+1Тем ангуляр и хорош, что он не библиотека и особо извратиться не позволяет. В любом случае фреймворк поверх будет не везде, а где будет, то будет на другом уровне абстракции.
mentin
03.08.2021 22:16+8По-моему мысль не в том, что делать свои фреймворки вместо популярных. А в том, чтобы не использовать и не строить никакие фреймворки (а angular себя называет даже не фреймворком, а платформой), а использовать и строить библиотеки (модули). Библиотеками пользуются по мере необходимости, фрейморк диктует тебе как жить.
intet
04.08.2021 12:34+6Одно из преимуществ angular для больших проектов в том, что он диктует как тебе жить. Новый разработчик приходя в проект сразу понимаем как проект устроен, а не тратить время узнать каким же 100500 способом в данном проекте объединили библиотеки.
Да это ограничивает функциональность, но и большой плюс от этого есть
syusifov
04.08.2021 14:48"больших проектов" - пример можно?
navferty
04.08.2021 18:23+1За популярные веб-ресурсы не буду говорить, но среди корпоративных решений такие встречаются нередко. И когда на фронтенде большое количество различных сложных компонентов: виджетов, графиков, табличек, админок и прочее, фреймворк, который ограничивает творческую свободу разработчиков, - это несомненное благо. И хотя я бэкендер, но будучи немного знаком со структурой нашего проекта на фронте, не могу себе представить, насколько сложнее стала бы разработка без ангуляра, и тем более без фреймворка вообще. Сейчас же новый человек может достаточно быстро погрузиться в проект и начать фигачить таски.
DreamShaded
10.08.2021 11:01Росбанк, мтс, альфа банк, тинькофф. Часть сервисов написана на ангуляре))
Вообще интересно, что скажет @obenjiro на это всё) хотя я догадываюсь
dshabalin
12.08.2021 01:13-1Лично наблюдал, как умирал проект на Angular 1. Проект начинал молодой мальчик с горящим взором "надо делать вот так, это сейчас самое модное с поддержкой от google". В итоге у мальчика огонек погас уже через год и он тихо слился. Развивать проект было некуда - производительность у Angular ниже плинтуса. Возможно, помогла бы миграция на Angular 2 (а потом 3? а потом 4?), но полная несовместимость версий и в итоге проект закрыли. Мораль сей басни такова - фреймфорк вам диктует не только как жить, но и когда умирать.
Xuxicheta
12.08.2021 16:12+1странно, а люди мигрируют и ничего
dshabalin
12.08.2021 20:03У людей есть бюджеты и много свободного времени...
Но вот скажите, в чем цель использования тяжелых вещей для фронтенда? Открываешь сбербанк онлайн и ждешь когда все это подгрузится.. 10 мегабайт, только чтобы увидеть состояние счета. Открываешь gmail и грузишь 20 мегабайт, только чтобы проверить свою почту. Товарищи, очнитесь. Зачем пользователям все это? Надо возвращаться к корням веба. А не то не только Angular придется выбросить, но и весь web. Как в Китае собственно уже и происходит (на хабре писали уже).
Kanut
13.08.2021 09:29Открываешь gmail и грузишь 20 мегабайт, только чтобы проверить свою почту. Товарищи, очнитесь. Зачем пользователям все это??
Ну например сейчас большинство пользователей хочет чтобы почта была с картинками и форматированием и чтобы линки в почте автоматом открывались в браузере и чтобы редактор был WYSIWYG и так далее и тому подобное.
И я посмотрю как вы всё это будете реализовывать и тем более поддерживать на технологиях из времён «корней веба».dshabalin
13.08.2021 19:11-1А что пользователи хотят от сбербанк онлайн? Смотреть анимацию по 10-15 секунд, пока там что-то подгружается / рендерится? Если умеете писать только такой код - заявление на стол и идите в другое место работать, там от вас будет меньше вреда. Такой результат работы - проф. непригодность. Тут и 5g не поможет с гигабитным интернетом. Главная страница https://angular.io/ - это 35 запросов в сеть и 3 мегабайта непонятно чего. И это просто страничка текста с несколькими картинками?
Kanut
13.08.2021 19:21+2Я без понятия что там пользователи хотят от сбербанка. Я ге их клиент и у них на странице даже ни разу в жизни и не был. Но даже если они там и накосячили, то это не отменяет того что на технологиях времён "корней веба" сейчас все желания клиентов не удовлетворить.
aronsky
09.08.2021 12:02+1Ну, типа контора использует Angular 10 и им сложно найти разработчиков. Давайте не будем использвоать ничего, в итоге программисты родят своё подобие фреймворка чтоб как-то организовать код, но мы будем искать теперь не Angular 10 разраба, а просто JS. Их же больше.
Отличный план. Надёжный как швейцарские часы, если я правильно понял.
LborV
03.08.2021 21:46-16Я поддерживаю это мнение частично уже более 2 лет. Правда я считаю оправдным использование каких-то либ/фреймворках в фронте и поэтому потихоньку развиваю свой фреймворк(https://github.com/LborV/js-mvca), у меня тут частичная предварительная компиляция шаблона в json - а фронт подставит переменные и сам всё сгенерит. Плюс всё сокет орентировано, вообщем, ангуляр ненавистникам рекомендую глянуть) доки у меня просто ужасные, даже не пытайтесь там что-то понять
aronsky
09.08.2021 12:03+5Хм, один майнтейнер, ужасные доки, отсутсвие описания конкурентных преимуществ, демо на домене xyz и не загружается? Беру, дайте 2.
pfffffffffffff
03.08.2021 22:07+6Может автор не пробовал vuejs
j_herasymchuk
12.08.2021 11:45Автор писал о Angular как пример, но писал и о Vue и о React.
"все в помойку" - давайте динозавра писатьВам нужно будет знать не только 12 разновидностей Angular, но ещё и разные версии Vue и React, так как какой-то новичок «подсадил» некую компанию на нечто подобное 4 года назад, а теперь ушёл оттуда, чем разрушил чей-то технологический стек.Пришло время отправить Angular и другие подобные разработки на свалку неудавшихся экспериментов, где им и место.
Alexandroppolus
03.08.2021 22:27+9Но ведь было же когда-то без фреймворков. И всё равно получался запутанный лапшекод.
DmitryKazakov8
03.08.2021 23:21+12Хотел бы я посмотреть на код автора этой статьи… Все равно ему придется писать и механизм рендеринга в DOM, и механизм обновления данных патчами (т.к. переписывание innerHTML собьет listeners), и жизненный цикл компонентов (т.к. нужно где-то очищать listeners и timeouts), и механизм обработки пользовательских событий (
onclick="window.myFunc"не подойдет из-за засорения глобальной области видимости и недоступности локального контекста данных), и экстракт состояния, отрендеренного на сервере, из разметки, и много чего еще. Не собирается же он бэкендовым twig рендерить модалки, графики, селекты, валидации форм и т.п., чтобы при каждом клике на элемент страница перезагружалась?Насчет недостатков Angular я скорее согласен с его ломающими обновлениями и обилием встроенных библиотек, но про "другие модные библиотеки" он так зря.
"Святой Грааль написания кода, любого кода, заключается в простоте" — тут как раз если ты знаком с фреймворком, то при переходе в новый проект очень быстро можешь разобраться и начать писать код. В общем, выглядит, как жалобы верстальщика лендингов с каруселями на jQuery, который посмотрел на серьезные проекты и подумал — нет, я слишком стар для такого, лучше буду хейтить все подряд.
s1im
04.08.2021 10:26+3А можно подробнее про "ломающие обновления"? Какие-то примеры из личного опыта?
Просто по моим наблюдениям (а я работаю с Angular со времен 2rc.1), авторы фреймворка очень много внимания уделяют тому, чтобы выход новой версии не начинался с трудностей по обновлению вашего проекта. Допустим, команда решает избавиться от одной библиотеки и заменить ее другой (или та же библиотека, но в более старшей несовместимой с текущей версии). В текущей версии Angular N никаких "хотфиксов" не происходит. В версии Angular N+1 заменяемая библиотека помечается как deprecated, ее использование по прежнему возможно, но посредством deprecation warning рекомендуется использование новой. И только в версии Angular N+2 старую библиотеку выпиливают окончательно. При подбном подходе и не игнорирования предупреждений, обновлений версии происходит абсолютно безболезнено с помощью одной лишь
ng updateDmitryKazakov8
04.08.2021 12:39-1"Я сам не слышал, но мне так сказали". Я работал только с первым ангуляром, про ломающие обновления слышал от коллег, поэтому аргументированно не смогу ответить.
blizzzard
11.08.2021 18:22Ну то что всё ломается через одну версию, а не на следующей какбэ не значит, что не ломается)
Я просто приведу более жизненный пример, на который сам напарывался, и скорее всего на нем покушали другие люди:
Бывает приходишь на проект, там SPA на втором ангуляре (к примеру, было и на других продуктах, у меня на PHP вот). Бизнесу нужны фичи, которые без боли можно зарелизить на Angular 10. И ты понимаешь, что там столько всего поменялось, что дешевле либо переписать всё заново, либо пилить фичи на Angular 2. Но уж точно не апдейтить до 10 версии.
И никакие "deprecation warning" тут не помогают, к сожалению.
Metotron0
03.08.2021 22:40+9Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS
А если это несколько разделов с разными меню, графиками, фильтрами, взаимозависимыми селектами, автодополнениями? Так и получится в итоге свой фреймворк.
Мне кажется, угол наклона графика сложности (от размера проекта) у "написать на чистом JS" положительный, а у "написать на готовом фреймворке" — отрицательный. И после некоторого значения второе становится выгоднее первого.
marshinov
03.08.2021 23:14+5Ага, а еще были люди, которые говорили, что "мы на ASM'е все гораздо лучше напишем". Смысл фреймворка не писать 100500-ый раз гребаную форму аутентификации, гарды, валидацию и вот это вот все. За бесконечное время я на любом языке напишу "аккуратный великолепный, быстрейший, красивейший интерфейс",... но зачем и кто за это мне заплатит?
k12th
03.08.2021 23:29+18Черт, зашел почитать обоснованную критику ангуляра, а внутри "scss это неудобно"...
DreamShaded
10.08.2021 11:05Вот-вот)) а ещё я бы поспорил, что он быстрее напишет понятный и масштабируемый интерфейс
yerzintimur
04.08.2021 00:25+11В частности, речь идёт о постоянном обучении и переобучении персонала в условиях, когда, можно сказать, ежегодно, выходят новые версии фреймворка
Каждый раз обновляя ОС, я с нуля учусь пользоваться компьютером.
Статья полностью под эмоциями, никаких конкретных предложений или причин автор не написал
claimc
04.08.2021 00:41Несколько лет назад я для интереса прошел обучение на freecodecamp, и два отдельных курса там были посвящены написанию одного проекта на Angular2, и второго на React. Я прошел их полностью, Мой субъективный вердикт для ангуляра сформировался очень быстро и бесповоротно - тупиковый проект, и работа с ним - потеря времени и денег. Через годы выяснилось, что они не имеют обратной совместимости от версии к версии, что напрямую свидетельствует о проблемах на архитектурном уровне. Реакт же, реализует простую идею виртуального DOM, которая при правильном подходе дает новый уровень простоты в разработке UI. Ничего подобного я не видел за годы работы со spring, Qt, msvs, и даже борладовких дельфи и с++, каждые из которых я любил.
urvanov
04.08.2021 00:57+8Мне кажется, основная проблема в том, что мы сейчас используем HTML и Javascript не для того, для чего они создавались первоначально. Отсюда и переусложнённость всех UI-фреймворков. Что с этим делать, раз уж уже так получилось, я даже не знаю, если честно.
RH215
04.08.2021 01:10+2Есть попытки в виде webasm, рисовании на canvas и прочего. Но получается пока средне.
DarthVictor
04.08.2021 01:04+19Крутой мужик.
У него в блоге целых четыре статьи, и какие!
Последнюю однозначно стоит прочитать, ведь он — автор Tiger Platform.
P.S. Да, я в курсе, что сарказм — низшая форма юмора.
mSnus
04.08.2021 02:18+11Фреймворки, валидация, гарды.. хуже приложений, чем Фейсбуковских -- ещё поискать! Глючнейший Инстаграм, который никак не научится считать количество уведомлений или нормально резать видео, кошмарный сам по себе Фейсбук -- так чего удивляться, что та же компания 10 лет пилит фреймворк и делает в результате какого-то монстра? И как ожидать от них хорошего во фронте?
Программисты Google? Можно, в бекэнд они умеют, Golang прекрасен. Но во фронте -- да посмотрите на Gmail, или зайдите на Page Speed Insights, или Google Console -- это всё глючит, откровенно плохо сверстано по принципу "и так сойдет". Ну и тоже 10 лет пилят... Как ожидать от них чего-то хорошего во фронте?
Причем мало того, что нынче все увешано этими фреймворками там, где без них прекрасно можно было бы обойтись, так ещё и всё, что во типовой фреймворк не входит, люди писать разучились.
Открываю сегодня форму ввода телефона на сайте, вернее, SPA ВТБ Транспорт - всё модно, современно, молодёжно. Вставляю туда номер +7925xxxxx-- получаю +77925xxxx, с лишней семёркой. Гениально. Матерюсь, стираю, ввожу с девятки руками -- получаю +79925хххх, с лишней девяткой. Зато все красиво подсвечивается, что телефон должен быть в правильном формате.
То есть стандартнейшая задача, форма входа с логином - телефонным номером. Но, видимо, фреймворк настолько отвлекает от написания собственного логики, что на эту основную и простую задачу сил уже не хватило.
Так что прав автор, ой как прав.
P.S. Дальше там у них в пароле нельзя использовать символы вроде $ или _ (не шел, как другие символы). Видимо, базовый валидатор не позволяет, а настраивать его -- лезть в кишки фреймворка или писать что-то своё, слоооожно. Мне кажется, никакой jQuery так людей не испортил..
AlexSpaizNet
04.08.2021 09:35Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.denisshabr
04.08.2021 10:40+9Звучит как оправдание собственной и корпоративной глупости. Если что-то сделано глючно - это пользователю наплевать на ваши эстимейшены и десяток менеджеров с MBA, он просто обматерит или уйдёт.
mrk-andreev
04.08.2021 18:36-3У всех багов есть severity и исходя из него они идут в спринт. В случае большого приложения количество багов начинает превышать ёмкость спринта (количество рабочий часов разработчиков) и начинает расти бэклог. Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
Если вам кажется, что разработчик может дополнительно поработать часок, то это только немного увеличит ёмкость и не решит проблему нехватки ресурсов.
Таким образом не критичные баги могут висеть годами.
daggert
05.08.2021 01:35+1Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
эээ... вы это надеюсь сейчас пошутили?
vanxant
05.08.2021 02:28+2Добро пожаловать в мир победившего управления качеством!
Не качества, а именно управления.
В математическом пределе у нас есть затраты на устранения дефекта стоимостью dLoss денег и потенциальные доходы от его устранения dGain. Если dLoss >= dGain , то устранять дефект тупо невыгодно.
На оперативном уровне (PM / лид) берётся 2-3 шкалы, допустим:
количество затронутых пользователей: единицы - мало - много - почти все
серьёзность бага: некрасиво - некомфортно (есть обходные пути) - отказ отдельных функций - порча данных - проблемы безопасности - отказ всей системы
и/или же срочность исправления: подождёт - срочно - надо вчера - ОГОНЬ
и по ним строится квадрат/куб/гиперкуб решений. Т.е. если отказ всей системы для всех пользователей это ОГОНЬ и чиним немедленно, выдирая кодеров из кроватей. А если кому-то там неважному в количестве трёх человек придётся сделать пару лишних кликов мышкой, то откладываем до рефакторинга.
Ну и модные гибкие методологии, скрамный аджайл, вот это всё. Ну, когда менеджер проекта официально самоустранился, разрабы снежинки, плывём по течению к ближайшему раунду финансирования. Если из-за бага никто важный не пришёл и не наорал, никто из разрабов случайно не починил, и прошло скажем 5 спринтов - баг закрывается как неважный:)
AlexSpaizNet
05.08.2021 13:17+2Как будто это что-то плохое.
Ну давайте делать вотерфолл... когда лет через 5 будет готова спецификация, вдруг окажется что оно уже и не актуально... или же конкуренты вышли на рынок раньше. Это бизнес в конце концов.
Мы должны смириться с тем что увы, никто не знает как писать код или создавать бизнес с нуля правильно, без багов, и что бы подходил всем. Это так не работает. Слишком много unknowns.
Бизнес это управление рисками и с одной лишь целью - заработать денег. Поэтому если бизнесу выгодно что-то, ему как бы все равно нравится ли это программисту/отдельному клиенту или нет.
И в этом примере, если бизнесу выгоднее что-бы какой-то условный индус с суппорта потратил час чтобы исправить вручную какую-то конкретную проблема конкретного человека чем тратить час работы программиста на баг, который приходит раз в год - то со стороны бизнеса это правильное решение.
mrk-andreev
05.08.2021 09:56Закрываются они не сразу, а спустя некоторое время. Эту практику можно увидеть в GitLabOrg (пример: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/211).
AlexSpaizNet
05.08.2021 13:02+1Я не знаю в каких компаниях вы работали, но так работает бизнес. Там другие метрики, риски и т.д.
Компания физически не может вот взять и все починить. Я не знаю если вы программист, но по вашей логике, глядя на бэклог багов MySQL, все должны тут-же плюнуть и отказаться от нее... а то глючная штука.
https://bugs.mysql.com/search.php?search_for=&status=Open&severity=all&limit=All&order_by=&cmd=display&direction=ASC&os=0&phpver=&bug_age=0
Жизнь она немного сложнее. Сделать можно все. Это лишь вопрос времени и денег.vanxant
05.08.2021 16:08+1Гг, там есть баги 2004 года под NT4 (которая уже тогда была устаревшей). Вот уж где автозакрытие по времени не помешало бы.
daggert
05.08.2021 16:47К счастью я работал в конторах где любые баги обязаны были закрывать, включая такие мелкие где надо поправить пару символов, на какие хабр забивает болтом уже кучу времени.
blizzzard
15.08.2021 10:49Ну вроде успешность "контор" измеряется не соотношением закрытых багов к открытым))
А если серьезно, то есть такая вещь, как приоритет, например. Одним компаниям важнее держать продукт в стабильном состоянии, а другим пилить фичи. И я бы не стал выделять какой-то один подход как точно правильный.
HellWalk
04.08.2021 10:43+5В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
Нет, не понимаю, и понимать не собираюсь.
Если я, как клиент, захожу на сайт пафосной организации, то я, как клиент, и оцениваю компанию по её сайту. И если вижу, что все тормозит и глючит - составляю соответствующее мнение о компании.
И мне плевать, что у компании "другие приоритетные задачи", "проблема висит в бэклоге" и прочее.
AlexSpaizNet
05.08.2021 12:56+2Еще раз. Если компания может позволить потерять вас из-за этих багов, то все нормально. Это бизнес и ничего более. Скорее всего есть баги из-за которых компания рискует потерять больше, и они в приоритете.
У вас всегда есть выбор перейти к другой компании где все программисты пишут продукт без багов...
insecto
05.08.2021 22:44Вы так говорите, будто компании не плевать на то что вы думаете когда заходите на её сайт.
mSnus
04.08.2021 12:52Понимаю, но вы пишете про то, что ошибки исправлять никто не хочет. А я про то, почему они вообще возникают.
Фреймворки не просто помогают, они изолируют программиста от решения многих задач. Дописать две строчки на JS, проверяющие, начинается ли ввод с + или с 9 -- не проблема, проблема в том, что переключаться на чистый JS не хочется, неуютно это.
dimka11
09.08.2021 18:30Со вставкой - проблема повсеместно, и не только в веб, но и в мобильных приложениях
kashey
04.08.2021 05:37+2По мере взросления человеку требуется поддержка. В начале это ходунки jQuery, потом костыли Angular.
Большинство перерастает этот этап и осознаёт что данная поддержка им более не нужна, и можно просто тяп ляп и в продакшен.
Меньшинство растёт дальше, до осознания: стандартов, требования бизнеса, в том числе к заменяемости сотрудников(опять же стандарты), или поддержке с прогнозируемым временем на внесение изменений и там или иначе приходит к четкой структуре, я бы даже сказал диктатуре, кода.
Хотя буду честен - в то время как Angular это именно диктатура структуры кода, чего очень не хватает рандомным React приложениям, многие основополагающие принципы, следуя которым эта диктатура может сделать «хорошо», товарищи проигнорировали.
JuniorNoobie
04.08.2021 07:43-1У меня нет страха или неприязни перед фреймворками. Но я очень боюсь их количества. Но и писать все на чистом JS - тоже не выход, ведь это все разовьется в повторяемый код, а далее логично перетечет и в библиотеку. Только ты ее будешь знать хорошо, как ее автор. А когда поделишься ей со своими знакомыми или выложишь в общий доступ - получишь фреймворк. Еще один.
Думаю, что это должно решаться на уровне выбора средств разработки архитектором. Но не проекта, а всей компании разработчиков. Не знаю, как там это называется, что-то типа технического директора что ли. Выбрать какой-то стек и скрестить пальцы, чтобы он развивался в нужном вам направлении. Так себе лотерея, конечно.
nick1612
04.08.2021 08:08-10Мне кажется, что в сложившейся ситуации, немалую роль сыграла попытка следования всяким надуманным принципам типа SOLID,TDD,BDD и т.п, которые пропагандирует Боб Мартин и компания инфоцыган от программирования. В итоге вполне конкретные задачи, которые можно решить в несколько строчек кода, разрастаются в раковую опухоль, так как простое решение типа не соответствует "принципу".
F0iL
04.08.2021 10:46+3Перечитав ваш комментарий, у меня возникло сомнение, что вы вообще понимаете, что такое SOLID и TDD и для чего оно нужно.
nick1612
04.08.2021 11:22-6Вы правы, признаюсь, что лет 5 назад я окончательно перестал понимать, что такое SOLID и TDD и главное зачем это кому-то нужно кроме самого Роберта Мартина, который зарабатывает на этом деньги.
F0iL
04.08.2021 11:59+3Это странно и печально. Впрочем, это еще зависит от того, чем именно вы занимаетесь. Если вы клепаете лендинги, хеллоуворлды и всякий write-only код (часто встречается в научной сфере, например), то да, это просто не ваш случай, проходите мимо.
А нужно это тем, кто пишет сколь-менее сложный софт на объектно-ориентированных языках программирования. Именно для того, чтобы избежать упомянутой вами проблемы -- чтобы при расширении новым функционалом и внесении изменений в логику, код оставался простым и понятным и НЕ разрастался в огромную раковую опухоль и изменения в одном месте не ломали код в другом. Плюс грамотное структурирование упрощает тестирование и улучшает читаемость кода другими разработчиками.
Принципы, составляющие SOLID, существовали еще за десятки лет до того как Мартин начал писать свои книги, и более того, практически любой опытный разработчик на ОО-языках обычно до доходит до этих подходов и начинает их использовать чисто интуитивно, даже если он знать не знаеть ни о каком "SOLID" :)
nick1612
04.08.2021 12:35-3Благодарю за развернутый ответ, но к сожалению вы и не угадали. Сильная неприязнь к этим принципам у меня появилась как раз после разработки достаточно крупных проектов. В самом начале, я так же читал и слушал всякие "умные" лекции о том как "правильно" писать код, про расширяемую архитектуру, модульность и тп. Это все хорошо звучит в теории, но на практике практически не работает (если у вас нет дара провидения). Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface. Привычка плодить горы классов и интерфейсов в угоду абстрактной расширяемости и тестируемости, приводит к тому что имеем - медленный, сложный и глючный софт. Не нужно решать проблему сферического коня в вакууме.
Alexandroppolus
04.08.2021 12:47+2Возможно, там позабыли про чувство меры и довели хорошую идею до абсурда.
F0iL
04.08.2021 12:55+2но на практике практически не работает
Слишком громкое и категоричное заявление.
Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface.
Совершенно верно. Никаким "принципам" нельзя следовать бездумно, у любых принципов есть границы их применения, и всегда нужно учитывать конкретные нюансы.
Не все фреймворки монструозные, а к монструозным фреймворкам приводят не сами принципы, а требования и цели, на которые ориентируются их авторы. Это примерно как Microsoft Excel, который содержит тысячу функций, обычному пользователю нужно не более 10% из них, но вот только эти из этих 10% половина необходимых функций у каждого пользователя разные.
При всем при этом, как здесь уже неоднократно замечали в комментариях, во многих случаях при отказе от фреймворков после определенного этапа в итоге в коде получается самодельная аналогичная, но гораздо более кривая и косая реализация чего-то похожего на какой-то из тех же фреймворков.абстрактной расширяемости и тестируемости
Угу. Но чтобы отказаться от расширяемости и тестируемости, вам нужно быть на сто процентов уверенным, в каком направлении и как будет развиваться проект через N, N*2, N*5 лет. Что тоже требует дара провидения.
медленный, сложный и глючный софт
Вот "медленный" в этом ряду вообще выглядит странно. В случае с 95% известных паттернов, единственный оверхед, который они могут дать, это несколько дополнительных вызовов через vtable (в зависимости от языка еще могут быть дополнительные аллокации, но это уже проблемы этих языков).
nick1612
04.08.2021 15:10-2Совершенно верно. Никаким "принципам" нельзя следовать бездумно, у любых принципов есть границы их применения, и всегда нужно учитывать конкретные нюансы.
Согласен, я об этом и говорил, что такие личности как Мартин и его адепты, пропагандируют оценку кода на соответствие каким-то надуманным принципам типа SOLID, в отрыве от контекста и задачи, которую он решает. К этому добавляются крики об обязательном 100% покрытии юнит тестами, которое приводит к необходимости реализаций абстракций для моков, там где они абсолютно не нужны. В итоге проекты серьезно страдают, только ради того, чтобы им не предъявили - "тут у вас нарушается принцип Single Responsibility, нужно разбить этот класс на 5 других а также использовать интерфейсы и DI".
Не все фреймворки монструозные, а к монструозным фреймворкам приводят не сами принципы, а требования и цели, на которые ориентируются их авторы.
В чем-то вы правы, часть монструозности фреймворком лежит в попытке реализации как можно большего объема функционала. Тут вопрос в самом концепте фреймворков.
При всем при этом, как здесь уже неоднократно замечали в комментариях, во многих случаях при отказе от фреймворков после определенного этапа в итоге в коде получается самодельная аналогичная, но гораздо более кривая и косая реализация чего-то похожего на какой-то из тех же фреймворков.
Не согласен, это стандартная страшилка для новичков - лучше сразу используй наш супер модный react,vue,angular и тп., иначе потом сам прийдеш к самописному фреймворку, только кривому. В этом есть доля правды, может ты и напишешь часть своего, но это будет только маленькая часть, которая решает конкретно твои задачи и не будешь никак зависеть от стороннего решения. Если нужно что-то изменить или оптимизировать, ты не должен городить костыли, править сторонний фрейворк и потом бояться обновлений. Тут все не так однозначно. Для всяких веб студий, которые клепают однотипные решения это ок, но брать фреймворк для собственного проекта глупо.
Угу. Но чтобы отказаться от расширяемости и тестируемости, вам нужно быть на сто процентов уверенным, в каком направлении и как будет развиваться проект через N, N*2, N*5 лет. Что тоже требует дара провидения.
В этом и состоит проблема, что никто не знает. Если ты не уверен, в каком направлении будет развиваться проект, то нужно действовать по обстоятельствам - добавлять функционал и рефакторить по мере изменения требований, а не лепить сходу горы абстракций, чтобы как говорят - "на будущее", "в дальнейшем было проще расширять". Не бывает идеальной архитектуры, которая магически расширяется и перестраивается под любые изменения требований, так что это больше вангование.
Вот "медленный" в этом ряду вообще выглядит странно. В случае с 95% известных паттернов, единственный оверхед, который они могут дать, это несколько дополнительных вызовов через vtable (в зависимости от языка еще могут быть дополнительные аллокации, но это уже проблемы этих языков).
Напомнило шутки про "zero cost abstractions" :)
TheShock
04.08.2021 16:14+1Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface
Современная "наука" в том же ЖС имеет функцию с такой же логикой, но при этом она должна быть названа по-хипстерски. Ну типа `it` или `mk`. То есть логика та же, но при этом оно называется абсолютно нечитабельно.
Вот как лично вы замените проброску зависимостей, когда будете писать код? Зависимости будут глобальные? Или иным способом?
gatoazul
04.08.2021 12:19+1Если ребенку дали молоток, то внезапно оказывается, что все вещи в доме нужно приколотить.
Так же и с этими принципами. Гуру (или их адепты - не знаю) как-то забывают, что все должно иметь определенную область применения.
mjr27
04.08.2021 08:22+7Любой достаточно сложный сайт на vanilla js содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины Angular.
Что ещё можно добавить?
anonymous
00.00.0000 00:00s1im
04.08.2021 09:28с минусом своей поддержки предыдущих версий
О каком минусе вы говорите, если со времен релиза Angular, структура компонентов не изменилась никак? То есть, вы сегодня можете взять стрый компонент, написанный во время выхода Angular 2 или 4 (при том что версий 1 и 3 попросту не было), и без изменения кода перенести его в Angular 12.
Более того, в моей практике был случай обновления проекта, завершенного под Angular 4 и который я без особых проблем перенес под Angular 11. Единственным большим breaking change как правило будет изменение библиотеки Http -> HttpClient.
А если вы говорите про AngularJS, то это нельзя считать первой версией текущего Angular, это по сути совершенно другой фреймворк со схожим названием.
s1im
04.08.2021 09:10+2Вам нужно будет знать не только 12 разновидностей Angular, но ещё и разные версии Vue и React, так как какой-то новичок «подсадил» некую компанию на нечто подобное 4 года назад, а теперь ушёл оттуда, чем разрушил чей-то технологический стек.
У меня складывается впечатление, что писавший данный пост человек - попросту некомпетентен и с Angular никогда не работал. Иначе, не писал бы про "12 разновидностей".
Если говорить об удобстве, то я не знаю о том, почему разработчики браузеров до сих пор не добавили в них поддержку SCSS в виде стандартного механизма для работы с CSS-кодомАга, конечно, давайте теперь вместо того чтобы делать сборку один раз перед выкладкой на продакшн, все переложим на клиента, они ведь всегда с очень быстрых машин заходят на ваши сайты.
Изучать и использовать их не легче, чем обычный CSS.
Так не изучай и не используй, в это разве проблема Angular? Он одинаково успешно работает как с css, так и с scss из коробки.
Я занимаюсь программированием более 20 лет. .... Ситуация здесь постоянно ухудшается.
Я конечно не настолько опытный, всего лишь 15 лет отдал индустрии, но как человек начинавший с верстки скругленных блоков под IE6, могу сказать, что наблюдаю строго противоположное.
Время SPA (Single Page Application, одностраничное приложение) прошло.
Так писать просто не прилично, не добавив ни одного пруф-линка.
Конечно, в Angular имеются кое-какие «замечательные» возможности, но все они совершенно не нужны для того чтобы создавать эффективные и привлекательные интерфейсы.
Вопрос привлекательности интерфейса ни коим образом не соотносится с задачами фреймворков, по типу Angular.
Я не являюсь противником использования опенсорсных библиотек вроде jQuery ... И они по-настоящему серьёзно упрощают жизнь разработчиков.
А как же принцип KISS? Неужили автор готов пойти на подобную сделку с совестью ради удобства виде
$('.my-class')противdocument.querySelectorAll('.my-class')?Продолжать можно долго, но если ты, читающий эти строки, не настолько опытный разработчик (как автор поста), проникся идеями прекрасного будущего без фреймворков и планируешь экономить своей фирме миллиарды долларов посредством
npm uninstall -g @angular/cli, то лучше поспрашивай других мнений по этому вопросу.
Kanut
04.08.2021 09:38+2Его надо выбросить и написать вместо него простые, лёгкие в использовании и понятные JavaScript-модули (или плагины — называть их можно по-разному)
То есть давайте выкинем один общий на всех Angular и потом каждый для себя напишет свою собственную версию? :)
alexkmbkdr1
04.08.2021 09:41-4Просто нужно нормальное ООП в разработке UI.
MyButton = New MyButton("Click me");s1im
04.08.2021 09:54+2И где появится эта кнопка? А если я хочу две иконки перед текстом, и чтобы одна появлялась после нажатия? А как мне задизейблить кнопку и добавить пару классов? Предлагаете делать так?
const MyButton = New MyButton("Click me"); MyButton.classList.add('class1'); MyButton.disabled = true; MyButton.click = () => { /* .... */ };Поздравляю, кажется, мы только что изобрели DOM-API
alexkmbkdr1
04.08.2021 10:24-1Контейнеры, группы элементов и т.д. Представление объектов UI в иерархической форме не исключает возможность использования ООП.
s1im
04.08.2021 10:38+2Проблема тут не в возможностях ООП, понятно, что написать оберток вида
class MyButton (){ ... }мы можем сколько угодно. Просто количество лапше-кода, даже для создания простой формочки с тремя кнопками, будет немыслимое. И эти полотна кода никогда не будет более читабельными, чем<button class="my-button">Click Me!</button>alexkmbkdr1
04.08.2021 15:54Ну например как сделано в QT для десктопных приложений. Очень удобно получается создавать GUI. И нет там никакой битвы фреймворков и никаких особых мучений.
vanxant
04.08.2021 14:16Ыгыгы, заднеконечники всегда с этого начинают:)
Тут вам и GWT, и Flutter, тысячи их, и это только от гугеля.
WinLin2
04.08.2021 10:23https://getbootstrap.com/docs/5.0/getting-started/javascript/
Still want to use jQuery? It’s possible!
Bootstrap 5 is designed to be used without jQuery, but it’s still possible to use our components with jQuery. If Bootstrap detects
jQueryin thewindowobject it’ll add all of our components in jQuery’s plugin system; this means you’ll be able to do$('[data-bs-toggle="tooltip"]').tooltip()to enable tooltips. The same goes for our other components.
RomanPokrovskij
09.08.2021 11:54Кстати какой-то олень в Bootstrap сломал поток исполнения js ради "гибкой поддержки". Раньше bs jquery компоенты цеплеялись/инициировались при загрузке, теперь после окончания загрузки страницы. "А потому что надо посмотреть если на 'body' флаг "используй или не используй jquery". Что поломало порядок инициирования, а в случае сложных компонент (моя компонента зависит от bs компоненты) всю аппликацию. При том что в среднем скрипты то все равно к концу страницы прелеплены и решение - хочешь смотреть атрибуты body не грузи скрипты в header очевидно.
О чем это говорит: 1) чужая голова потемки 2) jquery рассматривают как баласт.
HellWalk
04.08.2021 10:29Еще года три назад остро ощутил, что фронт идет куда-то не туда, и из фулл-стека перешел в чистый бек, чтобы в этом безумии не участвовать.
Приятно, что в сообществе приходит осознание этого факта.
P.S. Проблема не только в тяжелых фронт-фреймворках, а в том, что их теперь используют везде, даже там, где ничего особенного от фронта не нужно, и нормально справится обычный html и css
symbix
04.08.2021 10:57+4Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
Думаю, это предложение все объясняет. Да, если клепать сайтики, действительно, фреймворка для SPA не нужны. Автор явно никогда в своей жизни не разрабатывал сложные приложения, оттуда и непонимание, зачем «это всё».
А тащить фреймворки, предназначенные для сложных приложений, в сайтики, действительно, не стоит.
pavelsc
04.08.2021 11:21Забавный факт - проблема не во фреймворках, а в разработчиках. Многочисленные курсы учат их условно говоря правильно держать молоток и пилу, но не архитектурным основам. Дайте фронтендеру написать либу на ноде и вы увидите всю ущербность организации кода, когда фреймворк перестает диктовать организацию проекта.
SPA с роутером уже не SPA по определению. Если что я понял автора, ему не нравится объем бизнес-логики, подгруженной за раз, но я уверен что можно обойтись делением логики по поддоменам и использовать множество ангулар-аппов. Никто же не мешает делать profile.example.com/, analytics.example.com/.
Удивительно что ещё не было в статье выпада против typescript. Ведь хром не даёт бывает поставить брейкпойнт в нужную строку, что просто иногда бесит.
Во всей описываемой вакханалии беспокоит только одно - тебя могут не рассматривать на позицию сениор фуллстек даже если у тебя 10+ лет опыта и ты писал на ангуляр и Vue, но не писал на реакте на проект с реактом. Вот это вот действительно бред
derikn_mike
04.08.2021 11:34полностью согласен сейчас ангуляр или подобные суют в любые проекты нужно это или нет
caspermax
04.08.2021 11:34+2Автор, большое спасибо тебе! Наконец нашелся человек, который внятно описал весь тот срач который творится в разработке последние 10 лет.
Если 10 лет назад можно было написать сайт на коленке в блокноте и все это было довольно быстро. То теперь нам надо подготовить среду, поставить кучу frameworks, причем временами доходит до смешного.
Возьмите любой проект на nodejs сложности HelloWorld и получите более 10 000, а иногда и более 100 000 файлов. А ведь речь идет о том чтобы на выходе получить все лишь HTML!!!!
Иногда я скучаю за временами на Delphi 7 - накидал компонентов на формочку, прописал пару обработчиков и за 15 мин у вас работающая форма.kalyukdo
04.08.2021 11:55const http = require('http'); const hostname = '127.0.0.1'; const port = 3000; const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); res.end('Hello World'); }); server.listen(port, hostname, () => { console.log(`Server running at http://${hostname}:${port}/`); });caspermax
04.08.2021 12:22+1Речь не о том. На php вообще одна строка получается.
В данном случае речь о фреймоврках. Поставьте просто express - папка node_modules - 387 объектов. Это не много. Хуже начинается когда вы добавляете какой-то framework и накидываете еще модулей, которые тянут за собой зависимости.kalyukdo
04.08.2021 12:30+2сделайте тоже самое на пхп, поставе через компос какойнить yii или symfony и посмотрите сколько там будет файлов, не говоря уже о том что для запуска сервера на пап вам нужен сторонний модуль
caspermax
04.08.2021 12:48-1А я не говорю что там все гладко. Так что успокойтесь и не нервничайте. Мир, дружба, жвачка!
Речь о том куда мы вообще катимся.
Я считаю что все от человеческой лени + влияние денег: заказчику надо быстро, нет времени разбираться, и т.д. Все это в итоге вываливается с тонны неуправляемого кода, снижению скорости работы. О, ура, есть повод добавить кеширование!
Ну и т.д.
anonymous
00.00.0000 00:00s1im
04.08.2021 12:21+4Ой, я вас умоляю, во времена Delphi 7 было полно таких же нытиков, как автор поста, которые ругали библиотеку VCL за все то же самое, мол, формочка с кнопкой занимает 3Мб! Тогда как на чистом WinAPI можно сделать exe в 100кб. А лучше вообще на MASM32 все написать.
caspermax
04.08.2021 12:29Вот не надо, не 100Kb, было меньше - я помню.
Плюсом VLC было то, что на выходе у вас был 1 exe файл (ну может еще пара DLL - это кто как писал). Все компоненты были у вас под рукой и не надо было что-то тянуть из инета.
Вспомните недавно историю о том как один из авторов удалил из NPM свой пакет и в итоге сломал кучу приложений по всему миру. Уже точно не помню что за пакет был, но что-то безумно простое.
Вот в этом проблема - зависимости, много пакетов. Ну и как следствие - пакеты для пакетов, приложения для еще фиг знает чего. Это скорее смахивает на пузырь, который все ближе к моменту когда он лопнет.
Alendorff
05.08.2021 18:18Так ну и пишите сразу html если вам на выходе нужен html и не нужны вот эти все «сложности». Да, по старинке, открыть любимый блокнот и в нем написать. Кто ж вас заставляет все эти фреймворки использовать? :)
andrew_evseev
04.08.2021 11:34-2Возможно с angular могут возникнуть некоторые сложности в связи с необходимостью писать и бэк и фронт код, но в случае react все гораздо проще и удобней. В данном случае если сравнивать джуниор react разработчика (вместо angular) и джуниор который будет писать на чистом Js, я уверен что на react код будет написан за меньшее время и будет гораздо более простым в понимании для разработчиков(джунов и мидлов, а не сеньёров с 20 летним опытом). Также отдельный вопрос про сайты с десятками а то и сотнями страниц, как поддерживать такие проекты, по какому принципу из писать, какие паттерны использовать, и много других технических вопросов, нет никакого четкого пути построения для построения приложений. Также разработчиков пишущих на Js фреймворках сейчас найти достаточно просто, в данное время каждый второй фронтэнд разработчик пишет на Js фреймворках. А jQuery как по мне уже очень устарел и его надо забыть как страшный сон.
fdx
04.08.2021 11:34+2Выкинуть компиляторы? Вот те на! Ну давайте вернемся во времена так 2008 года, будем писать поделки на нативном js, это тоже своего рода ад. Спасибо не надо. И вообще написано больше на эмоциях чем приведены какие-то факты.
MherArsh
04.08.2021 11:34+2Давайте писать на ассемблере! А лучше на машинным коде! Это конечно сарказм, если серьезно то такие "инструменты" как Angular, не упрощают процесс разработки, они его усложняют, но их цель в стандартизации, в общем подходе, в использовании более строгих механизмов контроля типов и тд. По этой же логике зачем мы усложняем наш код разными паттернами проектирования?? Зачем мы следуем определённым принципам? По словам Роберта Мартина это упрощает поддержку проекта, что следовательно, снижает цену поддержки. Ещё обязательно надо помнить - каждая технология хороша там для чего она предназначена! Если проект лучше сделать на чистом js то делайте! А если вам подходит vaadin для рисования ui в java то берите его!
gans5131
04.08.2021 11:34Мне кажется мы слишком ударились в развитие фремворков, в то время как стоит развивать себя. Или можно сказать, что чем создавать для себя набор правил использования языка разработки (тот же фремворк), которые не позволят сделать "неправильный" шаг права или влево, уж лучше использовать эти ресурсы на совершенствование себя и самому знать куда и какой шаг сделать. А если коротко, то в целом я за библиотеки нежели за фреймворк.
BetsuNo
04.08.2021 11:34+2Автор предлагает отказаться от монструозных UI-фоеймворков а-ля angular, в пользу велосипедов на монструозных библиотеках а-ля jQuery.
Также решительно не понятно, чем автору не угодило то, что SCSS компилируется при деплое в CSS. При этом минификация его, судя по всему, не удивляет.
kotboriska
04.08.2021 11:34+1Такое ощущение, что у автора ностальгия по временам HTML 1.0 и CSS 1.
Очевидная ересь против CSS препроцессоров могла прийти в голову либо извращенцу-индусу, который любит много писать и переписывать руками, либо теоретику, который на практике CSS только в отладке браузера видел и не верстал даже среднего проекта с хорошими требованиями по совместимости.
Как я понимаю, typescript автор тоже не жалует? Тут без комментариев.
По поводу удлинения CI/CD цепочек: а вы в курсе, что это выполняется автоматически в считанные минуты у нормальных людей со всеми препроцесморами и фреймворками? Подозреваю, что автор из головы руками сборку проводит до сих пор.
Про ангуляр и фреймворки, кмк, автор, решив освоить ювелирку, взял слесарный молоток и теперь доносит нам, что молотки надо выкинуть, а гвозди можно и головой забивать. Конечно, если ты делаешь хороший лендинг - делай руками. А если тебе в 1 лицо надо за 2 недели админку сделать от которой плакать не хочется, как без ангуляра будете выкручиваться?
В общем, весьма спорные утверждения, хотя здравое зерно имеется местами.
rotarepo
04.08.2021 11:57Вдобавок, 90% "современных интерфейсов" на Джаваскрипте неудобнее и медленнее, чем простой разумный веб-интерфейс без всяких клиентских скриптов. А про глюкавость уже и не говорю. В общем, сколько Adobe Flash не убивай, идиоты будут его реинкарнировать.
stardust_kid
04.08.2021 13:52Очередное камлание адепта Церкви Отключения. Откажемся от Angular, отключим js в браузере, а потом и html с css. Откажемся от высокоуровневых языков, потом от низкоуровневых тоже. И воцарится рай нолей и единиц. На самом деле, конечно, оно так не работает. И подобные шлаковые статьи появляются регулярно с конца 90х.
rcepro
04.08.2021 15:08Наконец-то я дожил до этого момента...
Тут возможны 2 варианта:
1. Если автор - известный человек и с большой буквы то, ждём лет так эдак через 4-5
новости о том, что пора выкинуть QT и .NET на свалку.
Причины - всё те же. Вдобавок, легкоизвлекаемая нефть закончится к 2070-ым годам. Везде будет царить энергоэффективность и всеобщая экономия (сейчас уже есть). Так зачем делать за зря из компьютера - подобие утюга? Лишние ватты/киловатты энергии, которые тратит комп на обработку всей этой абстрагированной мишуры кода.
2. Если автор - не так известен - то, всё это канет в лету.
alexanderniki
05.08.2021 17:48+1QT
Чем вам QuickTime-то не угодил?)
Шучу) Речь, разумеется, идет о Qt и, мне кажется, некорректно сравнивать его с Angular.
Первое - большой фреймворк, написанный на C++ и содержащий средства для работы с ОС, сетью, тредами и пр. А также, что немаловажно, биндинги для других ЯП.
Второе - заточенный строго под GUI фрейворк, чтобы пилить формочки средствами тормозного DOM-а.
george3
04.08.2021 16:13-1Я пойду дальше автора и заявлю что вообще фронт-енд программинг - унылая шляпа (вот это все JS, HTML, CSS, зоопарк мутных фреймворков) и должно умереть во имя добра. Стараясь ускорить этот процесс придумал как вообще не прикаcаясь ко всему этому получать готовые фронты для всех девайсов/отображателей, программируя только на том языке, который нравится (вообщем любом). для data science/business апликух, где стандартного MD достаточно.
Написал на flutter (тоже гадость, но меньшего порядка) авто-фронт, юзаю для себя и своих заказчиков, и в общем доволен. Уверен, что подобная моей технология прибьет нафиг всю эту камарилью рано или поздно. А пока до этого не додумались монстры, я тихо сижу и радуюсь, что я вне этого безумия. ну почти так.
что придумал https://github.com/Claus1/unigui
vanxant
04.08.2021 22:20Скажу по-секрету, таких вот "универсальных конструкторов админок" для обсуждаемых в статье технологий, ну примерно дофига. Первая попавшаяся ссылка в гугле: тыц. В-основном, правда, от $15 и до десятков тыщ денег. Некоторые даже не такие унылые, как ваше поделие:)
Правда, иначе как для написания "админки для админов" такие конструкторы использовать нельзя. У обычных людей почему-то начинает идти кровь из нетренированных глаз, и они начинают делать ошибки на ровном месте. А ошибки админа это иногда дорого.
george3
05.08.2021 05:00-1вы не поняли о чем там. даже отдаленно. я придумал протокол, избавляющий от написания фронта. а унылость идет от MD, туда (в гугл) жаловаться и надо. а я поддержу.
vanxant
05.08.2021 15:32Среди конструкторов достаточно много таких, которые полностью управляются декларативно бэком. Т.е. конструктор на вход получает json с описанием где чего выводить.
george3
05.08.2021 16:43например,хоть один, чтобы сразу давал многопользовательский универсальный GUI и работал для всех языков, по крайней мере в теории?
Dmitriy_vles
06.08.2021 11:48Я 5 лет работаю с vue и react, недавно довелось поработать с angular 11. При изучении angular заметил что каждые 5-10 мин приходиться что-то смотреть в документацию так как на первый взгляд при интуитивной работе с JavaScript что-то не работало так как нужно было дело именно как angular требует. Странные ошибки которые появляются в консоле, а решение для них просто перезапустить angular cli - просто убивало меня, после 15-20 мин проверки кода который точно правильный, нужно запустить ng serve снова и все заработает. В react и vue хватает своей магии и там её относительно немного, и когда стреляет баг с производительностью то +- понимаешь сразу где беда и быстро исправляется, но в angular из за тонны абстракций, и без богатого опыта именно работы с angular а не JavaScript - это реально вызвало у меня боль.
noodles
07.08.2021 00:59+2Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
для создания эффективного UX, не нужен фреймворк, под завязку набитый сомнительными возможностями. Для этих целей можно пользоваться любым движком для работы с шаблонами, предоставляемым бэкендом
Судя по всему автор не разобрался, что SPA - это обычно приложения спрятанные за аутентификацией, и им эти поисковые боты и индексация вообще не нужны. Зато им как раз нужны вот эти фреймворки, чтобы реализовать эффективный и сложный интерфейс.
В то время как публичная часть продукта (ака сайт) делается как раз "любым движком для работы с шаблонами, предоставляемым бэкендом" с щепоткой jquery по вкусу.
ncix
09.08.2021 11:28Много лет делаю нишевые бизнес-приложения для нескольких постоянных заказчиков. Пока присматривался, а не перейти ли мне с чистого JS на какой-нибудь модный фреймворк, оно вон как повернулось. Пожалуй, не буду дергаться, подожду еще.
Axelaredz
09.08.2021 11:58Нормально относимся, если это https://getuikit.com :)
..в отличие от бутстрапа в котором есть и правда всё необходимое при таком же размере, но без странных решений
aronsky
09.08.2021 12:13+5Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик.
Знаем, проходили. Это тот же разраб, который:
"я не буду использовать фреймворки для php и напишу на плейне быстрее, чем вы все тут в офисе"
"я не буду использовать IDE и напишу код чище, чем любой из этих линтер-юзеров"
"все эти ваши митинги - это потеря времени, сами эстимируйте свои таски, я лучше в это время напишу код"
"я тут переписал велосипед заново и получил +5% к производительности вместо того, чтоб делать таск, но таск я сделаю ночью"
"да мои таски не надо ревьюить и тестить, я никогда не допускаю баги"
"у нас на 5 программистов 2 менеджера - раскормили дармоедов"
"на что они вообще тратят деньги, лучше бы программерам ЗП подняли"
Это тот же чувак, который потом:
"нет, заберите этих идиотов, я буду сам работать, не нужна мне команда",
а затем:
"нет, я не буду никого обучать и объяснять, что я там написал и как это теперь мейнтейнить, если вы можете себе позволить уволить такого крутого специалиста как я, то сами разбирайтесь".
mxms
09.08.2021 12:20Я говорю об этом уже второй десяток лет.
Безотносительно конкретного Angular, фреймворки (да и часть библиотек) это зло практически во всём, и хорошо бы 98% из них закопать и никогда больше не вспоминать.
Хороши они только в одном - быстром производстве тонн монструозного говнокода.
dcooder
09.08.2021 19:15+2Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
skand
09.08.2021 21:51Любой язык/фреймворк надо уметь грамотно использовать. В первую очередь то означает брать то, что надо и не брать то, что не надо. В C++ эту историю уже давно прошли, и, кстати, крайним способом борьбы со сложностью как раз предлагалось (а иногда и делалось) писать на чистом C.
Все эти беды от недостатка опыта или профессионализма. А в софтверной разработке профессионализм - это как раз НЕ использовать фичи только потому, что они есть, а использовать лишь то, что надо, понятно и можно адекватно сложности задачи в целом поддерживать.
На Angular удобно писать приложения, он навязывает определенную структуру и позволяет решить задачи в целом быстрее, чем без него. Но, как и любой нетривиальный инструмент, в кривых руках он может стать и бедой для всего проекта.
philpirj
10.08.2021 09:25+1"Пришло время избавиться от программистов максималистов и сэкономить миллиарды долларов".
speller
10.08.2021 10:20+1Есть подозрение, что автор не поддерживал большие кодовые базы, где переизобретены все возможные велосипеды. С колокольни своего опыта могу сказать, что чем меньше кода надо поддерживать самому (т.е. чем больше использовать готовое стороннее), тем больше отдельно взятый программист тратит на разработку бизнес задач. Как только проект обрастает хоть какой-то сложностью, уже требуется нанимать отдельного человека на поддержку кодовой базы или собственного фреймворка (даже если это "набор плагинов"). И автор как раз таки не раскрыл, для чего все используют фреймворки и КАК делать проекты без них в разумные сроки и со вменяемым качеством. Да, компании тратят миллиарды. Но не думал ли автор о том, что зарабатывают они ещё больше? А то знаю я эту логику "отдел рекламы зарабатывает деньги компании, а ИТ отдел только тратит". Если бы не ИТ отдел, то рекламщикам и продавать было нечего - у таких людей забывается.
wemonpf
10.08.2021 11:21+3Честно говоря, я совершенно не фронтендер, но мне крайне знакомо и понятно мнение, которое Вы изложили, среди разработчиков уставших от бесконечного хайпа новых технологий и наивному желанию новичков вписываться во всё без разбора. Да что там, я со своим опытом в 4 года сам подгораю, когда студенты аргументируют выбор технологии тем, что "сейчас это модно". Сейчас? А что будет через год? А техническое обоснование выбора, специфичное именно для наших нужда, а не нужд других корпораций?
Но. Надо учитывать и другую сторону вопроса. Даже не так, по-другому ставить вопрос. Вы описываете мир глазами разработчика, который выбирает технологию на перспективу, учитывая гибкость, масштабируемость, производительность, удобство разработки, в конце концов чувство уважения к самому себе от того, что пишешь код решающий задачи, а не борющийся с фреймворком... Но всё это лишь косвенно и не всегда может решать реальные проблемы бизнеса.
Чтобы не ходить вокруг, вот конкретика: можно взять задачу бизнеса по написанию модерируемого новостного портала, который сможет поддерживать Марина Викторовна, не умеющая ничего сложнее, чем сверстать текст в ричбоксе. Вполне реальная задача. И в тоже время компания не будет располагать ресурсами на то, чтобы делать разработку в фоновом режиме и/или длительное время. Вполне нормальная ситуация. Вы приходите к адекватному менеджеру и, как специалист, говорите: я могу сделать вам это на ангуляре за 5 дней на ворд-прессе за два дня, на реакте за две неделе, на html+css+jquery за полтора месяца. В ногу это нам выстрелит в первом случае через два года, во втором через год, в третьем только если вымрут все разработчики способные что-то делать, кроме как писать на ангуляре. И дальше менеджер взвешивает это исходя из условий и делает вывод, что решает проблемы бизнеса конкретно сейчас, и о будущем какой дальности он может позволить себе позаботиться. Стоит ли перед компанией задача в отклик по кнопке за 3 миллисекунды или можно и помедленнее и т.д. Решает он, а не Вы.
Вот так это должно работать. На этом коротком примере видно, что вопрос не решаем исходя только лишь из желания разработчика выбрать ту технологию, с которой потом будет проще/не понадобится слезать. Вы конечно можете и должны взвешивать потенциальные потери в будущем. Но если проблема блокирует бизнес, то к моменту когда разработчик подготовит идеальную и гибкую систему, фирма уже может перестать существовать. Тоже касается вопроса производительности/масштабируемости/кроссплатформенности и т.д. Если сейчас проблема не стоит, или оценивается как несущественная, то и не надо почём зря на её решение делать ставку, особенно если это не бесплатно, например, с точки зрения времени разработки/жертв удобством, читаемостью кода и т.д.
И второй пример уже из моей ниши, но, как мне показалось, очень похож на то, на что Вы делали ставку в этой статье: на заре языков с управляемой кучей (да и сейчас тоже, как видно из комментариев к статье, но реже) было расхоже мнение среди бородатых разработчиков, что эти языки -- насмешка над понятием программирования и нужны не более чем для новичков, а для реальной разработки не пригодны, так как GC даёт просто дикий оверхэд, жрёт ресурсы да ещё и требует установки виртуальной машины, что вообще ну ни в какие ворота, как же тогда на тостере дум запускать будем?
История показала, насколько такое мнение было некорректным. Но не в плане технической аргументации. С этой точки зрения вся критика справедлива. А вот если ставить вопрос снова на рельсы бизнеса, то всплывают сразу два момента: 1) если посмотреть на разработку любой крупной компании, использующую c++ то с большой вероятностью в исходном коде увидим аналоги того же CG самописной сборки. По очень простой причине: всё, что делается руками рано или поздно приводит к ошибкам. А в масштабах крупных компаний -- к регулярным ошибкам (просто по законам статистики) и, следовательно, к регулярным финансовым потерям. Из мне известных: ПО для фотокамер самсунга, где эти самые потери были в какой-то момент подсчитаны и задача по написанию GC была поставлена (другие примеры не копал, но наверняка подобное есть много где, например в тех же игровых движках). 2) Скорость написания кода, не требующего глубокого продумывания стратегии управления памятью, и ещё более глубокой отладки, зачастую критический для бизнеса фактор, а вот экономия каждого байта памяти, на которую указывали олдскулы, в условиях гигабатных серверных ОЗУ, в большинстве областей -- нет.
Какой из всего этого можно сделать вывод (к чему все эти примеры?). Ну я бы обобщил так:
1) Технический вопрос -- важен, но первичен вопрос бизнеса. Поймите важность решаемых проблем рассматриваемыми технологиями и выберите меньшее зло с точки зрения проблем приносимых. Ставка на будущее, может привести к тому, что до будущего можно и не дотянуть. Ставка на производительность может привести к тому, что производительную систему, в жертву которой была принесена поддерживаемость и порог входа, просто будет некому сопровождать. И т.д.
2) Крупные компании. Здесь важно чётко понимать: крупные компании ничем не отличаются от малых, в том смысле, что они также думают о своей прибыли и выживаемости, а не о прекрасном коде под своим капотом (см. например, на эту тему статью "Почему я ушёл из Google и начал работать на себя"), просто они могут позволить себе быть чуть менее зависимыми от сиюминутных решений, банально в силу того, что имеют запас жира, так что могут думать не только о проблемах сегодняшнего дня, но и о проблемах дня завтрашнего. Что я этим хотел сказать? Не думайте что EA отказываются от фреймворков потому что EA <3 JQuery и гибкость, ангуляр -- ошибка, просто осознать это могут только они, избранные компании. Нет. Реальная причина в том, что как и в любой другой FAANG-like компании, им нужен минимум внешних зависимостей, дабы минимизировать риски изменения лицензий/остановок поддержек и гарантировать решение фреймворками своих, а не чужих проблем. Не просто так тот же реакт возник не где-нибудь, а в фейсбуке. Другими словами ожидайте кастомый ангуляр/реакт ea-эдишн. Абсолютно стандартная практика, все компании таких масштабов пишут велосипеды, задача которых не приносить в грязный, неправильный мир мир хаоса единорогов наступившего будущего, а не более чем решать задачи компании. Разница только в том, что когда у тебя 100 команд разработчиков, ты можешь себе это позволить, а когда код пишут полтора инвалида, и не дай бог им начать инфраструктурный слой пилить, так вся работа встанет -- нет.
3) Ну и на последок хотелось бы лишний раз отметить негласную истину: задача нас, разработчиков, не в том, чтобы выискивать идеальные решения, или писать неповторимый код, находя точки J мастерским владением языком программирования, а прежде всего в том, чтобы решать проблемы, какими бы порой странными эти решения нам самим не казались. Выбор всегда должен быть взвешен и, желательно, не только техническими специалистами. А идеальные решения... Их просто не бывает, за всё приходится платить :)
integer2
10.08.2021 11:22Скоро можно будет отказаться от всего :) так как в релиз почти вышел Compose for Web/Desktop
https://compose-web.ui.pages.jetbrains.team/Так что не придется писать на чистом js
YuryB
10.08.2021 15:32+1наивность автора похоже не знает границ, не от хорошей жизни появился ангуляр
Beaend
12.08.2021 11:46Не могу назвать себя знатоком всей глубины этой темы.
И самому не нравится, что частенько случайно увиливаю в backend работая с ангуляром и т.п. пытаясь написать что-то простое, но в тайпскрипте, да ещё интегрировав для чтения данных всем остальным данным.
Но! Есть одно большое но, из-за которого я и начал пользоваться Ангуляром (сейчас, правда я почти всё делаю на Vue, но не суть) - это структуризация данных. Для меня очень удобно раскладывать на полочки css/scss, разбив их на уровни, темы и дизайны. Мне удобно, что я верстая страницу, могу не обращать внимание на код, который мне не нужен в данный момент (сайдбар, новости и т.п.) и от него лежит лишь "красивая" строчка подключения. Что мне не нужно генерировать шаблоны внутри JS кода. Что я могу спокойно (ну относительно) проследить какие страницы используют какой дизайн. И что кусок кода не мешается при всех прогрузках страницы, лишь раз и о нём забывается.
bskton
16.08.2021 09:04Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик
Вау! Звучит круто! Жаль автор не привел примеров своего кода в подтверждение этих слов :))
Static555
02.09.2021 19:10неплохо автор набросил ) видел эту статью в англоязычном интернете
у фронтэнда есть проблема - он не нужон. Большинство сейчас делает на своем Реакте просто интерактивную вьюшку. Такие вещи работали прекрасно и в "старом вебе" без фронтэндеров. Но если вы пойдете писать приложение, которое работает и выглядит именно как приложение, а не как сайтик, который "по модному" подгружает странички, вы поймете что Ангуляр, к сожалению, на сегодня - это единственное вменяемое решение
Хотя, он не дает вменяемого ответа на то, что делать с бизнес логикой, с той самой Моделью, но хотя бы слои инфраструктурной и прикладной логики, а так же вьюшки он обеспечивает
LabEG
Полностью поддерживаю ваше мнение. Но встает вопрос - Ангуляр дает паттерн в организации и структуирования кода. Какого паттерна построения приложения придерживаться без ангуляра?
Tiulkin
Это перевод, соответственно, не факт, что автор (точнее, переводчик) познал эту боль
pfffffffffffff
Mvc
s1im
Тяп-ляп и в продакшн!
chyngyz6
как говорит коллега: "хуяк хуяк и в продакшн!" :)
Spaceoddity
Паттерны ради паттернов? Ну и как бы никто не мешает использовать любую парадигму архитектуры, причем тут собственно реактивные фреймворки? Их надо юзать чтобы у тебя код был по паттерну построен?
Это как некоторое время назад все носились с БЭМом. А если мне вдруг не надо переиспользовать компоненты (как и в доброй половине проектов, требующих БЭМ) - зачем мне погружаться во всё это?
Desprit
Паттерна, которого придерживается коммьюнити Vue, где нет паттерна организации кода. Мне довелось поработать в нескольких проектах разного объема, написанных на Vue. Кто во что горазд. Поэтому, нет, спасибо, уж лучше Angular, пусть сам по себе Vue я и очень люблю.
Автор говорит о Fortune 1000, но нет ни одного примера по-настоящему крупного проекта, написанного без фреймворка и при этом не превратившегося в неподдерживаемую лапшу.
Aetae
Лучше ли? Согласен что от проекта к проекту на Vue встречается всякое самое разное, но, как по мне, работать с этим всё равно стократ приятнее.)
Aleksei_Segodin
Но «лапша» — это нормальная эволюция любого большого проекта. Так как на самой ранней стадии нельзя предвидеть то, как будет меняться бизнес и каким он будет через 5 лет. «По дороге» в бизнесе всегда меняются приоритеты, появляются/закрываются разные направления и сферы деятельности и т.д. С этим нужно смириться. Что есть — то есть. Это мир в котором мы живём.
То есть у вас есть выбор: с одной стороны свой кастомный паттерн, так сказать, гибкая архитектура или сдругой — Ангуляр с его высеченным в камне на веки паттерном. Что выберете в долгосрочной перспективе?
И вообще-то здесь есть одно «но». Именно потому что мир меняется и требования к проектам у всех разные, Ангуляр тоже пытается адаптироваться выпуская новые версии фреймворка. Для нас очевидно, разработчики разного софта выпускают новые версии. Но сам тот факт, что выходят новые версии Ангуляра говорит о том, что он не идеален. Потому что если бы паттерны Ангуляра изначально были бы «идеалными» и подходили бы всем, то не было бы и новых версий. Замкнутный круг. Но это мир в котором мы живём...
evgeniyPP
"Лапша" – это не нормальная эволюция, а одна из следующих причин:
У программистов было мало времени
У программистов было мало опыта в написании масштабируемого кода
Что касается паттернов, то тут понятно, что
водка лучше самогонаобщепринятое решение всегда лучше своего велосипеда.А то, что Angular неидеальный, – это очевидно, хотя бы по 1,7k issue на GitHub
Aleksei_Segodin
Сгласен с пунктами 1 и 2. Но в том и дело, что у программистов всегда мало времени и команды программистов не состоят на 100% из идеальных работников :)
На практике никто никогда не позволит программистам условно целый год ваять какое-то супер-масштабируемое «произведение искусства», которое оценит каждый программист и похлопает по плечу. Владелец бизнеса по плечу не похлопает. Всегда есть бюджет, сроки и т.п. Поэтому и видим время от времени решения на скорую руку, хардкод и прочее, то что любой опытный программист понимает как некачественный код, но «так и быть, сделаем рефакторинг позже». А потом уходит из компании/проекта.
Мы живём не в видеальном мире. У вас в команде из 5 программистов никогда не будет 5 программистов-суперменов, где каждый на 100% освоил синтаксис, мыслит на 100% абстрактно и пишет на 100% масштабирумый код. В конце концов, всем свойственно делать ошибки будь то сознательно (см. пункт 1) или бессознательно.
P.S. Не путайте фразу «нормальная эволюция» с понятием «так и должно быть». Лапша — это плохо и так не должно быть.
HellWalk
Разве jQuery это фреймворк? Вроде как это библиотека.
Mihaelc
Библиотека, как и React
JordanoBruno
Это где GitHub использует React и jQuery? Насколько я вижу, ничего этого у них сейчас нет на сайте, а для UI они самописное используют - https://www.npmjs.com/package/@primer/css .
edward_gray
Можно ссылки?
Пару-тройку UI - это уже роскошно.
От jQuery, вроде, официально отказались с 2018.
Ссылки ниже
https://github.blog/2018-09-06-removing-jquery-from-github-frontend/https://habr.com/ru/post/418257/Aleksei_Segodin
Придерживайтесь паттерна здравого смысла. Планируйте проект и его архитектуру заранее на сколько позволяет ситуация. Ну а потом по старинке: HTML / CSS / JS. Сам так делаю — всё хорошо работает и поддерживается.
Нет ничего страшного в отстутсвии фреймворка. Автор прав насчёт скорости — она не такая уж низкая, тем более, с современной браузерной поддержкой новых «плюшек» в HTML, CCS и JS.