Видим, что AngularJS развивался с 2010 по 2017 и поддерживался по-крайней мере до 2021. Так уже для тех, кто сделал на него ставку в 2010-2011, критерий выполняется.
Внедрять ангуляр в компании где у большинства нет опыта разработки на нём
Не совсем так. Опыт AngularJS в некоторых командах был. Это конечно не Angular, но всё равно не с нуля. Внедрение шло постепенно, начиная с новых проектов. Так уж боли не было. Кроме того раз в несколько лет приходится и существующие интерфейсы переписывать, например при масштабном редизайне, и что в это случае будет быстрее, ещё вопрос.
CMS-ки отлично подходят там, где нужно создавать много шаблонного контента. Например для сайта mango-office.ru используется 1C Bitrix, и это оправдано. В остальных продуктах такого нет, в них разработка любого раздела превращается полностью в самописный код. т.е. Wordpress начинает использоваться как фреймворк по аналогии с Laravel или Symfony. Но в этом качестве он явно не лучше последних.
Первый коммит в репозиторий $mol быль сделан в мае 2016, к этому моменту оригинальное исследование уже было завершено, поэтому фреймворк физически не мог оказаться в списке рассматриваемых.
Вообще, ваш выбор в пользу разработки собственного решения довольно смелый. Для компаний это не всегда применимо.
Середина десятых годов была удивительным временем для фронтенд фреймворков. Многие "старички", проверенные временем уходили на пенсию, а "новичков", подающих надежду, было множество. Какой из них выдержит конкуренцию - вопрос. В этом и состояла сложность и интересность выбора.
Если статью воспринимать только как сравнение технологий 2016 года, то соглашусь, конечно, устарела :) Но я старался больше сделать акцент на методологии, на подходах и посмотреть как спустя годы это себя показывает. Например, в большинстве статей о сравнении технологий я не встречал описания, как собираются критерии. Зачастую они даже не взвешиваются. Учитываются ли при этом интересы бизнеса? Не понятно.
Кроме того, редко увидишь и хороший анализ рисков, просто потому, что в них опускаются риски не технологического характера.
Если говорить про одновременное использование Angular и React, то для более-менее крупной компании использование только одной технологии - большой риск. Все яйца в одну корзину не складывают. К тому же, React хорошо подходит в определённых ситуациях (например, для точечного улучшения крупного fullstack приложения). И почему бы им не воспользоваться?
Из сложностей можно дополнить следующее:
- Отсутствие опыта Angular у сотрудников этапе. Из-за этого местами некачественный код и решения, которые затем переписывались. - Мало готовых компонентов в 2016-2017. Приходилось брать из разных библиотек из-за чего UX от одного контрола к другому мог сильно отличаться. - Где-то года через 2-3 на передний план вышла проблема, что сторонние компоненты не поддерживают новых версию Angular, т.к. перестали развиваться (за частую их просто бросили). В итоге мы намучились и решили делать свой UI kit.
Кстати, да, человек с опытом Java или .NET пишет на Angular как на родном. Порог входа для них ниже, чем в React.
Видим, что AngularJS развивался с 2010 по 2017 и поддерживался по-крайней мере до 2021. Так уже для тех, кто сделал на него ставку в 2010-2011, критерий выполняется.
Не совсем так. Опыт AngularJS в некоторых командах был. Это конечно не Angular, но всё равно не с нуля. Внедрение шло постепенно, начиная с новых проектов. Так уж боли не было. Кроме того раз в несколько лет приходится и существующие интерфейсы переписывать, например при масштабном редизайне, и что в это случае будет быстрее, ещё вопрос.
CMS-ки отлично подходят там, где нужно создавать много шаблонного контента. Например для сайта mango-office.ru используется 1C Bitrix, и это оправдано. В остальных продуктах такого нет, в них разработка любого раздела превращается полностью в самописный код. т.е. Wordpress начинает использоваться как фреймворк по аналогии с Laravel или Symfony. Но в этом качестве он явно не лучше последних.
Первый коммит в репозиторий $mol быль сделан в мае 2016, к этому моменту оригинальное исследование уже было завершено, поэтому фреймворк физически не мог оказаться в списке рассматриваемых.
Вообще, ваш выбор в пользу разработки собственного решения довольно смелый. Для компаний это не всегда применимо.
Середина десятых годов была удивительным временем для фронтенд фреймворков. Многие "старички", проверенные временем уходили на пенсию, а "новичков", подающих надежду, было множество. Какой из них выдержит конкуренцию - вопрос. В этом и состояла сложность и интересность выбора.
Если статью воспринимать только как сравнение технологий 2016 года, то соглашусь, конечно, устарела :) Но я старался больше сделать акцент на методологии, на подходах и посмотреть как спустя годы это себя показывает. Например, в большинстве статей о сравнении технологий я не встречал описания, как собираются критерии. Зачастую они даже не взвешиваются. Учитываются ли при этом интересы бизнеса? Не понятно.
Кроме того, редко увидишь и хороший анализ рисков, просто потому, что в них опускаются риски не технологического характера.
Если говорить про одновременное использование Angular и React, то для более-менее крупной компании использование только одной технологии - большой риск. Все яйца в одну корзину не складывают. К тому же, React хорошо подходит в определённых ситуациях (например, для точечного улучшения крупного fullstack приложения). И почему бы им не воспользоваться?
Из сложностей можно дополнить следующее:
- Отсутствие опыта Angular у сотрудников этапе. Из-за этого местами некачественный код и решения, которые затем переписывались.
- Мало готовых компонентов в 2016-2017. Приходилось брать из разных библиотек из-за чего UX от одного контрола к другому мог сильно отличаться.
- Где-то года через 2-3 на передний план вышла проблема, что сторонние компоненты не поддерживают новых версию Angular, т.к. перестали развиваться (за частую их просто бросили). В итоге мы намучились и решили делать свой UI kit.