Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
Все хорошо расписано, есть один вопрос: не задумывался, как автоматизировать процесс добавления файлов в public-api.ts, просто компонентов, сервисов, модулей в либое может быть много. А добавлять все в ручную — сам знаешь, мы разрабы народ ленивый ;-)
Слышал про самурай — там через него генеришь компоннеты, модули, сервисы и добавляешь опцию прописать в public-api.ts, но тоже не очень удобное решение.
Может есть решение получше? Хоть самому садись и скрипт пиши :-))
Мы в подобных кейсах используем резолверы. Однако такой подход тоже интересен. Статья хорошая, еще можно было бы добавить подход с резолверами о осветить плюсы и минусы частных провайдеров и резолверов. Или это уже тема для отдельной статьи? ;-)
Вообще да, EventEmitter наследуется от Subject, я раньше запихивал BehaviorSubject в Output и не парился. Потом прочитал где-то, что команда Angular рекомендует использовать в Output только эмиттеры, вроде как для совместимости с более новыми, еще не вышедшими версиями Angular, так как не исключают добавление какой-нибудь специфичной логики в эмиттеры.
Присоединяюсь к комментарию. Данный подход к проектированию достаточно популярен, однако он больше нацелен на исключительно поведенческий вектор наращивания функционала. На практике же, в проектах если не преобладает, то по крайней мере имеет место быть структурный вектор наращивания функционала. То есть очень часто меняется набор полей у классов. Сам нахожусь в поиске элегантных архитектурных решений для реализации простоты структурных изменений.
Это из серии продать мак бук и уехать в испаноговорящую страну, где все сеньоры? :-)
Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
Слышал про самурай — там через него генеришь компоннеты, модули, сервисы и добавляешь опцию прописать в public-api.ts, но тоже не очень удобное решение.
Может есть решение получше? Хоть самому садись и скрипт пиши :-))