Привет, «Хабр», меня зовут Иван Матвиенко, я несколько лет отвечал за web‑технологии в Mango Office, а теперь занимаю должность руководителя направления разработки.
В статье хочу рассказать, как мы в Mango подошли к выбору единой технологии для фронтенда, с какими трудностями столкнулись и что в конце концов из этого вышло. Забегая вперед, скажу, что наш окончательный выбор пал на Angular.
История началась в уже далеком 2016 году. На тот момент основными технологиями были jQuery и библиотека виджетов jQuery UI, которые использовались в нашем самом крупном web‑приложении: Личном кабинете Mango Office. Еще один внутренний продукт был написан на ExtJS. Кроме того, некоторые команды экспериментировали с React и AngularJS. Однако использование этих фреймворков и библиотек носило хаотичный характер, и выбор конкретного подхода оставался на усмотрение команды. А о повторном использовании наработок одной команды в другой и речи не было. В связи с этой неопределенностью назрел вопрос унификации стека и выбора технологии для фронта, с которой мы будем жить долгое время.
Выбор технологии
Выбор технологии мы начали с формирования списка требований со стороны продуктовых и технических подразделений. В опросе участвовали отделы продуктов, бизнес‑анализа, системного анализа, разработки и тестирования. Первичный список критериев состоял из 31 одного пункта, после отбрасывания не влияющих на выбор осталось 19. Из них 12 были техническими и 7 — от бизнеса. Затем мы попросили подразделения расставить вес критериев по важности. Усреднив, получили вес каждого критерия.
Итоговый список:
Критерий |
Вес |
Кросплатформенность. Работа в приложениях на десктопах, смартфонах, планшетах, на платформах Android, iOS, Windows Phone. Работа с touch-устройствами |
8,3 % |
Производительность фреймворка при большом количестве данных |
8,3 % |
Легкая реализация кастомных элементов слоя представления |
6,8 % |
Полноценная документация |
6,3 % |
Базовое быстродействие (без нагрузки в виде большого количества данных) |
6,3 % |
Большая компонентная база |
6,3 % |
Доступность специалистов на рынке |
6,3 % |
Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален |
5,9 % |
Наличие инструментов отладка исходного кода, лёгкость локализации ошибок |
5,8 % |
Возможность реализации слоя представления в виде HTML-верстки |
5,6 % |
Низкий порог вхождения для новых сотрудников |
5,5 % |
Наличие механизмов для реализации unit- и авто-тестирования |
5,3 % |
Развитое сообщество |
5,0 % |
Развитая высокоуровневая базовая модель данных инструмента, наличие высокоуровневых шаблонов |
3,8 % |
Отсутствие необходимости программисту работы с DOM-моделью |
3,5 % |
Поддержка стандарта JavaScript ES6+ и TypeScript |
3,5 % |
Низкие трудозатраты при необходимости реализации нестандартных компонентов |
3,4 % |
Локализация приложения в различные иностранные языки |
2,7 % |
Отсутствие ограничивающих лицензий |
1,5 % |
Сейчас читателю часть критериев может показаться бесполезными, но семь лет назад они были актуальны.
Следующим шагом стало составление списка фреймворков и библиотек для сравнения. В него, с одной стороны, вошли уже используемые в компании, с другой, — лидеры рынка на тот момент. Часть исключили по блокирующим критериям: ограничениям лицензий, непригодности для решения наших задач и другим.
Что в итоге получилось:
AngularJS;
Angular 2;
Backbone;
ExtJS;
React+Backbone;
React+Redux.
От jQuery собирались уходить, поэтому в сравнение он не попал. Также в списке нет Vue. В те годы фреймворк был еще мало распространен, нам не хватало промышленных примеров удачного использования для его рассмотрения. Кроме того, он ничем не выделялся на фоне многочисленных аналогов.
В выборку мы включили Angular 2, потому что он воспринимался как новая версия популярного AngularJS. На момент исследования он находился на стадии Release Candidate. Официальный выпуск произошел осенью 2016, к тому моменту мы в Mango уже вели на нем разработку. Собственно, «молодость» фреймворка была основным риском использования технологии. Но та стратегия развития, которую озвучивала компания Google, и вкладываемые ей ресурсы послужили поводом добавить Angular 2 в наше исследование.
Оценку фреймворков по критериям осуществляли по пятибалльной шкале на основе двух факторов: экспертное мнение разработчиков и архитекторов компании, работавших с несколькими из перечисленных технологий, и публичные исследования и официальные стратегии развития фреймворков.
Итоговый балл вышел следующий:
Технология |
Средняя оценка с учетом веса критериев |
Angular 2 |
4,06 |
AngularJS |
4,00 |
React+Redux |
3,80 |
React+Backbone |
3,61 |
ExtJS |
3,57 |
Backbone |
2,27 |
В лидерах оказались Angular 2 и AngularJS, и выбор склонялся в пользу первого. Делать ставку на AngularJS было бы не прагматично: Angular 2 приходил ему на смену. Но все же мы явно выписали ключевые риски использования Angular:
Проект быстро закончит развиваться.
Проект будет долгое время нестабильным.
Не было готовых специалистов со знанием стандарта ES6 и языка TypeScript.
Не было хорошей документации.
Не было готовых сторонних компонентов.
Мы приняли эти риски. Angular стал в Mango основной технологией.
Второй этап оценки
Через год мы вернулись к оценке Angular. Хотелось еще раз свежим взглядом оценить, правильно ли был выбран вектор развития. Я вышел на исследование популярности web-технологий от аналитического агентства Developer Nation, выпущенное весной 2017.
Из данных исследования вытекало, что обеими версиями Angular в мире пользуется больше разработчиков, чем React: 21% против 9%. Это удивительно, так как по популярности в статьях и оценках на GitHub напрашивался противоположный вывод.
Также выяснилось, что Angular в большей мере предпочитают разработчики с опытом в Enterprise‑технологиях, таких как Java или.NET. Это стало еще одним плюсом в пользу нашего выбора.
Внедрение: сложности и решения
Внедрение фреймворка мы начали в двух продуктовых командах. Они активно развивали новые сервисы, и использование новой технологии для них было проще всего. В главном web‑проекте — личном кабинете Mango Office — перейти на новую технологию с наскока не получилось бы. В этом продукте внедрять Angular мы начали спустя несколько лет, после того как накопили опыт в других командах.
Личный кабинет Mango Office — это большое фулстек‑приложение с бэкендом на PHP и фронтендом на jQuery. У него длинная история — больше 15 лет. Внедрить фронтенд технологии было непросто. Мы стали двигаться в двух направлениях: новые модули стали писать уже на Angular, а в текущем личном кабинете постепенно отказывались от jQuery в пользу React, тем более что пробное использование React уже было запущено. Мы переписывали виджеты с jQuery на React, что позволило постепенно улучшать интерфейс, не уходя надолго в рефакторинг кабинета.
Внедрению фронтенд‑технологии сопутствовали изменения в бэкенде. Бэкенд также переписывался на микросервисы, в которые выносилась ключевая бизнес‑логика. Фронтенд всегда шел за бэкендом. Перенос бизнес‑бизнес логики — дело не быстрое, поэтому и перевод фронта на новую технологию шел не тем темпом, как хотелось бы.
Разумеется, в компании есть продукты, где внедрение такого крупного фреймворка, как Angular, было нецелесообразно. В первую очередь, к ним относятся виджеты, которые встраиваются на сайты клиентов и плагины для других систем (например, CRM). Там мы оставили использование более легковесных Vue и React, а в последствии частично перешли на чистый JavaScript.
Микрофронтенды
Данная тема заслуживает отдельной статьи, затрону ее здесь кратко. На определенном этапе мы пришли к тому, что разработку личного кабинета Mango Office должны вести разные продуктовые команды. На бэкенде благодаря микросервисной архитектуре разделение ответственности между командами произошло легко. На фронте пришлось внедрять микрофронтенды.
Архитектуру микрофронтендов построили на базе модуля Federation @angular‑architects/module‑federation. Большинство разделов начали встраивать как микрофронтенды. Бонусом такого подхода стало то, что мы смогли гладко встроить в единое приложение модули, написанные на React. Для этого оказалось достаточно завернуть React‑приложение в Angular‑обертку. Над разработкой модулей‑микрофронтендов теперь могли работать разные команды.
Дизайн-система и библиотека компонентов
Внедрение единой технологии для фронтенда упростило внедрение корпоративной дизайн‑системы в web‑проекты. Разные команды годами пользовались разными библиотеками компонентов. Это усложняло пользовательский опыт и приводило к лишним трудозатратам по унификации UX/UI.
Пару лет назад мы приступили к разработке общей для всей компании библиотеки собственных компонентов в едином стиле Mango. На текущий момент вырос большой UI‑kit на Angular и чуть поменьше на React. Этих библиотек хватает для разработки типового интерфейса в личном кабинете Mango Office.
В будущем, возможно, мы выложим наши наработки по дизайн‑системе в открытый доступ.
Результаты
Подведем итоги за семь лет.
Большая часть фронтовых команд использует Angular. Треть продолжает писать на React, Vue и чистом JavaScript. Кому‑то большой фреймворк не подходит, кому‑то нужен чистый JS. Также остается один старый внутренний проект на ExtJS.
Риски, которые мы принимали, выбирая Angular, не сработали.
Разберем результаты:
Проект закончит развиваться. Технология развивается и поддерживается крупными вендорами. На нем написано уже столько кода, что в ближайшие годы окончание поддержки не предвидится.
Нехватка готовых специалистов. Специалистов со знанием Angular на рынке труда достаточно. Среднее время поиска меньше, чем для бэкендеров. Я считаю, это хороший показатель.
Слабое сообщество, документация, мало сторонних библиотек. Сообщество развито, много литературы, оригинальных решений, сторонних библиотек и пр. Конечно, для React всего этого в разы больше, зато для Angular качество в среднем выше.
Какие плюсы мы получили от использования единой технологии:
Angular оказался большим фреймворком, способным закрыть многие потребности команд. Использовать сторонние библиотеки и компоненты приходится редко.
Из первого пункта вытекает простота обновления версий базового фреймворка во всех проектах, что позволяет нам идти в ногу со временем. К использованию единой версии мы еще не пришли, но сделать это в будущем будет не трудно.
Сокращение трудозатрат и унификация интерфейсов за счет единой технологии и дизайн‑системы.
Но не все надежды оправдали ожидания. Главный минус — распространение технологии в проектах идет не так быстро, как хотелось бы, и до сих пор не завершено. Причина — не в выбранной технологии, а в том, что переписывание многолетней кодовой базы не всегда целесообразно и рентабельно. Приходится, так сказать, есть слона по кускам.
Послесловие
Я постарался осветить опыт, который компания Mango Office накопила на пути внедрения единой технологии для фронтенда. Моей целью было продемонстрировать, что унификация влечет больше плюсов, чем минусов. Мы начинали с целого «зоопарка» устаревших технологий и пришли к желаемому единообразию. Выбор Angular себя полностью оправдал. Этот фреймворк достоин быть корпоративным стандартом.
Возможно у вас есть истории — успешные или не очень — о внедрении нового фреймворка. Расскажите в комментариях, будет интересно сравнить ваш и наш опыт.
Подписывайтесь на наши соцсети:
Аккаунты Mango Office
ВКонтакте: https://vk.com/mangotelecom
Телеграм: https://t.me/mango_office
Комментарии (49)
Safort
00.00.0000 00:00+2Кажется, эта статья на момент выхода уже является устаревшей. Критерии, по которым вы выбирали тогда, к 2023 поменялись несколько раз. Более того, после выбора Angular вы всё равно где-то используете тот же React.
В подобных статьях наибольшую полезность имеют конкретные технические сложности с которыми столкнулись и решения, которые использовали.
ivm7
00.00.0000 00:00+2Если статью воспринимать только как сравнение технологий 2016 года, то соглашусь, конечно, устарела :) Но я старался больше сделать акцент на методологии, на подходах и посмотреть как спустя годы это себя показывает. Например, в большинстве статей о сравнении технологий я не встречал описания, как собираются критерии. Зачастую они даже не взвешиваются. Учитываются ли при этом интересы бизнеса? Не понятно.
Кроме того, редко увидишь и хороший анализ рисков, просто потому, что в них опускаются риски не технологического характера.
Если говорить про одновременное использование Angular и React, то для более-менее крупной компании использование только одной технологии - большой риск. Все яйца в одну корзину не складывают. К тому же, React хорошо подходит в определённых ситуациях (например, для точечного улучшения крупного fullstack приложения). И почему бы им не воспользоваться?
Из сложностей можно дополнить следующее:
- Отсутствие опыта Angular у сотрудников этапе. Из-за этого местами некачественный код и решения, которые затем переписывались.
- Мало готовых компонентов в 2016-2017. Приходилось брать из разных библиотек из-за чего UX от одного контрола к другому мог сильно отличаться.
- Где-то года через 2-3 на передний план вышла проблема, что сторонние компоненты не поддерживают новых версию Angular, т.к. перестали развиваться (за частую их просто бросили). В итоге мы намучились и решили делать свой UI kit.
nin-jin
00.00.0000 00:00-5Тем временем в параллельной вселенной:
$mol не даёт неопытным сотрудникам говнокодить, приучая к хорошим практикам.
Уже в 2016 году в $mol было больше стандартных компонент с единым UX, чем в любом другом UI-Kit написанными сторонними людьми для Ангуляра.
И с тех пор они никуда не делись, не перестали поддерживаться, не сломали обратную совместимость.
И сделать на их основе свой UI Kit в своём дизайне можно было без каких-либо мучений.
Но кому какое до этого дело? Давайте минусовать комментарии, игнорировать вопросы и клеветать про токсичность - так победим.
dopusteam
00.00.0000 00:00+4Я думаю все ждут примеры сайтов на $mol, написанные не автором
Ну и мб отзывов о $mol не от автора :)
nin-jin
00.00.0000 00:00-4То есть вместо того, чтобы думать своей головой, все ждут, что за них это сделает кто-то другой?
DarthVictor
00.00.0000 00:00+1То есть вместо того, чтобы думать своей головой, все ждут, что за них это сделает кто-то другой?
Ага. По научному это называется проектный менеджмент.
alexshipin
00.00.0000 00:00Да этого не будет. Проект $mol выглядит интересно, но подвержен правилу "идея отличная, реализация - как всегда"
Dolios
00.00.0000 00:00+4и клеветать про токсичность
Я вот ваши комментарии почитал тут и могу сказать, что они очень токсичные. А ещё могу сказать, что, посмотрев на главного разработчика и его манеру общения, $mol теперь даже смотреть не пойду и точно буду против, если кто-то другой предложит его использовать.
nin-jin
00.00.0000 00:00-4Жили-были два соседа. Один жил хорошо. Другой - чуть похуже. Второй завидовал первому. Пришел он к Богу с просьбой, мол дай мне столько же, сколько есть всего у моего соседа. И ответил Бог, что выполнит эту просьбу. Но при одном условии - соседу просителя он даст в два раза больше. И тогда просящий сказал - выколи мне глаз.
Клевета не в мой адрес, а в адрес людей пишущих на $mol. А вообще, всегда забавно слышать от практикантов культуры отмены претензии в токсичности. Тут или крестик снимите, или штаны наденьте.
vasek07
00.00.0000 00:00А что не так с Wordpress (темы/компоненты + плагины) - бэкенд (Wordpress API, mySql, php) - громадное сообщество, открытый код, платных плагинов любой степени сложности навалом. Если проекты не супер highload - собирается все что угодно (простой и удобный конструктор).
ivm7
00.00.0000 00:00CMS-ки отлично подходят там, где нужно создавать много шаблонного контента. Например для сайта mango-office.ru используется 1C Bitrix, и это оправдано. В остальных продуктах такого нет, в них разработка любого раздела превращается полностью в самописный код. т.е. Wordpress начинает использоваться как фреймворк по аналогии с Laravel или Symfony. Но в этом качестве он явно не лучше последних.
zhulan0v
00.00.0000 00:00Внедрять ангуляр в компании где у большинства нет опыта разработки на нём - боль и мина в плане расходов в будущем на выпиливание огромного кол-ва говнокода. Хотя бы лиды или сеньоры должны обладать хорошим опытом на фреймворке, чтобы держать в узде остальных. Хотя если темп разработки низкий, как это часто бывает, то наверное это не будет большой проблемой. И да, в тот момент выбора было не очень много по всей видимости ;)
ivm7
00.00.0000 00:00+1Внедрять ангуляр в компании где у большинства нет опыта разработки на нём
Не совсем так. Опыт AngularJS в некоторых командах был. Это конечно не Angular, но всё равно не с нуля. Внедрение шло постепенно, начиная с новых проектов. Так уж боли не было. Кроме того раз в несколько лет приходится и существующие интерфейсы переписывать, например при масштабном редизайне, и что в это случае будет быстрее, ещё вопрос.
Gugic
00.00.0000 00:00Мы когда-то очень плотно работали с ангуляром, а сейчас, на новом месте с новым проектом решили все-таки взять реакт просто потому что сильно меньше проблем с поиском новых разработчиков с готовым опытом.
Но по личному опыту видится что ангуляр сильно более, как в русских деревнях говорят, opinionated и это помогает что в равитии что в поддержке проекта.
Еще он очень помогает энтерпрайзным бекендщикам (коим я также был) чувствовать себя как дома.
ivm7
00.00.0000 00:00+1Еще он очень помогает энтерпрайзным бекендщикам (коим я также был) чувствовать себя как дома.
Кстати, да, человек с опытом Java или .NET пишет на Angular как на родном. Порог входа для них ниже, чем в React.
nin-jin
Ну и дежурный вопрос: почему $mol, который в то время пиарили по всему Хабру, не попал даже в список кандидатов? Вот, я прошёлся по вашему чек-листу, что дало средний балл 5.2:
✅ Кросплатформенность. Работа в приложениях на десктопах, смартфонах, планшетах, на платформах Android, iOS, Windows Phone. Работа с touch-устройствами
✅ Производительность фреймворка при большом количестве данных
✅ Легкая реализация кастомных элементов слоя представления
❌ Полноценная документация
✅ Базовое быстродействие (без нагрузки в виде большого количества данных)
✅ Большая компонентная база
✅ Доступность специалистов на рынке
✅ Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален
✅ Наличие инструментов отладка исходного кода, лёгкость локализации ошибок
❌ Возможность реализации слоя представления в виде HTML-верстки
✅ Низкий порог вхождения для новых сотрудников
✅ Наличие механизмов для реализации unit- и авто-тестирования
❌ Развитое сообщество
✅ Развитая высокоуровневая базовая модель данных инструмента, наличие высокоуровневых шаблонов
✅ Отсутствие необходимости программисту работы с DOM-моделью
✅ Поддержка стандарта JavaScript ES6+ и TypeScript
✅ Низкие трудозатраты при необходимости реализации нестандартных компонентов
✅ Локализация приложения в различные иностранные языки
✅ Отсутствие ограничивающих лицензий
danilovmy
Вероятно потому что:
❌ Полноценная документация
❌ Возможность реализации слоя представления в виде HTML-верстки
❌ Развитое сообщество
✅ Токсичность пишущих на $mol
nin-jin
Вам не стыдно клевету репостить?
alexshipin
ну почему же клевета? как раз-таки наоборот, более правдивое положение дел фреймворка
nin-jin
Либо приводите подтверждения, либо следите за языком.
jetteim
https://www.youtube.com/watch?v=iywaBOMvYLI
ivm7
Первый коммит в репозиторий $mol быль сделан в мае 2016, к этому моменту оригинальное исследование уже было завершено, поэтому фреймворк физически не мог оказаться в списке рассматриваемых.
Вообще, ваш выбор в пользу разработки собственного решения довольно смелый. Для компаний это не всегда применимо.
Середина десятых годов была удивительным временем для фронтенд фреймворков. Многие "старички", проверенные временем уходили на пенсию, а "новичков", подающих надежду, было множество. Какой из них выдержит конкуренцию - вопрос. В этом и состояла сложность и интересность выбора.
radtie
✅ Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален
Ну да, ну да:
Поставить будущее своей компании в зависимость от одного единственного стороннего разработчика, отличный план, надежный как...
nin-jin
Кто не знает историю, обречён на её повторение.
ivm7
Видим, что AngularJS развивался с 2010 по 2017 и поддерживался по-крайней мере до 2021. Так уже для тех, кто сделал на него ставку в 2010-2011, критерий выполняется.
nin-jin
AngularJS просуществовал меньше, чем уже существует $mol. При этом те, кто поставил на него будущее своей компании в 2015 году был вынужден уже через 2 года переписать проект полностью на чём-то другом. Те, кто по умнее, соскочили с него на Вью. Кто по глупее - на Реакт. Остальные же решили повторить с сырым до 10 версии Ангуляром с прекрасной поддержкой, чинящей баги в базовой функциональности годами.
dopusteam
А те кто поставил но $mol (кстати, есть такие?), постоянно получает от автора советы вида "код $mol открыт, если что то не работает, работает неправильно или не реализовано - вы можете сделать это сами"?
Тут есть доля передергивания, но это прям как в примере про ангуляр выше
nin-jin
Ага, а если что то не работает в Ангуляре, работает неправильно или не реализовано - вы **не сможете** сделать это сами и будете лепить костыли, надеясь, что через 5 лет это поправят.
dopusteam
Может мне повезло, но за ~10 лет ангуляра не помню ни одного случая, когда я б напарывался на баги ангуляра.
А вот почти в каждой статье про mol$ находится баг (или недоработка), на который поступает предложение поконтрибьютить и сделать самому, либо поступает ответ "вам это не нужно"
Но иногда, справедливости ради, бывает что выкатывается новая версия с правкой
nin-jin
Берём первый попавшийся компонент Select и выведем в него список городов. Найти в нём, например, Дакоту - задача не из простых. Как быстро вы прикрутите туда поиск? Как скоро вы дождётесь прикручивания туда поиска от вендора? Ещё через 10 лет? Для сравнения $mol_select.
dopusteam
https://material.angular.io/components/autocomplete/overview
Вроде есть что то готовое.
К тому же, можно взять другой набор компонентов, не материалом единым. Не понимаю как это связано с проблемами ангуляра
nin-jin
Автокомплит совсем о другом.
Ну да, найти другой набор, потом мучиться с приведением к единому стилю, потом бояться обновлять мажорную версию фреймворка. Никаких проблем.
dopusteam
О чем автокомплит? Чем он не устраивает?
Все в едином стиле, не знаю, что не так там. Бояться не нужно, что то не встречал проблем. И повторю, ангуляр не ограничен материалом.
nin-jin
Не знаю, чем вы занимались 10 лет на Ангуляре, но я бы рекомендовал вам записаться на курсы UX, чтобы понимать основы разработки интерфейсов и разницу между разными контролами в частности. Конкретно по этим, ключевая разница в следующем:
Выходное значение селекта - не то, что видит пользователь, это даже не обязательно строка.
Пользователь не может ввести невалидное значение, что избавляет от необходимости его нормализации и валидации.
При открытии селекта экранная клавиатура его не перекрывает, так как поиск не является основным сценарием.
В принципе, без разницы будете ли вы пытаться к селекту прикручивать поиск, или из автокомплита делать селект. На Ангуляре это одинаково больно. На любом UI Kit.
dopusteam
Все это звучит странно как то.
Так же как и автокомплит.
Чего? Автокомплит тоже не позволяет ввести что то свое
Это где такое определение есть? Или это какое то сакрально знание, которое "и так понятно"?
bromzh
Забавно, вы тут ниже предлагали пользоваться своей головой. Давайте последуем совету, поищем 1 минуту, и возьмём для больших селектов более подходящий компонент. Дакоту там искать просто, сами попробуйте.
Вы не заметили его? Или осознанно высосали проблему из пальца? Ну и конечно, отличный манёвр, ушли от ангуляра к сторонней UI библиотеке. Хоть и от тех же авторов, но таки сторонней, ведь ангуляр не тянет с собой её, и у ангулярщиков есть выбор UI-китов, в отличие от.
nin-jin
Продолжайте думать, и обязательно додумаетесь, почему эти два разных компонента с совершенно различной функциональностью до сих пор не объединили в один.
$mol вообще ничего не тянет с собой, в отличие от.
bromzh
autocomlete без возможности выбрать/ввести что-то не из списка == dropdown/select с фильтрацией. Prove me wrong.
Но если уж убеждения не позволяют взять autocomplete вместо select, то можно заблаговременно взять ui-kit побольше, чем ущербный material, благо их много. Вообще, докапываться до недостатков material, это как обижать ребёнка - показать над ним превосходство просто, но со стороны выглядит не очень.
bromzh
Ваще мимо, вы можете лучше.
Angular 2 вышел в 2016, а поддержка первого закончилась в 2022. 8 лет поддержки старья - хороший срок. Да и умер первый не молча, команда ангуляра выпустила инструменты и подробдые гайды как мигрировать с одного на другое. Ну и самое главное отличие - у ангуляра bus-factor большой, там много разработчиков, у моля же он равен одному.
nin-jin
Поддержка - громко сказано. Особенно показателен случай, когда эта чудесная поддержка безрассудно сломала обратную совместимость в минорной версии, на что поднялся вой и они откатили. Гайды по миграции - тоже громко сказано. Архитектуры совсем разные - вся миграция заключалась в полном переписывании.
bromzh
Я, кстати, знаю, почему никто не берёт mol. В то время, как во всех популярных библиотеках и в самом языке везде camelCase, в mol пошли своим путём, и используют snake_case. Итоговый код будет выглядеть кашей из разных стилей (вон и в исходниках так: 1, 2, и т.д.), что будет задевать чувство прекрасного у использующих его людей. Ну и линтер/форматтер надо дольше настраивать.
nin-jin
В $mol технические решения имеют обоснование, в то время как остальные придерживаются карго-культа. А линтер/форматтер не надо настраивать для имён, не выдумывайте.
bromzh
Увидел там только вкусовщину (мне snake_case читать труднее) и попытку оправдаться
Ну то есть не баг, а фича, ага. Зачем отличать одно от другого, чтобы что?
Хз как у вас (в проекте не увидел линтера вообще, найс), но у меня на каждом проекте есть naming convention, который чекается линтером, чтобы не получалось плохочитаемая мешанина, когда работают много людей вместе. И в конфиге линтера стоит ошибка для snake_case. И если я вдруг захочу отнаследоваться от класса, в имени которого (или в его полях и методах) есть snake_case, то линтер будет ругаться. В таких случаях надо отключать линтер на эти строки, что на самом деле тупо. Так что настраивать таки надо, не выдумывайте, что я выдумываю.
Gugic
Мы тут между ангуляром и реактом на новом месте сделали выбор в пользу реакта просто потому что разработчиков искать сильно проще (когда были на ангуляре, 80, а то и 90 процентов людей на собеседования приходили с опытом реакта).
Где искать разработчиков знакомых с $mol - вообще ума не приложу. Продать разработчикам $mol как бенефит тоже видится довольно тяжелой задачей, они резонно заметят что полученный опыт никак в индустрии потом никак монетизировать не смогут.
И нет, мне не надо шашечки, мне надо ехать и чем быстрее тем лучше.
nin-jin
Я бы не рекомендовал нанимать разработчиков одного фреймворка. Ни к чему хорошему это не приведёт. А так, освоить $mol за недельку-другую может любой разработчик, знакомый с TS. А полученный опыт очень даже хорошо монетиризуется, так как начинаешь видеть даже как на React писать код лучше, чем его пишут обычно. То и дело вижу попытки перенести фичи из $mol на React: инверсия контроля через дерево контекстов, модель реактивности с автоматическими отслеживанием зависимостей, оптимизацией потоков данных и освобождением ресурсов, двусторонние биндинги без конфликта источников истины, полноценный саспенс даже в экшенах, автоматизация индикаторов ожидания и показа ошибок, генерация человекопонятных классов и идентификаторов, автоматические точки расширения, отделение инициализации от обновления, избавление от лишних ререндеров и тд. Из послених - remol.