Comments 49
Ну и дежурный вопрос: почему $mol, который в то время пиарили по всему Хабру, не попал даже в список кандидатов? Вот, я прошёлся по вашему чек-листу, что дало средний балл 5.2:
✅ Кросплатформенность. Работа в приложениях на десктопах, смартфонах, планшетах, на платформах Android, iOS, Windows Phone. Работа с touch-устройствами
✅ Производительность фреймворка при большом количестве данных
✅ Легкая реализация кастомных элементов слоя представления
❌ Полноценная документация
✅ Базовое быстродействие (без нагрузки в виде большого количества данных)
✅ Большая компонентная база
✅ Доступность специалистов на рынке
✅ Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален
✅ Наличие инструментов отладка исходного кода, лёгкость локализации ошибок
❌ Возможность реализации слоя представления в виде HTML-верстки
✅ Низкий порог вхождения для новых сотрудников
✅ Наличие механизмов для реализации unit- и авто-тестирования
❌ Развитое сообщество
✅ Развитая высокоуровневая базовая модель данных инструмента, наличие высокоуровневых шаблонов
✅ Отсутствие необходимости программисту работы с DOM-моделью
✅ Поддержка стандарта JavaScript ES6+ и TypeScript
✅ Низкие трудозатраты при необходимости реализации нестандартных компонентов
✅ Локализация приложения в различные иностранные языки
✅ Отсутствие ограничивающих лицензий
Вероятно потому что:
❌ Полноценная документация
❌ Возможность реализации слоя представления в виде HTML-верстки
❌ Развитое сообщество
✅ Токсичность пишущих на $mol
Первый коммит в репозиторий $mol быль сделан в мае 2016, к этому моменту оригинальное исследование уже было завершено, поэтому фреймворк физически не мог оказаться в списке рассматриваемых.
Вообще, ваш выбор в пользу разработки собственного решения довольно смелый. Для компаний это не всегда применимо.
Середина десятых годов была удивительным временем для фронтенд фреймворков. Многие "старички", проверенные временем уходили на пенсию, а "новичков", подающих надежду, было множество. Какой из них выдержит конкуренцию - вопрос. В этом и состояла сложность и интересность выбора.
✅ Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален
Ну да, ну да:
Поставить будущее своей компании в зависимость от одного единственного стороннего разработчика, отличный план, надежный как...
Кто не знает историю, обречён на её повторение.
Видим, что AngularJS развивался с 2010 по 2017 и поддерживался по-крайней мере до 2021. Так уже для тех, кто сделал на него ставку в 2010-2011, критерий выполняется.
AngularJS просуществовал меньше, чем уже существует $mol. При этом те, кто поставил на него будущее своей компании в 2015 году был вынужден уже через 2 года переписать проект полностью на чём-то другом. Те, кто по умнее, соскочили с него на Вью. Кто по глупее - на Реакт. Остальные же решили повторить с сырым до 10 версии Ангуляром с прекрасной поддержкой, чинящей баги в базовой функциональности годами.
А те кто поставил но $mol (кстати, есть такие?), постоянно получает от автора советы вида "код $mol открыт, если что то не работает, работает неправильно или не реализовано - вы можете сделать это сами"?
Тут есть доля передергивания, но это прям как в примере про ангуляр выше
Ага, а если что то не работает в Ангуляре, работает неправильно или не реализовано - вы **не сможете** сделать это сами и будете лепить костыли, надеясь, что через 5 лет это поправят.
Может мне повезло, но за ~10 лет ангуляра не помню ни одного случая, когда я б напарывался на баги ангуляра.
А вот почти в каждой статье про mol$ находится баг (или недоработка), на который поступает предложение поконтрибьютить и сделать самому, либо поступает ответ "вам это не нужно"
Но иногда, справедливости ради, бывает что выкатывается новая версия с правкой
Берём первый попавшийся компонент Select и выведем в него список городов. Найти в нём, например, Дакоту - задача не из простых. Как быстро вы прикрутите туда поиск? Как скоро вы дождётесь прикручивания туда поиска от вендора? Ещё через 10 лет? Для сравнения $mol_select.
https://material.angular.io/components/autocomplete/overview
Вроде есть что то готовое.
К тому же, можно взять другой набор компонентов, не материалом единым. Не понимаю как это связано с проблемами ангуляра
Автокомплит совсем о другом.
Ну да, найти другой набор, потом мучиться с приведением к единому стилю, потом бояться обновлять мажорную версию фреймворка. Никаких проблем.
О чем автокомплит? Чем он не устраивает?
Все в едином стиле, не знаю, что не так там. Бояться не нужно, что то не встречал проблем. И повторю, ангуляр не ограничен материалом.
Не знаю, чем вы занимались 10 лет на Ангуляре, но я бы рекомендовал вам записаться на курсы UX, чтобы понимать основы разработки интерфейсов и разницу между разными контролами в частности. Конкретно по этим, ключевая разница в следующем:
Выходное значение селекта - не то, что видит пользователь, это даже не обязательно строка.
Пользователь не может ввести невалидное значение, что избавляет от необходимости его нормализации и валидации.
При открытии селекта экранная клавиатура его не перекрывает, так как поиск не является основным сценарием.
В принципе, без разницы будете ли вы пытаться к селекту прикручивать поиск, или из автокомплита делать селект. На Ангуляре это одинаково больно. На любом UI Kit.
Все это звучит странно как то.
Выходное значение селекта - не то, что видит пользователь, это даже не обязательно строка.
Так же как и автокомплит.
Пользователь не может ввести невалидное значение, что избавляет от необходимости его нормализации и валидации.
Чего? Автокомплит тоже не позволяет ввести что то свое
При открытии селекта экранная клавиатура его не перекрывает, так как поиск не является основным сценарием.
Это где такое определение есть? Или это какое то сакрально знание, которое "и так понятно"?
Забавно, вы тут ниже предлагали пользоваться своей головой. Давайте последуем совету, поищем 1 минуту, и возьмём для больших селектов более подходящий компонент. Дакоту там искать просто, сами попробуйте.
Вы не заметили его? Или осознанно высосали проблему из пальца? Ну и конечно, отличный манёвр, ушли от ангуляра к сторонней UI библиотеке. Хоть и от тех же авторов, но таки сторонней, ведь ангуляр не тянет с собой её, и у ангулярщиков есть выбор UI-китов, в отличие от.
Продолжайте думать, и обязательно додумаетесь, почему эти два разных компонента с совершенно различной функциональностью до сих пор не объединили в один.
$mol вообще ничего не тянет с собой, в отличие от.
autocomlete без возможности выбрать/ввести что-то не из списка == dropdown/select с фильтрацией. Prove me wrong.
Но если уж убеждения не позволяют взять autocomplete вместо select, то можно заблаговременно взять ui-kit побольше, чем ущербный material, благо их много. Вообще, докапываться до недостатков material, это как обижать ребёнка - показать над ним превосходство просто, но со стороны выглядит не очень.
Ваще мимо, вы можете лучше.
Angular 2 вышел в 2016, а поддержка первого закончилась в 2022. 8 лет поддержки старья - хороший срок. Да и умер первый не молча, команда ангуляра выпустила инструменты и подробдые гайды как мигрировать с одного на другое. Ну и самое главное отличие - у ангуляра bus-factor большой, там много разработчиков, у моля же он равен одному.
Поддержка - громко сказано. Особенно показателен случай, когда эта чудесная поддержка безрассудно сломала обратную совместимость в минорной версии, на что поднялся вой и они откатили. Гайды по миграции - тоже громко сказано. Архитектуры совсем разные - вся миграция заключалась в полном переписывании.
Я, кстати, знаю, почему никто не берёт mol. В то время, как во всех популярных библиотеках и в самом языке везде camelCase, в mol пошли своим путём, и используют snake_case. Итоговый код будет выглядеть кашей из разных стилей (вон и в исходниках так: 1, 2, и т.д.), что будет задевать чувство прекрасного у использующих его людей. Ну и линтер/форматтер надо дольше настраивать.
В $mol технические решения имеют обоснование, в то время как остальные придерживаются карго-культа. А линтер/форматтер не надо настраивать для имён, не выдумывайте.
Увидел там только вкусовщину (мне snake_case читать труднее) и попытку оправдаться
В JS формат кастомных имён отличается от формата имён нативных API, что с одной стороны неконсистентно в целом, но с другой позволяет легко отличать нативное от кастомного.
Ну то есть не баг, а фича, ага. Зачем отличать одно от другого, чтобы что?
А линтер/форматтер не надо настраивать для имён, не выдумывайте.
Хз как у вас (в проекте не увидел линтера вообще, найс), но у меня на каждом проекте есть naming convention, который чекается линтером, чтобы не получалось плохочитаемая мешанина, когда работают много людей вместе. И в конфиге линтера стоит ошибка для snake_case. И если я вдруг захочу отнаследоваться от класса, в имени которого (или в его полях и методах) есть snake_case, то линтер будет ругаться. В таких случаях надо отключать линтер на эти строки, что на самом деле тупо. Так что настраивать таки надо, не выдумывайте, что я выдумываю.
Мы тут между ангуляром и реактом на новом месте сделали выбор в пользу реакта просто потому что разработчиков искать сильно проще (когда были на ангуляре, 80, а то и 90 процентов людей на собеседования приходили с опытом реакта).
Где искать разработчиков знакомых с $mol - вообще ума не приложу. Продать разработчикам $mol как бенефит тоже видится довольно тяжелой задачей, они резонно заметят что полученный опыт никак в индустрии потом никак монетизировать не смогут.
И нет, мне не надо шашечки, мне надо ехать и чем быстрее тем лучше.
Я бы не рекомендовал нанимать разработчиков одного фреймворка. Ни к чему хорошему это не приведёт. А так, освоить $mol за недельку-другую может любой разработчик, знакомый с TS. А полученный опыт очень даже хорошо монетиризуется, так как начинаешь видеть даже как на React писать код лучше, чем его пишут обычно. То и дело вижу попытки перенести фичи из $mol на React: инверсия контроля через дерево контекстов, модель реактивности с автоматическими отслеживанием зависимостей, оптимизацией потоков данных и освобождением ресурсов, двусторонние биндинги без конфликта источников истины, полноценный саспенс даже в экшенах, автоматизация индикаторов ожидания и показа ошибок, генерация человекопонятных классов и идентификаторов, автоматические точки расширения, отделение инициализации от обновления, избавление от лишних ререндеров и тд. Из послених - remol.
Кажется, эта статья на момент выхода уже является устаревшей. Критерии, по которым вы выбирали тогда, к 2023 поменялись несколько раз. Более того, после выбора Angular вы всё равно где-то используете тот же React.
В подобных статьях наибольшую полезность имеют конкретные технические сложности с которыми столкнулись и решения, которые использовали.
Если статью воспринимать только как сравнение технологий 2016 года, то соглашусь, конечно, устарела :) Но я старался больше сделать акцент на методологии, на подходах и посмотреть как спустя годы это себя показывает. Например, в большинстве статей о сравнении технологий я не встречал описания, как собираются критерии. Зачастую они даже не взвешиваются. Учитываются ли при этом интересы бизнеса? Не понятно.
Кроме того, редко увидишь и хороший анализ рисков, просто потому, что в них опускаются риски не технологического характера.
Если говорить про одновременное использование Angular и React, то для более-менее крупной компании использование только одной технологии - большой риск. Все яйца в одну корзину не складывают. К тому же, React хорошо подходит в определённых ситуациях (например, для точечного улучшения крупного fullstack приложения). И почему бы им не воспользоваться?
Из сложностей можно дополнить следующее:
- Отсутствие опыта Angular у сотрудников этапе. Из-за этого местами некачественный код и решения, которые затем переписывались.
- Мало готовых компонентов в 2016-2017. Приходилось брать из разных библиотек из-за чего UX от одного контрола к другому мог сильно отличаться.
- Где-то года через 2-3 на передний план вышла проблема, что сторонние компоненты не поддерживают новых версию Angular, т.к. перестали развиваться (за частую их просто бросили). В итоге мы намучились и решили делать свой UI kit.
Тем временем в параллельной вселенной:
$mol не даёт неопытным сотрудникам говнокодить, приучая к хорошим практикам.
Уже в 2016 году в $mol было больше стандартных компонент с единым UX, чем в любом другом UI-Kit написанными сторонними людьми для Ангуляра.
И с тех пор они никуда не делись, не перестали поддерживаться, не сломали обратную совместимость.
И сделать на их основе свой UI Kit в своём дизайне можно было без каких-либо мучений.
Но кому какое до этого дело? Давайте минусовать комментарии, игнорировать вопросы и клеветать про токсичность - так победим.
Я думаю все ждут примеры сайтов на $mol, написанные не автором
Ну и мб отзывов о $mol не от автора :)
и клеветать про токсичность
Я вот ваши комментарии почитал тут и могу сказать, что они очень токсичные. А ещё могу сказать, что, посмотрев на главного разработчика и его манеру общения, $mol теперь даже смотреть не пойду и точно буду против, если кто-то другой предложит его использовать.
Жили-были два соседа. Один жил хорошо. Другой - чуть похуже. Второй завидовал первому. Пришел он к Богу с просьбой, мол дай мне столько же, сколько есть всего у моего соседа. И ответил Бог, что выполнит эту просьбу. Но при одном условии - соседу просителя он даст в два раза больше. И тогда просящий сказал - выколи мне глаз.
Клевета не в мой адрес, а в адрес людей пишущих на $mol. А вообще, всегда забавно слышать от практикантов культуры отмены претензии в токсичности. Тут или крестик снимите, или штаны наденьте.
А что не так с Wordpress (темы/компоненты + плагины) - бэкенд (Wordpress API, mySql, php) - громадное сообщество, открытый код, платных плагинов любой степени сложности навалом. Если проекты не супер highload - собирается все что угодно (простой и удобный конструктор).
CMS-ки отлично подходят там, где нужно создавать много шаблонного контента. Например для сайта mango-office.ru используется 1C Bitrix, и это оправдано. В остальных продуктах такого нет, в них разработка любого раздела превращается полностью в самописный код. т.е. Wordpress начинает использоваться как фреймворк по аналогии с Laravel или Symfony. Но в этом качестве он явно не лучше последних.
Внедрять ангуляр в компании где у большинства нет опыта разработки на нём - боль и мина в плане расходов в будущем на выпиливание огромного кол-ва говнокода. Хотя бы лиды или сеньоры должны обладать хорошим опытом на фреймворке, чтобы держать в узде остальных. Хотя если темп разработки низкий, как это часто бывает, то наверное это не будет большой проблемой. И да, в тот момент выбора было не очень много по всей видимости ;)
Внедрять ангуляр в компании где у большинства нет опыта разработки на нём
Не совсем так. Опыт AngularJS в некоторых командах был. Это конечно не Angular, но всё равно не с нуля. Внедрение шло постепенно, начиная с новых проектов. Так уж боли не было. Кроме того раз в несколько лет приходится и существующие интерфейсы переписывать, например при масштабном редизайне, и что в это случае будет быстрее, ещё вопрос.
Мы когда-то очень плотно работали с ангуляром, а сейчас, на новом месте с новым проектом решили все-таки взять реакт просто потому что сильно меньше проблем с поиском новых разработчиков с готовым опытом.
Но по личному опыту видится что ангуляр сильно более, как в русских деревнях говорят, opinionated и это помогает что в равитии что в поддержке проекта.
Еще он очень помогает энтерпрайзным бекендщикам (коим я также был) чувствовать себя как дома.
Как мы выбирали технологию для фронтенда и что из этого вышло