Comments 32
Это не вес, а количество звезд на GitHub). На самом деле, мне нравится и Vue и Angular.
Я не топлю за определенный фреймворк и не стараюсь "обратить в свою веру". Просто рассказываю что вы можете получить при переходе на Angular. Разумеется, у Vue есть свои плюсы, я говорю о них в самом начале статьи.
Vuex — это отдельный пакет для управления состоянием, во Vue его по умолчанию нет. В Angular ничего такого тоже нет, потому я про это ничего не написал. Расскажите пожалуйста про первые 5 пунктов во Vue. Разве это есть "из коробки"? Я хотел особенно подчеркнуть, что в Angular уже это все есть, на этом основана архитектура и паттерны решения проблем. Все это ведет к общим практикам.
В таком случае вопрос переходит в другой разряд. Типа Vue и Angular со всеми возможностями. Vuex и NgRx и другое. Вообще я не вижу смысла делать такое сравнение. Хотел просто показать что можно получить "на базовом уровне".
vuejs.org/v2/guide/state-management.html
Сравнить официальную библиотеку для Vue с неофициальной для Angular? Звучит не очень логично. По умолчанию в Angular предлагается хранить данные в сервисах, а не в Store. Если сравнивать в принципе два подхода, то это тема для отдельной статьи, но и тут я смысла особого не вижу. Нужно пользоваться тем, что удобно в вашем случае. Даже если я "докажу", что один подход более эффективен, то это же не будет причиной переходить на новый фреймворк, верно?
Усреднённый энтерпрайз с гарантированым средним уровнем.
Это не хорошо и не плохо, это особенность.
ЗЫ Ну и, мне кажется, не стоит всё же сравнивать фреймворк с библиотеками.
Здесь не могу согласиться. Да, конечно, Angular реализуют бОльшую часть логики приложения, но это не значит, что вы не должны разбираться как работают классы и те же декораторы. У меня есть много коллег, которые пишут много классных вещей на Angular и для Angular, например https://habr.com/ru/users/waterplea/posts/. Для этого необходимо не только хорошее знание и понимание фреймворка, но и самого языка.
Отдельно хотел бы сказать, что Angular реализует множество паттернов, применимых в принципе к программированию, например, Dependency Injection. Поэтому, Angular может принести пользу не только во фронтенде.
Angular предоставляет инструменты реализующие общепринятные паттерны.
Если приглядеться, то Angular очень похож на тот же Spring boot из java.
Конечно, если нормально не изучив язык программирования сразу браться за angular, то знать будешь только angular.
Но если хорошо знать основы ЯП, паттерны проектирования, структуры данных, алгоритмы, тогда любые фреймворки/библиотеки не будут вызывать сложностей в изучении и понимании.
Не соглашусь.
У обычного человека есть время что-то изучать только на работе. Ты узнаешь что-то новое тогда и только тогда, когда на работе появится задачка, требующая изучения. Дома, ясное дело, остается времени сгонять катку в доту, поесть и поспать.
Поэтому очень-очень хорошо, когда на работе сама жизнь заставляет пробовать тебя сотни фреймворков и переписывать много раз одно и то же с разными подходами. Это получается полноценное непрерывное обучение — и тебе за него платят деньги! Если же есть какой-то условный 1С, где всё уже придумано, то жизнь может превратиться в непрерывную деградацию.
Понятно, что часов у тебя в любом случае 8, и значит развиваться ты всё-таки будешь — но в каком-то другом деле. Например, в бизнес-области: работая в банке будешь глубоко разбираться в банковской сфере и слабо — в низкоуровневом программировании и создании фреймворков.
Лично я всю жизнь (ту ее часть, когда хотел расти как программист) очень хотел заниматься именно разработкой инструментов для программистов, написанием фреймворков, итп — и ни в коем случае не конечных продуктов. В крайнем случае, разработкой архитектур продуктов. Конечные продукты — это скучно. Использование полностью готового фреймворка не кажется хорошей идеей в этой концепции, потому что на работе ты слишком много времени будешь уделять вещам, которые тебя никак не развивают.
У обычного человека есть время что-то изучать только на работе.
Не соглашусь, у меня и у моих коллег находится время изучать новое и еще писать статьи :)
Дома, ясное дело, остается времени сгонять катку в доту, поесть и поспать.
У всех разные увлечения, я в доту не играю.
потому что на работе ты слишком много времени будешь уделять вещам, которые тебя никак не развивают
Жаль, что у вас сложился такой опыт.
Я сам стараюсь развиваться и в рабочее и вне рабочего времени, как и мои коллеги.
Итого, люди разные, с разными возможностями и мотивацией, так что не стоит под «обычных людей» подписывать всех, кто не имеет возможности развиваться на работе и у кого нет желания развиваться вне работы.
У меня, тогда, встречный вопрос:
Если не нужно что-то такое, о чём разработчики ангуляра не подумали за вас. И да, если вы развиваетесь так, как они придумали и всегда можете объяснить бизнесу «вот эта штучка противоречит политике фреймворка, так что нет»
Можете привести пример штук, противоречащих политике фреймворка? Я бы сказал, чо разработчики Ангуляр подумали за нас только в очень глобальных вопросах, скажем, в роутинге, в остальных же случаях они оставили нам полную свободу действий и я не могу сходу назвать ситуацию, которую вы озвучили.
Я работаю над библиотекой UI компонентов и если добавить в веб компоненты DI и проверку изменений, то практически всё, что я делаю можно без особого труда в них перенести не сильно меняя код.
Ага, понятно. Если заниматься задачами такого рода, то да, действительно здорово похоже. Я имел в виду обычную, «дженерик» разработку — мидлов, клепающих формы в рамках предустановленной архитектуры.
Впрочем, заранее соглашусь, что если человеку не интересно, что там внутри и почему, то среда не важна (и ангуляр тут в плюс, потому что не даёт совсем уж наговнокодить).
Противоречащие штуки — да пожалуйста. Мне нужен кастомный билд конвеер (он есть, он не работает так, как нужно). Мне нужен свой роутинг, свой бандлинг и свой бутстраппинг. Не от хорошей жизни, поверьте.
Да, не типовые случаи — ну я и сказал, что для типовых обычно есть типовое решение.
Никаких «я пишу на Angular» тут нет. Это тот же самый js, только обычно мы работаем с ним через абстракции фреймворка, но всегда есть возможность сделать напрямую, а лучше написать свою абстракцию.
Мне нравится, что в Angular я могу контролировать эти вещи, в том числе и притащить такую же магию, впрочем в React можно так же.
Хотел бы написать свое мнение на данную статью, на мой взгляд весьма однобокую в сторону Angular
Просто момент бросившийся в глаза, во Vue тоже так можно сделать? От чего такое акцентирование на angular?
<!-- В Angular можно указать едичный динамический класс -->По статье создается впечатление, что чем больше ограничивают разработчика и больше впихнут в проект тем лучше(не хейт angular, nestjs на его основе шикарен).
По пунктам итога:
- Не используя angular не могу говорить конкретики насколько это нужно и оправдано не разделяя пакеты
- vue-router можно считать из коробки(как и vuex, о котором ни слова, но о фичах angular типа форм информация есть), формы не поспорю +очко ang, перехватчики и httpclient, субьективно не вижу смысла ограничивать разработчика, тот же axios(который используется в большинстве проектов) имеет и функцию перехватчиков и поддерживается огромным кол-вом людей
- Плагины к vue-cli если не ошибаюсь могут в том числе расширить функционал и до такого(хотя критичной нужды не вижу), но опять же, не преувеличенно ли значение создания файла с шаблонным контентом?
- Много ли кейсов которые не покрываются весьма простыми асинхронными vue-компонентами? Для store, есть аналог в виде динамических модулей
- Если RxJs обязателен для использования, опять же навязывание технологий, typescript, с ним у vue < 3.0 проблемы не поспорю, что он обязателен в angular, ну качество кода по-умолчанию будет выше, хотя порог вхождения новичкам тоже выше, поэтому +-
- Стандарты решают проблему
- Использование готовых решений для конкретной задачи решает проблему(минус — нужно время искать решения)
- Стандарты решают проблему
Хотел бы обратить внимание, что я не топлю за Angular. Я предлагаю Vue разработчикам рассмотреть что они могут получить, если перейдут на него. Например, они хотят пойти в Google и писать фронт там. У меня не было цели сравнить фреймворки, а скорее показать различия, чтобы было проще и быстрее понять принципы работы Angular.
Для меня одним из плюсов ангуляр является то что после него легко писать на Nestjs. Более того, он добавляется в проект одним кликом
Геттер, который заменяет вычисляемое значение. Его логика работы отличается от VueВы тут умолчали о том, что в примере на Vue у вас есть мемоизация и автоматическое вычисление зависимостей (благодаря Transparent Reactive Programming). В примере на Angular функция будет пересчитываться на каждый вызов Change Detection, что гораздо менее эффективно. Не говоря уже о том, что во Vue вам не нужно делать подписку на интервал вне Zone.js, а в Angular вы рано или поздно столкнётесь с необходимостью так делать. Я как-то добавлял таймер обратного отсчёта в Angular приложение, таймер был вверху дерева компонентов и на каждый тик триггерил CD рекурсивно у всех компонентов ниже. Тут ещё спасает OnPush, но во Vue это не нужно.
Он использует библиотеку для реактивного программирования RxJS, без которой также обойтись нельзя.Без RxJS можно прекрасно обойтись даже в Angular, посмотрите например Mobx-Angular. Я был на проекте, который писали фулстеки с уклоном в бекенд, и им было очень тяжело совладать с RxJS и его операторами, в коде были все возможные антипаттерны RxJS — вложенные подписки, отсутствие отписок, непонимание разницы между switchMap/mergeMap/concatMap и как следствие трудновоспроизводимые баги. Mobx зашёл на ура разработчикам из-за привычной модели программирования, писать код стало проще. Ну и вот возьмём ваш пример на RxJS, в нём ведь тоже есть проблемы:
— Лишний BehaviorSubject. Вместо того, чтобы считать количество кликов через оператор scan вы ввели состояние, которое мутируете вручную. Это императивный подход. Такой код люди пишут постоянно, потому что ломать голову операторами RxJS сложно.
— Подписка на интервал в шаблоне у вас скорее всего через async pipe, а это опять будет триггерить CD на каждый тик. На интервалы/таймеры нужно подписываться вне Zone.js
Вся эта ненужная сложность, отсутствие девтулзов и ещё вагон проблем с типизацией (она в Angular слишком щадящая) и побудили меня отказаться от этого фреймворка в пользу React.
Angular для Vue разработчиков