Comments 196
Полностью поддерживаю ваше мнение. Но встает вопрос - Ангуляр дает паттерн в организации и структуирования кода. Какого паттерна построения приложения придерживаться без ангуляра?
Это перевод, соответственно, не факт, что автор (точнее, переводчик) познал эту боль
Mvc
Тяп-ляп и в продакшн!
Паттерны ради паттернов? Ну и как бы никто не мешает использовать любую парадигму архитектуры, причем тут собственно реактивные фреймворки? Их надо юзать чтобы у тебя код был по паттерну построен?
Это как некоторое время назад все носились с БЭМом. А если мне вдруг не надо переиспользовать компоненты (как и в доброй половине проектов, требующих БЭМ) - зачем мне погружаться во всё это?
Паттерна, которого придерживается коммьюнити Vue, где нет паттерна организации кода. Мне довелось поработать в нескольких проектах разного объема, написанных на Vue. Кто во что горазд. Поэтому, нет, спасибо, уж лучше Angular, пусть сам по себе Vue я и очень люблю.
Автор говорит о Fortune 1000, но нет ни одного примера по-настоящему крупного проекта, написанного без фреймворка и при этом не превратившегося в неподдерживаемую лапшу.
Но «лапша» — это нормальная эволюция любого большого проекта. Так как на самой ранней стадии нельзя предвидеть то, как будет меняться бизнес и каким он будет через 5 лет. «По дороге» в бизнесе всегда меняются приоритеты, появляются/закрываются разные направления и сферы деятельности и т.д. С этим нужно смириться. Что есть — то есть. Это мир в котором мы живём.
То есть у вас есть выбор: с одной стороны свой кастомный паттерн, так сказать, гибкая архитектура или сдругой — Ангуляр с его высеченным в камне на веки паттерном. Что выберете в долгосрочной перспективе?
И вообще-то здесь есть одно «но». Именно потому что мир меняется и требования к проектам у всех разные, Ангуляр тоже пытается адаптироваться выпуская новые версии фреймворка. Для нас очевидно, разработчики разного софта выпускают новые версии. Но сам тот факт, что выходят новые версии Ангуляра говорит о том, что он не идеален. Потому что если бы паттерны Ангуляра изначально были бы «идеалными» и подходили бы всем, то не было бы и новых версий. Замкнутный круг. Но это мир в котором мы живём...
"Лапша" – это не нормальная эволюция, а одна из следующих причин:
У программистов было мало времени
У программистов было мало опыта в написании масштабируемого кода
Что касается паттернов, то тут понятно, что водка лучше самогона общепринятое решение всегда лучше своего велосипеда.
А то, что Angular неидеальный, – это очевидно, хотя бы по 1,7k issue на GitHub
Сгласен с пунктами 1 и 2. Но в том и дело, что у программистов всегда мало времени и команды программистов не состоят на 100% из идеальных работников :)
На практике никто никогда не позволит программистам условно целый год ваять какое-то супер-масштабируемое «произведение искусства», которое оценит каждый программист и похлопает по плечу. Владелец бизнеса по плечу не похлопает. Всегда есть бюджет, сроки и т.п. Поэтому и видим время от времени решения на скорую руку, хардкод и прочее, то что любой опытный программист понимает как некачественный код, но «так и быть, сделаем рефакторинг позже». А потом уходит из компании/проекта.
Мы живём не в видеальном мире. У вас в команде из 5 программистов никогда не будет 5 программистов-суперменов, где каждый на 100% освоил синтаксис, мыслит на 100% абстрактно и пишет на 100% масштабирумый код. В конце концов, всем свойственно делать ошибки будь то сознательно (см. пункт 1) или бессознательно.
P.S. Не путайте фразу «нормальная эволюция» с понятием «так и должно быть». Лапша — это плохо и так не должно быть.
Придерживайтесь паттерна здравого смысла. Планируйте проект и его архитектуру заранее на сколько позволяет ситуация. Ну а потом по старинке: HTML / CSS / JS. Сам так делаю — всё хорошо работает и поддерживается.
Нет ничего страшного в отстутсвии фреймворка. Автор прав насчёт скорости — она не такая уж низкая, тем более, с современной браузерной поддержкой новых «плюшек» в HTML, CCS и JS.
Хотелось бы посмотреть на примеры прекрасных и богатых веб-приложений, не использующих никаких UI-фремворков...
GitHub?)
Разве jQuery это фреймворк? Вроде как это библиотека.
Это где GitHub использует React и jQuery? Насколько я вижу, ничего этого у них сейчас нет на сайте, а для UI они самописное используют - https://www.npmjs.com/package/@primer/css .
Можно ссылки?
Пару-тройку UI - это уже роскошно.
От jQuery, вроде, официально отказались с 2018.
Ссылки нижеhttps://github.blog/2018-09-06-removing-jquery-from-github-frontend/https://habr.com/ru/post/418257/
У них там из последнего Catalyst, это библиотека вполне себе уровня React, Angular, VUE и т.д.
https://github.blog/2021-05-04-how-we-use-web-components-at-github/
Не знаком с Catalyst, но он очень похож на Stimulus JS. А Stimulus я использую последние пару лет во всех проектах. Это реально очень простой и удобный микро-фреймворк для JS. Он работает поверх HTML, сгенерированного сервером. Позволяет легко добавлять интерактивность, при этом сохраняя основную бизнес логику-на бекенде.
Ну у гитхаба сам по себе как приложение предельно простой. А вот условную 1с-ку на жквери я бы глянул :)
Ангулар помойка, согласен. Но есть легчайший vue и react, которые выпоняют строго отведенную роль, работа с ними не вызывает боль ниже спины. Просто поделка от гугл не нужна.
А вот отказаться от препроцессоров это большой шаг назад, тут не согласен
Легчайший реакт? С хуками, редуксом и 50 копированиями всего на каждый чих? Лiл)
реакт - шаблонизатор, именно так его нужно рассматривать, он прекрасно ложиться в MVC паттерн, если к нему прикрутить Mobx+ DI
Почему если React, то сразу значит "+Redux"? Вовсе необязательно :)
Без Redux будет очень сложно следить и управлять State если проект становится большим. Раньше я тоже считал, что Redux не нужен но увы в крупных проектах он упрощает жизнь.
Без Redux будет очень сложно следить и управлять State
Не без Redux, а без глобального управления состоянием. Имхо MobX вполне себе альтернатива.
Если проект становится большим, это вовсе не означает, что State Manager надо превращать в коробку для хранения всего. Есть глобальное состояние приложения (его много не бывает), есть локальное состояние. На MobX у вас есть возможность создавать нормальное локальное состояние без проблем. Хотя в последнее время я больше тяготею к хукам, у MobX есть свои плюсы. А вот для чего мне Redux тогда я не понимаю. Думаю, его используют в основном не потому, что он нужен, а потому, что "все используют". Карго-культ)
В чем проблема хуков? Зачем копировать всё 50 раз? Даже если и так, это хуже ангулара?
В чем проблема хуков?
В многочисленных подводных камнях, тормознутости и часто неочевидности
Зачем копировать всё 50 раз?
Не знаю, спросите у Абрамова и того, кто придумал идею flux/redux/*ux. Но с этой идеей любое нетривиальное действие, модифицирующее состояние, вызывает просто лавину обновлений и перерисовок.
Даже если и так, это хуже ангулара?
не знаю, имо оба хуже. Путь, предлагаемый в статье - рендерить всё руками - может потенциально и быстрее, но уж точно глючнее и трудоёмче. Vue и vue+jsx более-менее норм для мелких и средних проектов, но для крупных (10+ фронтовиков), вполне возможно, будет не очень.
В связке с MobX - таки легчайший. Хуки, если в меру, то вполне съедобны.
Если хуков в меру, то норм.
Я видел, как норот пихает по сотне хуков в один компонент. Потому что за классы вчерашние джуны засмеют. Ну да, за классы с 50+ полей тоже, скорее всего, не погладят, теперь уже старшие, но там хотя бы очевидна необходимость дробить и рефакторить.
Я видел, как норот пихает по сотне хуков в один компонент.
Да, проблема имеется. Точнее, две проблемы. Во первых, слишком большие компоненты (но, кстати, функциональные компоненты легко распиливаются, а конструкции из базовых элементарных хуков прячутся в кастомные хуки, и всё становится красиво). Во вторых, попытки реализовывать бизнес-логику в хуках (чему редукс весьма способствует). Тут уже сложнее, это отдельная песня.
реакт несомненно легчайший, только написать приложение на нем довольно проблематично. Нужно добавить в него еще кучу костылей, если все пройдет удачно и хорошо получишь что-то вроде своего Angular, на котором наконец можно писать. Если...
А можно какую-то обоснованную критику ангулара-то? Пишу на нем уже года три, а тут оказывается его выбросить нужно. До этого писал на реакте и знаю его очень неплохо, а недавно делал тестовое на vue - и то, и другое тоже хорошо, но чтоб прям принципиально лучше ангуляра - даже близко не представляю о чем речь. Вернее, есть пару претензий к ангуляру, но, как правило, чтобы их назвать нужно очень глубоко знать фреймворк, и те, кто выдает такие комментарии, обычно ничего перечислить не могут
Тут многое зависит от того к каким проектам применяют то или иное решение. Сам занимаюсь разработкой крупного клиентского проекта. Я не могу представить как пришлось бы разрабатывать без всего того, что предлагает и рекомендует мир angular + mobx. Но в то же время даю себе отчёт, что в небольшом, да и в среднем проекте angular избыточен. 80% проектов являются таковыми. Отсюда и такой негатив в сторону angular.
Самая большая - сложность обучения, из-за которой многие негативно относятся к этой платформе:
Непрозрачность того, как работает cdr и zone [ну многие так говорят, хотя мне кажется, что это очевидные вещи какие-то]
Такие штуки, как DI и rx - это сложно, хотя я уже представить не могу, как без этих штуковин (паттернов) решать свои задачи настолько же изящно
Что еще за модули? Гарды и резолверы?! Пайпы?!!!! - я тута тока реакт-комопнент-писака, не понимац, надо тока компонент, остальное сложна (сорри, что упомянул реакт как будто в негативном ключе - это наоборот круто, что в реакте можно обходиться без лишних сущностей)
Наверно, что-то еще (и даже много), но я уже не могу сказать, что сложно, а что просто, надо спросить у тех, кто пробует войти в ангуляр
Как следствие популярность инструмента падает, сообщество растет медленно, меньше готовых решений. Кроме того сейчас многие перешли на "функциональную" парадигму, и вот есть такая либа как twilio -- в ООП она прям плохо вписывается, хотя это дико популярный инструмент для видео-аудио-звонков.
Остальное мелочи, к примеру:
Почему нет типов на ngOnChanges?
Почему нет типов на Provider?
Почему нет типов у FormControl?
Почему нельзя стилизовать диррективу?
Как мне пробросить аттрибуты на дочерний шаблон так же красиво, как во vue или react?
В качестве расширения комопнентов есть только наследование, а вот всякие крутые решения по типу composition api (vue) или hooks (react) -- отсуствуют;
В ssr нет возможности проставить custom-property (css);
«cdr и zone» — а вот тут согласен, по воспоминаниям, это занимает первые места по боли в работе с ангуляром, помню еще какие-то хаки писали в ончейндж везде.
«DI и rx» — не вызывало никаких проблем при изучении, но может, опять же из-за .Net бекграунда. Ну, rx-ом можно себе в ногу выстрелить, конечно, что-то сложнее банальщины читается оче тяжко, поэтому стрались не переусердствовать.
«надо спросить у тех, кто пробует войти в ангуляр»
Да, ну может еще тайпскрипт. Еще вспоминается, да, скудная база библиотек (ну в сравнении с первым ангуляром или того более просто жиквери).
И лично моя боль и вопрос, а что на счет не SPA? Помню, раньше это была проблема, как минимум из-за тяжелого инита. Да и в целом ангуляр себя позиционирует как SPA фреймворк. Сейчас с этим как?
angular 2 никогда не был встраевымым, ничего не изменилось к текущему моменту, и, мне кажется, никогда не изменится - из пушки по воробьям не стреляют) В кейсах, когда нужно что-то среднего объема поднять сам я использую vue.
А про бэкграунд с .net -- это, разумеется, хорошо подмечено. Многие разработчики с базой в виде c# или java легко вкатываются в этот фреймворк.
"Непрозрачность того, как работает cdr"
"мне кажется, что это очевидные вещи какие-то"
Думаю вам это очевидно просто в силу того, что у вас не было желания/необходимости копнуть чуть глубже того, что написано в доке(достаточно общими словами, кстати).
"rx"
"изящно"
Выберите что-то одно.
Думаю вам это очевидно просто в силу того, что у вас не было желания/необходимости копнуть чуть глубже
Так я ж про публичный интерфейс говорю, понятно, что внутри сложная инкрементальная проверка через всякие побитовые сравнения. Да, на практики у меня необходимости в этом знании не было.
"rx""изящно"
Выберите что-то одно.
Ну тут уж дело практики, кмк. Ну либо можно пример того кода с rx, который написан приемлимо, и при этом, если переписать его без использования этой либы, он будет гораздо лучше?
Так я ж про публичный интерфейс говорю
Как только встают какие-то небанальные задачи и нужно подумать о перформансе, то там далеко не всё так очевидно.
Можно пример такой "небанальной" задачи, ради которой мне нужно лезть разбираться в кишках ангуляра? А то, вот буду сидеть теперь и думать о том, какой же я банальный разработчик, банально решающий банальные задачи)
Кроме шуток, не пойму о чем идет дискуссия - я изначально сказал, что cdr и zone - это сложность фреймворка, мол, даже с публичным интерфейсом из 5 методов, надо поразбираться по началу.
"rx""изящно"
Выберите что-то одно.
Там и в самом деле получается изящно, только с вывихом мозга для "не-ФП-шника", если кейс не совсем банальный.
Работал в двух проектах, в одном rxjs тащили вообще везде, где только возможно. В другом использовали только на тех местах, где реактивность уже шла из ангуляра.
В первом случае, где все покрыто реактивностью - получился спагети код. Который абсолютно все читали с трудом.
Я быстрее прочитаю 100 строк ванильного жса, чем 20 строк всратого rxjs'a, десять свитч мапов, вложенных в пять мерж мапов, обёрнутых в комбайн латест, на асинк сабжектах. Rxjs делает плохой код хуже.
Имхо, если и тащить его в проект(а штука в принципе оч.полезная в некоторых ситуациях), то с серьезными ограничениями.
Про атрибуты на дочерний шаблон - в точку)
Три года разработки - не срок. Еще лет 10 и никто не вспомнит, что был такой Ангуляр. Умрет, как и многое другое, которое уже умерло. Проблема - как поддерживать все то, что на нем было сделано? Легче выбросить...
Дичь какая, и вместо десятка популярных фреймворков с хорошей документацией мы получим свой велосипед с дырявой документацией и пачкой багов в каждой отдельной компании.
То есть, если было "подрядчик, работающий с несколькими организациями, использующими разные UI-фреймворки", то теперь нужно знать разные велосипеды в каждой отдельной компании. Таким образом привлекая новых специалистов компания всегда будет тратить тысячи денег на то, чтобы новый специалист разобрался сначала с велосипедом и потом уже начнет пилить фичи.
Все равно поверх фреймворка будет велосипед и с ним нужно будет разбираться.
По-моему мысль не в том, что делать свои фреймворки вместо популярных. А в том, чтобы не использовать и не строить никакие фреймворки (а angular себя называет даже не фреймворком, а платформой), а использовать и строить библиотеки (модули). Библиотеками пользуются по мере необходимости, фрейморк диктует тебе как жить.
Да это ограничивает функциональность, но и большой плюс от этого есть
"больших проектов" - пример можно?
За популярные веб-ресурсы не буду говорить, но среди корпоративных решений такие встречаются нередко. И когда на фронтенде большое количество различных сложных компонентов: виджетов, графиков, табличек, админок и прочее, фреймворк, который ограничивает творческую свободу разработчиков, - это несомненное благо. И хотя я бэкендер, но будучи немного знаком со структурой нашего проекта на фронте, не могу себе представить, насколько сложнее стала бы разработка без ангуляра, и тем более без фреймворка вообще. Сейчас же новый человек может достаточно быстро погрузиться в проект и начать фигачить таски.
Росбанк, мтс, альфа банк, тинькофф. Часть сервисов написана на ангуляре))
Вообще интересно, что скажет @obenjiro на это всё) хотя я догадываюсь
office.com
Лично наблюдал, как умирал проект на Angular 1. Проект начинал молодой мальчик с горящим взором "надо делать вот так, это сейчас самое модное с поддержкой от google". В итоге у мальчика огонек погас уже через год и он тихо слился. Развивать проект было некуда - производительность у Angular ниже плинтуса. Возможно, помогла бы миграция на Angular 2 (а потом 3? а потом 4?), но полная несовместимость версий и в итоге проект закрыли. Мораль сей басни такова - фреймфорк вам диктует не только как жить, но и когда умирать.
странно, а люди мигрируют и ничего
У людей есть бюджеты и много свободного времени...
Но вот скажите, в чем цель использования тяжелых вещей для фронтенда? Открываешь сбербанк онлайн и ждешь когда все это подгрузится.. 10 мегабайт, только чтобы увидеть состояние счета. Открываешь gmail и грузишь 20 мегабайт, только чтобы проверить свою почту. Товарищи, очнитесь. Зачем пользователям все это? Надо возвращаться к корням веба. А не то не только Angular придется выбросить, но и весь web. Как в Китае собственно уже и происходит (на хабре писали уже).
Открываешь gmail и грузишь 20 мегабайт, только чтобы проверить свою почту. Товарищи, очнитесь. Зачем пользователям все это??
Ну например сейчас большинство пользователей хочет чтобы почта была с картинками и форматированием и чтобы линки в почте автоматом открывались в браузере и чтобы редактор был WYSIWYG и так далее и тому подобное.
И я посмотрю как вы всё это будете реализовывать и тем более поддерживать на технологиях из времён «корней веба».
А что пользователи хотят от сбербанк онлайн? Смотреть анимацию по 10-15 секунд, пока там что-то подгружается / рендерится? Если умеете писать только такой код - заявление на стол и идите в другое место работать, там от вас будет меньше вреда. Такой результат работы - проф. непригодность. Тут и 5g не поможет с гигабитным интернетом. Главная страница https://angular.io/ - это 35 запросов в сеть и 3 мегабайта непонятно чего. И это просто страничка текста с несколькими картинками?
Ну, типа контора использует Angular 10 и им сложно найти разработчиков. Давайте не будем использвоать ничего, в итоге программисты родят своё подобие фреймворка чтоб как-то организовать код, но мы будем искать теперь не Angular 10 разраба, а просто JS. Их же больше.
Отличный план. Надёжный как швейцарские часы, если я правильно понял.
Я поддерживаю это мнение частично уже более 2 лет. Правда я считаю оправдным использование каких-то либ/фреймворках в фронте и поэтому потихоньку развиваю свой фреймворк(https://github.com/LborV/js-mvca), у меня тут частичная предварительная компиляция шаблона в json - а фронт подставит переменные и сам всё сгенерит. Плюс всё сокет орентировано, вообщем, ангуляр ненавистникам рекомендую глянуть) доки у меня просто ужасные, даже не пытайтесь там что-то понять
Может автор не пробовал vuejs
Вроде в США не популярен.
Автор писал о Angular как пример, но писал и о Vue и о React.
"все в помойку" - давайте динозавра писатьВам нужно будет знать не только 12 разновидностей Angular, но ещё и разные версии Vue и React, так как какой-то новичок «подсадил» некую компанию на нечто подобное 4 года назад, а теперь ушёл оттуда, чем разрушил чей-то технологический стек.
Пришло время отправить Angular и другие подобные разработки на свалку неудавшихся экспериментов, где им и место.
Но ведь было же когда-то без фреймворков. И всё равно получался запутанный лапшекод.
Хотел бы я посмотреть на код автора этой статьи… Все равно ему придется писать и механизм рендеринга в DOM, и механизм обновления данных патчами (т.к. переписывание innerHTML собьет listeners), и жизненный цикл компонентов (т.к. нужно где-то очищать listeners и timeouts), и механизм обработки пользовательских событий (onclick="window.myFunc" не подойдет из-за засорения глобальной области видимости и недоступности локального контекста данных), и экстракт состояния, отрендеренного на сервере, из разметки, и много чего еще. Не собирается же он бэкендовым twig рендерить модалки, графики, селекты, валидации форм и т.п., чтобы при каждом клике на элемент страница перезагружалась?
Насчет недостатков Angular я скорее согласен с его ломающими обновлениями и обилием встроенных библиотек, но про "другие модные библиотеки" он так зря.
"Святой Грааль написания кода, любого кода, заключается в простоте" — тут как раз если ты знаком с фреймворком, то при переходе в новый проект очень быстро можешь разобраться и начать писать код. В общем, выглядит, как жалобы верстальщика лендингов с каруселями на jQuery, который посмотрел на серьезные проекты и подумал — нет, я слишком стар для такого, лучше буду хейтить все подряд.
А можно подробнее про "ломающие обновления"? Какие-то примеры из личного опыта?
Просто по моим наблюдениям (а я работаю с Angular со времен 2rc.1), авторы фреймворка очень много внимания уделяют тому, чтобы выход новой версии не начинался с трудностей по обновлению вашего проекта. Допустим, команда решает избавиться от одной библиотеки и заменить ее другой (или та же библиотека, но в более старшей несовместимой с текущей версии). В текущей версии Angular N никаких "хотфиксов" не происходит. В версии Angular N+1 заменяемая библиотека помечается как deprecated, ее использование по прежнему возможно, но посредством deprecation warning рекомендуется использование новой. И только в версии Angular N+2 старую библиотеку выпиливают окончательно. При подбном подходе и не игнорирования предупреждений, обновлений версии происходит абсолютно безболезнено с помощью одной лишь ng update
"Я сам не слышал, но мне так сказали". Я работал только с первым ангуляром, про ломающие обновления слышал от коллег, поэтому аргументированно не смогу ответить.
Ну то что всё ломается через одну версию, а не на следующей какбэ не значит, что не ломается)
Я просто приведу более жизненный пример, на который сам напарывался, и скорее всего на нем покушали другие люди:
Бывает приходишь на проект, там SPA на втором ангуляре (к примеру, было и на других продуктах, у меня на PHP вот). Бизнесу нужны фичи, которые без боли можно зарелизить на Angular 10. И ты понимаешь, что там столько всего поменялось, что дешевле либо переписать всё заново, либо пилить фичи на Angular 2. Но уж точно не апдейтить до 10 версии.
И никакие "deprecation warning" тут не помогают, к сожалению.
Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS
А если это несколько разделов с разными меню, графиками, фильтрами, взаимозависимыми селектами, автодополнениями? Так и получится в итоге свой фреймворк.
Мне кажется, угол наклона графика сложности (от размера проекта) у "написать на чистом JS" положительный, а у "написать на готовом фреймворке" — отрицательный. И после некоторого значения второе становится выгоднее первого.
Ага, а еще были люди, которые говорили, что "мы на ASM'е все гораздо лучше напишем". Смысл фреймворка не писать 100500-ый раз гребаную форму аутентификации, гарды, валидацию и вот это вот все. За бесконечное время я на любом языке напишу "аккуратный великолепный, быстрейший, красивейший интерфейс",... но зачем и кто за это мне заплатит?
Черт, зашел почитать обоснованную критику ангуляра, а внутри "scss это неудобно"...
В частности, речь идёт о постоянном обучении и переобучении персонала в условиях, когда, можно сказать, ежегодно, выходят новые версии фреймворка
Каждый раз обновляя ОС, я с нуля учусь пользоваться компьютером.
Статья полностью под эмоциями, никаких конкретных предложений или причин автор не написал
Несколько лет назад я для интереса прошел обучение на freecodecamp, и два отдельных курса там были посвящены написанию одного проекта на Angular2, и второго на React. Я прошел их полностью, Мой субъективный вердикт для ангуляра сформировался очень быстро и бесповоротно - тупиковый проект, и работа с ним - потеря времени и денег. Через годы выяснилось, что они не имеют обратной совместимости от версии к версии, что напрямую свидетельствует о проблемах на архитектурном уровне. Реакт же, реализует простую идею виртуального DOM, которая при правильном подходе дает новый уровень простоты в разработке UI. Ничего подобного я не видел за годы работы со spring, Qt, msvs, и даже борладовких дельфи и с++, каждые из которых я любил.
Мне кажется, основная проблема в том, что мы сейчас используем HTML и Javascript не для того, для чего они создавались первоначально. Отсюда и переусложнённость всех UI-фреймворков. Что с этим делать, раз уж уже так получилось, я даже не знаю, если честно.
Крутой мужик.
У него в блоге целых четыре статьи, и какие!
Последнюю однозначно стоит прочитать, ведь он — автор Tiger Platform.
P.S. Да, я в курсе, что сарказм — низшая форма юмора.
Фреймворки, валидация, гарды.. хуже приложений, чем Фейсбуковских -- ещё поискать! Глючнейший Инстаграм, который никак не научится считать количество уведомлений или нормально резать видео, кошмарный сам по себе Фейсбук -- так чего удивляться, что та же компания 10 лет пилит фреймворк и делает в результате какого-то монстра? И как ожидать от них хорошего во фронте?
Программисты Google? Можно, в бекэнд они умеют, Golang прекрасен. Но во фронте -- да посмотрите на Gmail, или зайдите на Page Speed Insights, или Google Console -- это всё глючит, откровенно плохо сверстано по принципу "и так сойдет". Ну и тоже 10 лет пилят... Как ожидать от них чего-то хорошего во фронте?
Причем мало того, что нынче все увешано этими фреймворками там, где без них прекрасно можно было бы обойтись, так ещё и всё, что во типовой фреймворк не входит, люди писать разучились.
Открываю сегодня форму ввода телефона на сайте, вернее, SPA ВТБ Транспорт - всё модно, современно, молодёжно. Вставляю туда номер +7925xxxxx-- получаю +77925xxxx, с лишней семёркой. Гениально. Матерюсь, стираю, ввожу с девятки руками -- получаю +79925хххх, с лишней девяткой. Зато все красиво подсвечивается, что телефон должен быть в правильном формате.
То есть стандартнейшая задача, форма входа с логином - телефонным номером. Но, видимо, фреймворк настолько отвлекает от написания собственного логики, что на эту основную и простую задачу сил уже не хватило.
Так что прав автор, ой как прав.
P.S. Дальше там у них в пароле нельзя использовать символы вроде $ или _ (не шел, как другие символы). Видимо, базовый валидатор не позволяет, а настраивать его -- лезть в кишки фреймворка или писать что-то своё, слоооожно. Мне кажется, никакой jQuery так людей не испортил..
Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
Звучит как оправдание собственной и корпоративной глупости. Если что-то сделано глючно - это пользователю наплевать на ваши эстимейшены и десяток менеджеров с MBA, он просто обматерит или уйдёт.
У всех багов есть severity и исходя из него они идут в спринт. В случае большого приложения количество багов начинает превышать ёмкость спринта (количество рабочий часов разработчиков) и начинает расти бэклог. Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
Если вам кажется, что разработчик может дополнительно поработать часок, то это только немного увеличит ёмкость и не решит проблему нехватки ресурсов.
Таким образом не критичные баги могут висеть годами.
Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
эээ... вы это надеюсь сейчас пошутили?
Добро пожаловать в мир победившего управления качеством!
Не качества, а именно управления.
В математическом пределе у нас есть затраты на устранения дефекта стоимостью dLoss денег и потенциальные доходы от его устранения dGain. Если dLoss >= dGain , то устранять дефект тупо невыгодно.
На оперативном уровне (PM / лид) берётся 2-3 шкалы, допустим:
количество затронутых пользователей: единицы - мало - много - почти все
серьёзность бага: некрасиво - некомфортно (есть обходные пути) - отказ отдельных функций - порча данных - проблемы безопасности - отказ всей системы
и/или же срочность исправления: подождёт - срочно - надо вчера - ОГОНЬ
и по ним строится квадрат/куб/гиперкуб решений. Т.е. если отказ всей системы для всех пользователей это ОГОНЬ и чиним немедленно, выдирая кодеров из кроватей. А если кому-то там неважному в количестве трёх человек придётся сделать пару лишних кликов мышкой, то откладываем до рефакторинга.
Ну и модные гибкие методологии, скрамный аджайл, вот это всё. Ну, когда менеджер проекта официально самоустранился, разрабы снежинки, плывём по течению к ближайшему раунду финансирования. Если из-за бага никто важный не пришёл и не наорал, никто из разрабов случайно не починил, и прошло скажем 5 спринтов - баг закрывается как неважный:)
Как будто это что-то плохое.
Ну давайте делать вотерфолл... когда лет через 5 будет готова спецификация, вдруг окажется что оно уже и не актуально... или же конкуренты вышли на рынок раньше. Это бизнес в конце концов.
Мы должны смириться с тем что увы, никто не знает как писать код или создавать бизнес с нуля правильно, без багов, и что бы подходил всем. Это так не работает. Слишком много unknowns.
Бизнес это управление рисками и с одной лишь целью - заработать денег. Поэтому если бизнесу выгодно что-то, ему как бы все равно нравится ли это программисту/отдельному клиенту или нет.
И в этом примере, если бизнесу выгоднее что-бы какой-то условный индус с суппорта потратил час чтобы исправить вручную какую-то конкретную проблема конкретного человека чем тратить час работы программиста на баг, который приходит раз в год - то со стороны бизнеса это правильное решение.
Закрываются они не сразу, а спустя некоторое время. Эту практику можно увидеть в GitLabOrg (пример: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/211).
Я не знаю в каких компаниях вы работали, но так работает бизнес. Там другие метрики, риски и т.д.
Компания физически не может вот взять и все починить. Я не знаю если вы программист, но по вашей логике, глядя на бэклог багов 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
Жизнь она немного сложнее. Сделать можно все. Это лишь вопрос времени и денег.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
Нет, не понимаю, и понимать не собираюсь.
Если я, как клиент, захожу на сайт пафосной организации, то я, как клиент, и оцениваю компанию по её сайту. И если вижу, что все тормозит и глючит - составляю соответствующее мнение о компании.
И мне плевать, что у компании "другие приоритетные задачи", "проблема висит в бэклоге" и прочее.
Еще раз. Если компания может позволить потерять вас из-за этих багов, то все нормально. Это бизнес и ничего более. Скорее всего есть баги из-за которых компания рискует потерять больше, и они в приоритете.
У вас всегда есть выбор перейти к другой компании где все программисты пишут продукт без багов...
Вы так говорите, будто компании не плевать на то что вы думаете когда заходите на её сайт.
Понимаю, но вы пишете про то, что ошибки исправлять никто не хочет. А я про то, почему они вообще возникают.
Фреймворки не просто помогают, они изолируют программиста от решения многих задач. Дописать две строчки на JS, проверяющие, начинается ли ввод с + или с 9 -- не проблема, проблема в том, что переключаться на чистый JS не хочется, неуютно это.
Фреймворк тут не причём, обработка past, шаблон в input, валидатция все на совести разработчиков.
Со вставкой - проблема повсеместно, и не только в веб, но и в мобильных приложениях
По мере взросления человеку требуется поддержка. В начале это ходунки jQuery, потом костыли Angular.
Большинство перерастает этот этап и осознаёт что данная поддержка им более не нужна, и можно просто тяп ляп и в продакшен.
Меньшинство растёт дальше, до осознания: стандартов, требования бизнеса, в том числе к заменяемости сотрудников(опять же стандарты), или поддержке с прогнозируемым временем на внесение изменений и там или иначе приходит к четкой структуре, я бы даже сказал диктатуре, кода.
Хотя буду честен - в то время как Angular это именно диктатура структуры кода, чего очень не хватает рандомным React приложениям, многие основополагающие принципы, следуя которым эта диктатура может сделать «хорошо», товарищи проигнорировали.
У меня нет страха или неприязни перед фреймворками. Но я очень боюсь их количества. Но и писать все на чистом JS - тоже не выход, ведь это все разовьется в повторяемый код, а далее логично перетечет и в библиотеку. Только ты ее будешь знать хорошо, как ее автор. А когда поделишься ей со своими знакомыми или выложишь в общий доступ - получишь фреймворк. Еще один.
Думаю, что это должно решаться на уровне выбора средств разработки архитектором. Но не проекта, а всей компании разработчиков. Не знаю, как там это называется, что-то типа технического директора что ли. Выбрать какой-то стек и скрестить пальцы, чтобы он развивался в нужном вам направлении. Так себе лотерея, конечно.
Мне кажется, что в сложившейся ситуации, немалую роль сыграла попытка следования всяким надуманным принципам типа SOLID,TDD,BDD и т.п, которые пропагандирует Боб Мартин и компания инфоцыган от программирования. В итоге вполне конкретные задачи, которые можно решить в несколько строчек кода, разрастаются в раковую опухоль, так как простое решение типа не соответствует "принципу".
Вы правы, признаюсь, что лет 5 назад я окончательно перестал понимать, что такое SOLID и TDD и главное зачем это кому-то нужно кроме самого Роберта Мартина, который зарабатывает на этом деньги.
Благодарю за развернутый ответ, но к сожалению вы и не угадали. Сильная неприязнь к этим принципам у меня появилась как раз после разработки достаточно крупных проектов. В самом начале, я так же читал и слушал всякие "умные" лекции о том как "правильно" писать код, про расширяемую архитектуру, модульность и тп. Это все хорошо звучит в теории, но на практике практически не работает (если у вас нет дара провидения). Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface. Привычка плодить горы классов и интерфейсов в угоду абстрактной расширяемости и тестируемости, приводит к тому что имеем - медленный, сложный и глючный софт. Не нужно решать проблему сферического коня в вакууме.
Возможно, там позабыли про чувство меры и довели хорошую идею до абсурда.
Совершенно верно. Никаким "принципам" нельзя следовать бездумно, у любых принципов есть границы их применения, и всегда нужно учитывать конкретные нюансы.
Согласен, я об этом и говорил, что такие личности как Мартин и его адепты, пропагандируют оценку кода на соответствие каким-то надуманным принципам типа SOLID, в отрыве от контекста и задачи, которую он решает. К этому добавляются крики об обязательном 100% покрытии юнит тестами, которое приводит к необходимости реализаций абстракций для моков, там где они абсолютно не нужны. В итоге проекты серьезно страдают, только ради того, чтобы им не предъявили - "тут у вас нарушается принцип Single Responsibility, нужно разбить этот класс на 5 других а также использовать интерфейсы и DI".
Не все фреймворки монструозные, а к монструозным фреймворкам приводят не сами принципы, а требования и цели, на которые ориентируются их авторы.
В чем-то вы правы, часть монструозности фреймворком лежит в попытке реализации как можно большего объема функционала. Тут вопрос в самом концепте фреймворков.
При всем при этом, как здесь уже неоднократно замечали в комментариях, во многих случаях при отказе от фреймворков после определенного этапа в итоге в коде получается самодельная аналогичная, но гораздо более кривая и косая реализация чего-то похожего на какой-то из тех же фреймворков.
Не согласен, это стандартная страшилка для новичков - лучше сразу используй наш супер модный react,vue,angular и тп., иначе потом сам прийдеш к самописному фреймворку, только кривому. В этом есть доля правды, может ты и напишешь часть своего, но это будет только маленькая часть, которая решает конкретно твои задачи и не будешь никак зависеть от стороннего решения. Если нужно что-то изменить или оптимизировать, ты не должен городить костыли, править сторонний фрейворк и потом бояться обновлений. Тут все не так однозначно. Для всяких веб студий, которые клепают однотипные решения это ок, но брать фреймворк для собственного проекта глупо.
Угу. Но чтобы отказаться от расширяемости и тестируемости, вам нужно быть на сто процентов уверенным, в каком направлении и как будет развиваться проект через N, N*2, N*5 лет. Что тоже требует дара провидения.
В этом и состоит проблема, что никто не знает. Если ты не уверен, в каком направлении будет развиваться проект, то нужно действовать по обстоятельствам - добавлять функционал и рефакторить по мере изменения требований, а не лепить сходу горы абстракций, чтобы как говорят - "на будущее", "в дальнейшем было проще расширять". Не бывает идеальной архитектуры, которая магически расширяется и перестраивается под любые изменения требований, так что это больше вангование.
Вот "медленный" в этом ряду вообще выглядит странно. В случае с 95% известных паттернов, единственный оверхед, который они могут дать, это несколько дополнительных вызовов через vtable (в зависимости от языка еще могут быть дополнительные аллокации, но это уже проблемы этих языков).
Напомнило шутки про "zero cost abstractions" :)
Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface
Современная "наука" в том же ЖС имеет функцию с такой же логикой, но при этом она должна быть названа по-хипстерски. Ну типа `it` или `mk`. То есть логика та же, но при этом оно называется абсолютно нечитабельно.
Вот как лично вы замените проброску зависимостей, когда будете писать код? Зависимости будут глобальные? Или иным способом?
Если ребенку дали молоток, то внезапно оказывается, что все вещи в доме нужно приколотить.
Так же и с этими принципами. Гуру (или их адепты - не знаю) как-то забывают, что все должно иметь определенную область применения.
Любой достаточно сложный сайт на vanilla js содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины Angular.
Что ещё можно добавить?
с минусом своей поддержки предыдущих версий
О каком минусе вы говорите, если со времен релиза Angular, структура компонентов не изменилась никак? То есть, вы сегодня можете взять стрый компонент, написанный во время выхода Angular 2 или 4 (при том что версий 1 и 3 попросту не было), и без изменения кода перенести его в Angular 12.
Более того, в моей практике был случай обновления проекта, завершенного под Angular 4 и который я без особых проблем перенес под Angular 11. Единственным большим breaking change как правило будет изменение библиотеки Http -> HttpClient.
А если вы говорите про AngularJS, то это нельзя считать первой версией текущего Angular, это по сути совершенно другой фреймворк со схожим названием.
Вам нужно будет знать не только 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 , то лучше поспрашивай других мнений по этому вопросу.
Его надо выбросить и написать вместо него простые, лёгкие в использовании и понятные JavaScript-модули (или плагины — называть их можно по-разному)
То есть давайте выкинем один общий на всех Angular и потом каждый для себя напишет свою собственную версию? :)
И где появится эта кнопка? А если я хочу две иконки перед текстом, и чтобы одна появлялась после нажатия? А как мне задизейблить кнопку и добавить пару классов? Предлагаете делать так?
const MyButton = New MyButton("Click me");
MyButton.classList.add('class1');
MyButton.disabled = true;
MyButton.click = () => { /* .... */ };Поздравляю, кажется, мы только что изобрели DOM-API
Проблема тут не в возможностях ООП, понятно, что написать оберток вида class MyButton (){ ... } мы можем сколько угодно. Просто количество лапше-кода, даже для создания простой формочки с тремя кнопками, будет немыслимое. И эти полотна кода никогда не будет более читабельными, чем
<button class="my-button">Click Me!</button>Ыгыгы, заднеконечники всегда с этого начинают:)
Тут вам и GWT, и Flutter, тысячи их, и это только от гугеля.
Классный перевод, спасибо, но с пунктуацией у вас проблемы
https://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 jQuery in the window object 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.
Кстати какой-то олень в Bootstrap сломал поток исполнения js ради "гибкой поддержки". Раньше bs jquery компоенты цеплеялись/инициировались при загрузке, теперь после окончания загрузки страницы. "А потому что надо посмотреть если на 'body' флаг "используй или не используй jquery". Что поломало порядок инициирования, а в случае сложных компонент (моя компонента зависит от bs компоненты) всю аппликацию. При том что в среднем скрипты то все равно к концу страницы прелеплены и решение - хочешь смотреть атрибуты body не грузи скрипты в header очевидно.
О чем это говорит: 1) чужая голова потемки 2) jquery рассматривают как баласт.
Еще года три назад остро ощутил, что фронт идет куда-то не туда, и из фулл-стека перешел в чистый бек, чтобы в этом безумии не участвовать.
Приятно, что в сообществе приходит осознание этого факта.
P.S. Проблема не только в тяжелых фронт-фреймворках, а в том, что их теперь используют везде, даже там, где ничего особенного от фронта не нужно, и нормально справится обычный html и css
Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
Думаю, это предложение все объясняет. Да, если клепать сайтики, действительно, фреймворка для SPA не нужны. Автор явно никогда в своей жизни не разрабатывал сложные приложения, оттуда и непонимание, зачем «это всё».
А тащить фреймворки, предназначенные для сложных приложений, в сайтики, действительно, не стоит.
Забавный факт - проблема не во фреймворках, а в разработчиках. Многочисленные курсы учат их условно говоря правильно держать молоток и пилу, но не архитектурным основам. Дайте фронтендеру написать либу на ноде и вы увидите всю ущербность организации кода, когда фреймворк перестает диктовать организацию проекта.
SPA с роутером уже не SPA по определению. Если что я понял автора, ему не нравится объем бизнес-логики, подгруженной за раз, но я уверен что можно обойтись делением логики по поддоменам и использовать множество ангулар-аппов. Никто же не мешает делать profile.example.com/, analytics.example.com/.
Удивительно что ещё не было в статье выпада против typescript. Ведь хром не даёт бывает поставить брейкпойнт в нужную строку, что просто иногда бесит.
Во всей описываемой вакханалии беспокоит только одно - тебя могут не рассматривать на позицию сениор фуллстек даже если у тебя 10+ лет опыта и ты писал на ангуляр и Vue, но не писал на реакте на проект с реактом. Вот это вот действительно бред
полностью согласен сейчас ангуляр или подобные суют в любые проекты нужно это или нет
Автор, большое спасибо тебе! Наконец нашелся человек, который внятно описал весь тот срач который творится в разработке последние 10 лет.
Если 10 лет назад можно было написать сайт на коленке в блокноте и все это было довольно быстро. То теперь нам надо подготовить среду, поставить кучу frameworks, причем временами доходит до смешного.
Возьмите любой проект на nodejs сложности HelloWorld и получите более 10 000, а иногда и более 100 000 файлов. А ведь речь идет о том чтобы на выходе получить все лишь HTML!!!!
Иногда я скучаю за временами на Delphi 7 - накидал компонентов на формочку, прописал пару обработчиков и за 15 мин у вас работающая форма.
const 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}/`);
});
Речь не о том. На php вообще одна строка получается.
В данном случае речь о фреймоврках. Поставьте просто express - папка node_modules - 387 объектов. Это не много. Хуже начинается когда вы добавляете какой-то framework и накидываете еще модулей, которые тянут за собой зависимости.
сделайте тоже самое на пхп, поставе через компос какойнить yii или symfony и посмотрите сколько там будет файлов, не говоря уже о том что для запуска сервера на пап вам нужен сторонний модуль
А я не говорю что там все гладко. Так что успокойтесь и не нервничайте. Мир, дружба, жвачка!
Речь о том куда мы вообще катимся.
Я считаю что все от человеческой лени + влияние денег: заказчику надо быстро, нет времени разбираться, и т.д. Все это в итоге вываливается с тонны неуправляемого кода, снижению скорости работы. О, ура, есть повод добавить кеширование!
Ну и т.д.
Ой, я вас умоляю, во времена Delphi 7 было полно таких же нытиков, как автор поста, которые ругали библиотеку VCL за все то же самое, мол, формочка с кнопкой занимает 3Мб! Тогда как на чистом WinAPI можно сделать exe в 100кб. А лучше вообще на MASM32 все написать.
Вот не надо, не 100Kb, было меньше - я помню.
Плюсом VLC было то, что на выходе у вас был 1 exe файл (ну может еще пара DLL - это кто как писал). Все компоненты были у вас под рукой и не надо было что-то тянуть из инета.
Вспомните недавно историю о том как один из авторов удалил из NPM свой пакет и в итоге сломал кучу приложений по всему миру. Уже точно не помню что за пакет был, но что-то безумно простое.
Вот в этом проблема - зависимости, много пакетов. Ну и как следствие - пакеты для пакетов, приложения для еще фиг знает чего. Это скорее смахивает на пузырь, который все ближе к моменту когда он лопнет.
Так ну и пишите сразу html если вам на выходе нужен html и не нужны вот эти все «сложности». Да, по старинке, открыть любимый блокнот и в нем написать. Кто ж вас заставляет все эти фреймворки использовать? :)
Возможно с angular могут возникнуть некоторые сложности в связи с необходимостью писать и бэк и фронт код, но в случае react все гораздо проще и удобней. В данном случае если сравнивать джуниор react разработчика (вместо angular) и джуниор который будет писать на чистом Js, я уверен что на react код будет написан за меньшее время и будет гораздо более простым в понимании для разработчиков(джунов и мидлов, а не сеньёров с 20 летним опытом). Также отдельный вопрос про сайты с десятками а то и сотнями страниц, как поддерживать такие проекты, по какому принципу из писать, какие паттерны использовать, и много других технических вопросов, нет никакого четкого пути построения для построения приложений. Также разработчиков пишущих на Js фреймворках сейчас найти достаточно просто, в данное время каждый второй фронтэнд разработчик пишет на Js фреймворках. А jQuery как по мне уже очень устарел и его надо забыть как страшный сон.
Выкинуть компиляторы? Вот те на! Ну давайте вернемся во времена так 2008 года, будем писать поделки на нативном js, это тоже своего рода ад. Спасибо не надо. И вообще написано больше на эмоциях чем приведены какие-то факты.
Давайте писать на ассемблере! А лучше на машинным коде! Это конечно сарказм, если серьезно то такие "инструменты" как Angular, не упрощают процесс разработки, они его усложняют, но их цель в стандартизации, в общем подходе, в использовании более строгих механизмов контроля типов и тд. По этой же логике зачем мы усложняем наш код разными паттернами проектирования?? Зачем мы следуем определённым принципам? По словам Роберта Мартина это упрощает поддержку проекта, что следовательно, снижает цену поддержки. Ещё обязательно надо помнить - каждая технология хороша там для чего она предназначена! Если проект лучше сделать на чистом js то делайте! А если вам подходит vaadin для рисования ui в java то берите его!
Мне кажется мы слишком ударились в развитие фремворков, в то время как стоит развивать себя. Или можно сказать, что чем создавать для себя набор правил использования языка разработки (тот же фремворк), которые не позволят сделать "неправильный" шаг права или влево, уж лучше использовать эти ресурсы на совершенствование себя и самому знать куда и какой шаг сделать. А если коротко, то в целом я за библиотеки нежели за фреймворк.
Автор предлагает отказаться от монструозных UI-фоеймворков а-ля angular, в пользу велосипедов на монструозных библиотеках а-ля jQuery.
Также решительно не понятно, чем автору не угодило то, что SCSS компилируется при деплое в CSS. При этом минификация его, судя по всему, не удивляет.
Такое ощущение, что у автора ностальгия по временам HTML 1.0 и CSS 1.
Очевидная ересь против CSS препроцессоров могла прийти в голову либо извращенцу-индусу, который любит много писать и переписывать руками, либо теоретику, который на практике CSS только в отладке браузера видел и не верстал даже среднего проекта с хорошими требованиями по совместимости.
Как я понимаю, typescript автор тоже не жалует? Тут без комментариев.
По поводу удлинения CI/CD цепочек: а вы в курсе, что это выполняется автоматически в считанные минуты у нормальных людей со всеми препроцесморами и фреймворками? Подозреваю, что автор из головы руками сборку проводит до сих пор.
Про ангуляр и фреймворки, кмк, автор, решив освоить ювелирку, взял слесарный молоток и теперь доносит нам, что молотки надо выкинуть, а гвозди можно и головой забивать. Конечно, если ты делаешь хороший лендинг - делай руками. А если тебе в 1 лицо надо за 2 недели админку сделать от которой плакать не хочется, как без ангуляра будете выкручиваться?
В общем, весьма спорные утверждения, хотя здравое зерно имеется местами.
А ещё весь бэкенд будем снова писать на Перле
Вдобавок, 90% "современных интерфейсов" на Джаваскрипте неудобнее и медленнее, чем простой разумный веб-интерфейс без всяких клиентских скриптов. А про глюкавость уже и не говорю. В общем, сколько Adobe Flash не убивай, идиоты будут его реинкарнировать.
Наконец-то я дожил до этого момента...
Тут возможны 2 варианта:
1. Если автор - известный человек и с большой буквы то, ждём лет так эдак через 4-5
новости о том, что пора выкинуть QT и .NET на свалку.
Причины - всё те же. Вдобавок, легкоизвлекаемая нефть закончится к 2070-ым годам. Везде будет царить энергоэффективность и всеобщая экономия (сейчас уже есть). Так зачем делать за зря из компьютера - подобие утюга? Лишние ватты/киловатты энергии, которые тратит комп на обработку всей этой абстрагированной мишуры кода.
2. Если автор - не так известен - то, всё это канет в лету.
QT
Чем вам QuickTime-то не угодил?)
Шучу) Речь, разумеется, идет о Qt и, мне кажется, некорректно сравнивать его с Angular.
Первое - большой фреймворк, написанный на C++ и содержащий средства для работы с ОС, сетью, тредами и пр. А также, что немаловажно, биндинги для других ЯП.
Второе - заточенный строго под GUI фрейворк, чтобы пилить формочки средствами тормозного DOM-а.
Я пойду дальше автора и заявлю что вообще фронт-енд программинг - унылая шляпа (вот это все JS, HTML, CSS, зоопарк мутных фреймворков) и должно умереть во имя добра. Стараясь ускорить этот процесс придумал как вообще не прикаcаясь ко всему этому получать готовые фронты для всех девайсов/отображателей, программируя только на том языке, который нравится (вообщем любом). для data science/business апликух, где стандартного MD достаточно.
Написал на flutter (тоже гадость, но меньшего порядка) авто-фронт, юзаю для себя и своих заказчиков, и в общем доволен. Уверен, что подобная моей технология прибьет нафиг всю эту камарилью рано или поздно. А пока до этого не додумались монстры, я тихо сижу и радуюсь, что я вне этого безумия. ну почти так.
что придумал https://github.com/Claus1/unigui
Скажу по-секрету, таких вот "универсальных конструкторов админок" для обсуждаемых в статье технологий, ну примерно дофига. Первая попавшаяся ссылка в гугле: тыц. В-основном, правда, от $15 и до десятков тыщ денег. Некоторые даже не такие унылые, как ваше поделие:)
Правда, иначе как для написания "админки для админов" такие конструкторы использовать нельзя. У обычных людей почему-то начинает идти кровь из нетренированных глаз, и они начинают делать ошибки на ровном месте. А ошибки админа это иногда дорого.
Я 5 лет работаю с vue и react, недавно довелось поработать с angular 11. При изучении angular заметил что каждые 5-10 мин приходиться что-то смотреть в документацию так как на первый взгляд при интуитивной работе с JavaScript что-то не работало так как нужно было дело именно как angular требует. Странные ошибки которые появляются в консоле, а решение для них просто перезапустить angular cli - просто убивало меня, после 15-20 мин проверки кода который точно правильный, нужно запустить ng serve снова и все заработает. В react и vue хватает своей магии и там её относительно немного, и когда стреляет баг с производительностью то +- понимаешь сразу где беда и быстро исправляется, но в angular из за тонны абстракций, и без богатого опыта именно работы с angular а не JavaScript - это реально вызвало у меня боль.
Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
для создания эффективного UX, не нужен фреймворк, под завязку набитый сомнительными возможностями. Для этих целей можно пользоваться любым движком для работы с шаблонами, предоставляемым бэкендом
Судя по всему автор не разобрался, что SPA - это обычно приложения спрятанные за аутентификацией, и им эти поисковые боты и индексация вообще не нужны. Зато им как раз нужны вот эти фреймворки, чтобы реализовать эффективный и сложный интерфейс.
В то время как публичная часть продукта (ака сайт) делается как раз "любым движком для работы с шаблонами, предоставляемым бэкендом" с щепоткой jquery по вкусу.
Много лет делаю нишевые бизнес-приложения для нескольких постоянных заказчиков. Пока присматривался, а не перейти ли мне с чистого JS на какой-нибудь модный фреймворк, оно вон как повернулось. Пожалуй, не буду дергаться, подожду еще.
Нормально относимся, если это https://getuikit.com :)
..в отличие от бутстрапа в котором есть и правда всё необходимое при таком же размере, но без странных решений
Осталось закопать React и Vue, вот тогда заживём!
Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик.
Знаем, проходили. Это тот же разраб, который:
"я не буду использовать фреймворки для php и напишу на плейне быстрее, чем вы все тут в офисе"
"я не буду использовать IDE и напишу код чище, чем любой из этих линтер-юзеров"
"все эти ваши митинги - это потеря времени, сами эстимируйте свои таски, я лучше в это время напишу код"
"я тут переписал велосипед заново и получил +5% к производительности вместо того, чтоб делать таск, но таск я сделаю ночью"
"да мои таски не надо ревьюить и тестить, я никогда не допускаю баги"
"у нас на 5 программистов 2 менеджера - раскормили дармоедов"
"на что они вообще тратят деньги, лучше бы программерам ЗП подняли"
Это тот же чувак, который потом:
"нет, заберите этих идиотов, я буду сам работать, не нужна мне команда",
а затем:
"нет, я не буду никого обучать и объяснять, что я там написал и как это теперь мейнтейнить, если вы можете себе позволить уволить такого крутого специалиста как я, то сами разбирайтесь".
Я говорю об этом уже второй десяток лет.
Безотносительно конкретного Angular, фреймворки (да и часть библиотек) это зло практически во всём, и хорошо бы 98% из них закопать и никогда больше не вспоминать.
Хороши они только в одном - быстром производстве тонн монструозного говнокода.
Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
Любой язык/фреймворк надо уметь грамотно использовать. В первую очередь то означает брать то, что надо и не брать то, что не надо. В C++ эту историю уже давно прошли, и, кстати, крайним способом борьбы со сложностью как раз предлагалось (а иногда и делалось) писать на чистом C.
Все эти беды от недостатка опыта или профессионализма. А в софтверной разработке профессионализм - это как раз НЕ использовать фичи только потому, что они есть, а использовать лишь то, что надо, понятно и можно адекватно сложности задачи в целом поддерживать.
На Angular удобно писать приложения, он навязывает определенную структуру и позволяет решить задачи в целом быстрее, чем без него. Но, как и любой нетривиальный инструмент, в кривых руках он может стать и бедой для всего проекта.
Боюсь показаться непопулярным, но сам JS, как мне кажется, далеко не самый удачный язык.
"Пришло время избавиться от программистов максималистов и сэкономить миллиарды долларов".
Есть подозрение, что автор не поддерживал большие кодовые базы, где переизобретены все возможные велосипеды. С колокольни своего опыта могу сказать, что чем меньше кода надо поддерживать самому (т.е. чем больше использовать готовое стороннее), тем больше отдельно взятый программист тратит на разработку бизнес задач. Как только проект обрастает хоть какой-то сложностью, уже требуется нанимать отдельного человека на поддержку кодовой базы или собственного фреймворка (даже если это "набор плагинов"). И автор как раз таки не раскрыл, для чего все используют фреймворки и КАК делать проекты без них в разумные сроки и со вменяемым качеством. Да, компании тратят миллиарды. Но не думал ли автор о том, что зарабатывают они ещё больше? А то знаю я эту логику "отдел рекламы зарабатывает деньги компании, а ИТ отдел только тратит". Если бы не ИТ отдел, то рекламщикам и продавать было нечего - у таких людей забывается.
Честно говоря, я совершенно не фронтендер, но мне крайне знакомо и понятно мнение, которое Вы изложили, среди разработчиков уставших от бесконечного хайпа новых технологий и наивному желанию новичков вписываться во всё без разбора. Да что там, я со своим опытом в 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 мастерским владением языком программирования, а прежде всего в том, чтобы решать проблемы, какими бы порой странными эти решения нам самим не казались. Выбор всегда должен быть взвешен и, желательно, не только техническими специалистами. А идеальные решения... Их просто не бывает, за всё приходится платить :)
Скоро можно будет отказаться от всего :) так как в релиз почти вышел Compose for Web/Desktop
https://compose-web.ui.pages.jetbrains.team/
Так что не придется писать на чистом js
наивность автора похоже не знает границ, не от хорошей жизни появился ангуляр
Не могу назвать себя знатоком всей глубины этой темы.
И самому не нравится, что частенько случайно увиливаю в backend работая с ангуляром и т.п. пытаясь написать что-то простое, но в тайпскрипте, да ещё интегрировав для чтения данных всем остальным данным.
Но! Есть одно большое но, из-за которого я и начал пользоваться Ангуляром (сейчас, правда я почти всё делаю на Vue, но не суть) - это структуризация данных. Для меня очень удобно раскладывать на полочки css/scss, разбив их на уровни, темы и дизайны. Мне удобно, что я верстая страницу, могу не обращать внимание на код, который мне не нужен в данный момент (сайдбар, новости и т.п.) и от него лежит лишь "красивая" строчка подключения. Что мне не нужно генерировать шаблоны внутри JS кода. Что я могу спокойно (ну относительно) проследить какие страницы используют какой дизайн. И что кусок кода не мешается при всех прогрузках страницы, лишь раз и о нём забывается.
Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик
Вау! Звучит круто! Жаль автор не привел примеров своего кода в подтверждение этих слов :))
неплохо автор набросил ) видел эту статью в англоязычном интернете
у фронтэнда есть проблема - он не нужон. Большинство сейчас делает на своем Реакте просто интерактивную вьюшку. Такие вещи работали прекрасно и в "старом вебе" без фронтэндеров. Но если вы пойдете писать приложение, которое работает и выглядит именно как приложение, а не как сайтик, который "по модному" подгружает странички, вы поймете что Ангуляр, к сожалению, на сегодня - это единственное вменяемое решение
Хотя, он не дает вменяемого ответа на то, что делать с бизнес логикой, с той самой Моделью, но хотя бы слои инфраструктурной и прикладной логики, а так же вьюшки он обеспечивает
Пришло время избавиться от Angular и сэкономить миллиарды долларов