Комментарии 71
Поиск лучшего фронтенд-инструмента 2021 года… и ни слова о технических и потребительских качествах инструмента. В этом весь фронтенд.
В принципе, того же, чего и остальным представленным тут инструментам:
- богатой системы стандартных компонент
- высокой степени настраиваемости компонент
- простоты шаринга компонент между приложениями
- простоты разработки частей приложения разными командами
- толерантности к ошибкам реализации связанных модулей
- низких требований к профессионализму разработчика для обеспечения высокого уровня качества
- поддержки высокой доступности по умолчанию
- централизованной системы сбора аналитики
Ну, $mol подходит по всем пунктам кроме пока что последних двух.
А разве то что присутствует в $mol можно назвать богатой системой стандартных компонент? Я бы сказал что это минимальный набор, который непонятно как расширять…
Каких компонент вам не хватает?
Вся разработка на $mol основана на расширении компонент так-то.
Разработка мол может и основана на расширении, но чтобы ее расширять надо дорабатывать. Тот же vue.js + vuetify дает набор компонентов значительно лучше и удобнее. И все это в два клика расширяется нормальными графиками chartjs и например табличкой от ag-grid. И все работает без танцев с бубном, у них единый подход к взаимодействию, построенный на vuejs. Вот эта парадигма мне больше напоминает расширение. Для $mol это все ручками делать?
Вы не ответили на вопрос.
Нормальные графики и грид это не ответ? :)
Верстка под мобильный по умолчанию хотя бы в Демке тоже была бы полезна :)
Карты от гугла например как добавить?
Чем графики не нормальны?
Датагрида действительно пока нет. Как его нет и почти в любом "наборе".
Интерфейс вполне себе адаптируется под широкий диапазон размеров экранов.
Какая вам разница какой провайдер карт? Яндекс выбран так как не требует api-key для каждого сайта. Планируется и от него отказать в пользу кастомной реализации, использующей osm.
то даже разбираться почему так случается уже не хочется.
Адаптированный интерфейс может и возможен, но в демках этого нет. Быстро пробежавшись по документации тоже не нашел как адаптировать под разные разрешения.
Карты — для разных стран, где используется сайт нужны свои. В России и окрестности лучше работает Яндекс, где то Гугл, а где то действительно OSM. Например если давать в Европе или Азии выбрать свой адрес по картам Яндекса, то точность будет так себе :) Так что нужны все возможные провайдеры в общем случае. а еще есть политические моменты когда Яндекс блокируют и карты не работают :)
И это только начало. Хочется и select со множественным выбором из коробки и нормальный datetime picker…
Это еще и Bar и Bubble всякие Pie и т.д.
bar и bubble(dot) есть. По поводу pie рекомендую почитать это: https://habr.com/ru/company/otus/blog/424647/
вижу там вот такие картинки, куда то съехавшего интерфейса
Спасибо, уже починил. Как видите, багрепорты — это не больно.
Адаптированный интерфейс может и возможен, но в демках этого нет. Быстро пробежавшись по документации тоже не нашел как адаптировать под разные разрешения.
Есть, присмотритесь. Вообще, одна из основных идей $mol как раз в том, что прикладнику не надо "адаптировать интерфейс". Он обычно сам адаптируется.
Карты — для разных стран, где используется сайт нужны свои.
Вы действительно предлагаете для разных пользователей подгружать разные карточные апи? Думаю достаточно будет менять тайловый сервис и сервис геокодирования.
есть политические моменты
Такие моменты надёжно решаются лишь через собственный прокси.
Хочется и select со множественным выбором из коробки
Пожалуйста: https://mol.js.org/app/demo/-/#demo=mol_select_list_demo
и нормальный datetime picker…
Доработал: https://mol.js.org/app/demo/-/#demo=mol_date_demo
И это только начало.
Продолжайте.)
По поводу pie рекомендую почитать это: habr.com/ru/company/otus/blog/424647
Т.е. приходит ко мне бизнес и говорит — я хочу пирог. А я ему такой — вы ничего не понимаете, вот смотрите что на хабре умные люди пишут :-) Идите нафиг учится :)
Есть, присмотритесь. Вообще, одна из основных идей $mol как раз в том, что прикладнику не надо «адаптировать интерфейс». Он обычно сам адаптируется.
Если все само, то почему демо не работает нормально на телефоне?
Вы действительно предлагаете для разных пользователей подгружать разные карточные апи? Думаю достаточно будет менять тайловый сервис и сервис геокодирования.
Мы не предлагаем. Мы так делаем и очень давно. Самый стандартный пример — Россиянам показываем яндекс, Украинцам и американцам гугл и т.д. Как без этого в мультинациональном приложении — не понимаю.
Пожалуйста: mol.js.org/app/demo/-/#demo=mol_select_list_demo
Вы извините, но большего убожества я не видел в своей жизни :)) Вы хотя бы крестики добавьте к выбраним уже элементам, чтобы было понятно как их удалять из списка. И стандартный множественный выбор работает несколько по другому и сильно удобнее вашего прочтения.
Доработал: mol.js.org/app/demo/-/#demo=mol_date_demo
А time так где? а выбор диапазона дат/времени есть? или по старинке все двумя селектами?
Продолжайте.)
Ну и в продолжении, дизайн Vuetify того же можно использовать из коробки и будет красиво и современно. Если все сделать на ваших элементах ничего не трогая, то будет выглядеть это все как лет 10 назад делали.
На самом деле откуда растет ваша идея абсолютно понятно. Просто и быстро создавать приложения. Еще бы к этому делу приделать визуальный конструктор и нормальный дизайн — хороший продукт выйдет. Но для очень простых сайтов. Как только вы сталкиваетесь с большим продуктом и реальными требованиями бизнеса, то такой подход требует очень больших затрат на доработку по каждой небольшой хотелке.
Т.е. приходит ко мне бизнес и говорит — я хочу пирог. А я ему такой — вы ничего не понимаете, вот смотрите что на хабре умные люди пишут :-)
Именно так. Учитесь разговаривать с бизнесом. И решать его проблемы, а не просто делать как попросили.
почему демо не работает нормально на телефоне?
Что именно не нормально?
крестики добавьте к выбраним уже элементам, чтобы было понятно как их удалять из списка
В этом нет нужды, если пользователи не идиоты.
И стандартный множественный выбор работает несколько по другому и сильно удобнее вашего прочтения.
Нет никакого "стандартного" множественного выбора. Если вы говорите о v-select, то это даже не смешно. Чтобы убрать элемент придётся искать его глазами в выпадающем списке, где даже поиска не предусмотрено.
А time так где?
А время проще и быстрее клавиатурой набрать, чем вспоминать в какой части циферблата находится нужное число.
а выбор диапазона дат/времени есть?
Это как-нибудь в другой раз.
Ну и в продолжении, дизайн Vuetify того же можно использовать из коробки и будет красиво и современно.
У material design очень много недостатков. Самый большой — оформление инпутов в виде подчёркивания. Из-за чего даже опытные пользователи порой не замечают куда можно вводить, путая подчёркивание с разделителями. Эта мода вскоре пройдёт.
Как только вы сталкиваетесь с большим продуктом и реальными требованиями бизнеса, то такой подход требует очень больших затрат на доработку по каждой небольшой хотелке.
Как раз таки подход $mol позволяет легко и просто дорабатывать хоть свои, хоть чужие компоненты. Что я вам сегодня и продемонстрировал. Это попросту невозможно в "большой тройке". Именно поэтому на них любой yне совсем тривиальный компонент вырождается в монстра с сотней пропертей как у того же v-select. На них крайне сложно делать ортогональные компоненты, из которых можно было бы собирать интерфейсы как из кирпичиков.
Это похоже на разговор слепого с глухим :)
Если у вас нет пользователей идиотов, и они готовы делать лишний клик для выбора нескольких элементов, то я искренне вам завидую :) удачи :)
И да, ваша демка на айфоне выглядит так. Видимо так задумано и так удобно?
лишний клик для выбора нескольких элементов
Я это уже починил. Вы слишком торопитесь с выводами.
Видимо так задумано и так удобно?
У вас открыто боковое меню, которое сдвинуло страницу вправо. Если так у вас отображается сразу при загрузке, значит баг. Свайпните влево.
Я это уже починил. Вы слишком торопитесь с выводами.
Нет, не починили. Чтобы выбрать 2 элемента надо сделать минимум 4 клика, тогда как в нормальном можно обойтись тремя. И при увеличении количества вариантов разница будет множится, так как после каждого выбора вы закрываете всплывающее окно.
У вас открыто боковое меню, которое сдвинуло страницу вправо. Если так у вас отображается сразу при загрузке, значит баг. Свайпните влево.
Я их тех идиотов, которые не могут догадаться о таком «красивом» и интуитивно непонятном решении :) А если это баг и оно должно быть скрыто, то становится непонятно как его вызвать вообще :)
И странно, что я за полчаса просмотра вашего замечательного фреймворка уже нашел 3 бага :)
Да я тоже поторопился. Запушить забыл. Сейчас уже выкатилось.
Свайпом оно вызывается, как обычно.
Ничего странного и уж тем более смешного на самом деле. Он развивается на голом энтузиазме нескольких человек.
Я не против, но вы утверждали что он лучше других по многим параметром, но даже знакомство «по касательной» показало что использовать это в продуктиве нельзя. А так да, поделие для души прикольное :)
Компоненты есть в сторонних наборах — например vuetify
О том и речь, что это отдельный набор сбоку, а не единая экосистема. У каждого такого набора свой подход ко взаимодействию, в результате чего компоненты из разных наборов плохо совместимы друг с другом да и просто дублируют.
У всех трех компоненты не встроены и это правильно. Берете понравившийся набор и работаете.
из разных наборов плохо совместимы друг с другом
что конкретно имеется ввиду?
Естественно, что они не будет совместимы, ведь это разные наборы.
Затем, что ни в каком наборе нет всех необходимых. Ну, например, реализуйте "не сложно" компоненты для рисования графиков, карт или датагридов. Да так, чтобы они интегрировались в общую цветовую схему. Я понимаю, что вам хочется "защитить" свой любимый фреймворк, но совсем в маразм не надо впадать. От того, что вы заткнёте уши и сделаете вид, что проблемы не существует, проблема никуда не исчезнет.
А проблема в том, что каждый копошится в своём болоте и переизобретает очередную кнопку с оригинальным апи, вместо того, чтобы совместно развивать единую экосистему компонент, взяв на себя свою зону ответственности: один развивает компоненты форм, другой — компоненты для рисованиия, третий — компоненты для карт, используя первые два. При этом получается ортогональный набор компонент, которые минимально раздувают бандл, а не так, что подключение одного компонента из набора удваивает бандл на ровном месте.
Ну, например, реализуйте «не сложно» компоненты для рисования графиков, карт или датагридов. Да так, чтобы они интегрировались в общую цветовую схему.
легко — vuejs + Vuetify + vue-chartjs + vue_yandex_map + aggrid
Перевожу на человеческий:
- Берём фреймворк "для крупномасштабных проектов".
- Добавляем набор компонент на нём.
- Добавляем биндинг к тормозной библиотеке графиков, написанной на своём собственном фреймворке, которая ничего не знает про систему реактивности фреймворка и не подхватывает тему из набора компонент.
- Добавляем биндинг к библиотеке карт, написанной на своём собственном фреймворке со своей библиотекой компонент, которая не подхватывает тему из нашего набора компонент.
- Добавляем биндинг к библиотеке датагридов, написанной на своём собственном фреймворке со своей библиотекой компонент, которая не подхватывает тему из нашего набора компонент и ничего не знает про систему реактивности фреймворка.
- Тратим кучу времени на приведение всего этого лоскутного одеяла к божескому виду.
- Получаем тормозящего монстра, грузящего мегабайты кода на клиент: 4 разных фреймворка; 4 разные реализации тултипа, выполненные в разном дизайне; 3 разные реализации кнопки/поля ввода/чекбокса/и тп, выполненные в разном стиле; и так далее.
И это мы ещё даже не начали писать собственно прикладную логику..
vue create hello-world
vue add vuetify
npm install vue-chartjs chart.js --save
npm install vue-yandex-maps --save
npm install --save ag-grid-community ag-grid-vue vue-property-decorator
Окружение готово, заняло не больше 10 минут. Работает сразу, все в божеском виде и никакого лоскутного одеяла не видно. Chartjs, так же как и aggrid прекрасно работают с реактивностью, никаких биндингов «добавлять» не надо. Тема по умолчанию у них совпадет :) Кнопка есть только одна из vuetify. Тултипы возможно и есть разные в гриде и графиках, но при желании все НЕ СЛОЖНО приводится к единому виду.
Вес указанного набора в сжатом виде около 350Кб (Мы такое запихиваем в контроллеры на ATMega и STM).
Chartjs, так же как и aggrid прекрасно работают с реактивностью,
Речь не о том, что оно не работает, а о том, что работает оно не оптимально. Реактивность Vue умеет оптимизировать потоки данных. На биндингах вся эта оптимизация обламывается.
никаких биндингов «добавлять» не надо.
ag-grid-vue, vue_yandex_map, vue-chartjs — это и есть биндинги к библиотекам.
все в божеском виде и никакого лоскутного одеяла не видно
Это просто не правда.
Вес указанного набора в сжатом виде около 350Кб
Напомню, что это вы ещё не написали ни строчки прикладного кода, а время загрузки уже 5с на 3G.
Это просто не правда.
Почему? Потому что не совсем оптимально написано? Да, возможно. Но позволяет это делать удобно, быстро менять какие то части. Сегодня мы используем такой грид или datetime picker, а завтра вышла новая библиотека и мы перешли на нее. Просто и без танцев с бубнами в виде переделки фреймворка. Или взяли и разработали свой со своим блэкджеком. Не зря ведь в том же VUE логика отделена от графических элементов. Есть свобода для маневра. Хочешь простой интерфейс берешь какой нибудь Buefy, нужен сложный — Vuetify. при этом логика у тебя остается единой. У нас даже есть приложения где используются 2 UI библиотеки одновременно. Одна для рабочих мест на складах, вторая для офисных работников. Нижний слой логики у них один. А возможно появится и 3-й UI на этом проекте для открытого сайта. Там свои требования, в том числе и к скорости загрузки первой страницы.
Вы же предлагаете делать только так как вы решили и только это считаете правильным. При таком подходе вам очень сложно будет продавать слона. Может быть в этом проблема того, что продукт не становится популярным?
Напомню, что это вы ещё не написали ни строчки прикладного кода, а время загрузки уже 5с на 3G.
По сути, когда мы реализуем нормальное бизнес приложение с полнофункциональными гридами, пользовательским интерфейсом и графиками — кардинально меньше у вас не получится. Да и грузится это пользователю только в первый раз. И да, львиную долю (около половины) из этих 350 килобайт занимает шрифт Roboto, который сильно хотят дизайнеры и иконки material icons, хоть и в урезанном нами формате :) Ваш продукт как в этом случае будет себя вести? :)
Почему?
Перечитайте сообщение, которое я цитировал.
При таком подходе вам очень сложно будет продавать слона.
Вы наивно полагаете, будто я вам что-то продаю. Опуститесь на землю, вы не пуп земли, а я не корпорация добра. Я прежде всего делюсь идеями. Экономить вам деньги — не в моих интересах.
бизнес приложение с полнофункциональными гридами, пользовательским интерфейсом и графиками — кардинально меньше у вас не получится
Получится. Вот, например, портал https://mol.hyoo.ru/ весит всего 140кб. А там все моловские компоненты со всеми их демками и ещё несколько приложений.
из этих 350 килобайт занимает шрифт Roboto
Который на Андроиде уже есть, а вы грузите ещё раз.
Вы наивно полагаете, будто я вам что-то продаю. Опуститесь на землю, вы не пуп земли, а я не корпорация добра. Я прежде всего делюсь идеями. Экономить вам деньги — не в моих интересах.
Странно, а зачем тогда Фреймворк, если не денег экономить? просто для души? :-) Ну тогда вопросов нет :)
Который на Андроиде уже есть, а вы грузите ещё раз.
Андроидом мир не ограничивается, Еще есть другие мобильные платформы и десктопы :-) Если вы их не учитывает во фреймворка, то это очень странно.
Получится. Вот, например, портал mol.hyoo.ru весит всего 140кб. А там все моловские компоненты со всеми их демками и ещё несколько приложений.
И что я вижу при первом заходе? Потрясающе:
Если допилят в этом году, то я бы поставил на Rome
Насколько я понимаю, в Angular в основе лежат Observables (лучше всего их постигать на примере RxJS, там хорошая дока), там с ними приходится довольно плотно работать.
Рискну предположить, что это и есть причина того, почему у Angular больше соотношение «работал раньше, больше не хочу». Сложность. Observables, при всей их концептуальной красоте, для обывателя значительно сложнее в постижении, чем… их отсутствие. Вокруг них, как вокруг регулярных выражений (к примеру), у стандартных инженеров витает аура «какая-то непонятная хрень, ну ее, лучше напишу пару ифов и циклов»; очень жаль, конечно, что так (вещь-то хорошая), но что поделать.
Также Observables являются боковой веткой в теме асинхронности, на которую, например, JS решил НЕ делать ставки (ставку сделали на AsyncIterables, которые pull, а не push — резонно заключив, что backpressure проще осознать на стороне читателя, а не писателя). В AsyncIterables тоже полно проблем, конечно, но сложность (и порог вхождения) у них ниже.
Рискну предположить, что при всей своей могучести, создание компонентов в Angular — боль. По сравнению с Реактом (да почти с кем угодно).
Невозможность сделать компонент без обертки в виде хост-элемента (привет от Flexbox), невозможность динамически навешивать директивы (что до безумия усложняет создание своих компонентов и директив на базе стандартных), так себе поддержка typescript (до сих пор нетипизированные let-переменные в ng-template — хотя с каждым релизом все лучше и лучше становится, надо признать).
И к слову об observable — либо 100500 дублирующихся | async в шаблоне, либо ручные подписки, либо создать новый вложенный "синхронный" компонент (а как мы помним, создавать компонты — боль).
<my-component></my-component>Да, об этом. Дело не в селекторе как таковом, а в том, что это именно отдельный DOM-элемент. Это усложняет стилизацию, завязанную на прямое отношение родитель-ребенок. Flexbox — яркий пример, где флекс-элементы должны быть непосредственно вложены во флекс-контейнер. В Реакте у меня такой проблемы не было, потому что компонент реакта существует только в virtual dom, а в реальный ДОМ попадает только контент, который этот компонент рендерит.
<my-component [customDirective]="dynamicValue"></my-component>Не совсем.
Хочу сделать кастомный элемент-ссылку. В зависимости от типа ссылки он будет рендерить или [routerLink]="link", или [href]="link". [routerLink] — директива, ее нельзя динамически включить/выключить.
Или делаю кастомный компонент-кнопку. В зависимости от инпута, она должна быть mat-raised-button или mat-stroke-button. Опять же, mat-raised-button — директива, ее динамически не повесишь. Приходится в темплейте дублировать разметку для каждого случая. В реакте это бы выглядело как-то так
const ButtonComp = props.raised ? RaisedButton : StrokeButton;
return <ButtonComp {...buttonProps}>;А теперь усложняем — хочу композит, который будет или ссылкой, или кнопкой (и покажет промежуточный диалог). Получили комбинаторный взрыв в темплейте.
Можно долго холиварить по поводу что лучше, что хуже. Тут надо исходить из требований и объема. Лично для меня уже сложилось мнение, что для чего-то простого, небольшого сайта — лучше svelte. Для чего-то посложнее, но не более — react. Если требуется сделать сложную, большую систему — лучше angular. Одним из простых причин выбора для последнего DI, без него сложно строить сложную систему максимально просто.
Насчет vue ничего не могу сказать толкового, не изучал особо, честно и желания нет.
В angular есть шаблоны(ng-template)
Они (1) многословные (это вкусовщина, конечно, можно игнорировать), (2) только для контента внутри элемента. Все атрибуты (в моем примере с mat-raised-button / mat-stroke-button) на каждую кнопку все равно придется дублировать.
Можно возразить, конечно, что проблема не в Ангуляре, а в Material (ну в самом деле — что мешало сделать одну параметризированную директиву mat-button="raised", как сделали в имплементации под реакт). Но пока что имеем то, что имеем.
Да, я понимаю, что мои претензии исходят из привычки любую проблему решать композицией компонентов (в реакте). Но более элегатного способа решения моих проблем я не нашел. Может, вы подскажете, как сделать динамическую кнопку из моей (не-)гипотетической задачи выше? Так, чтоб без дублирования кода.
Так к слову mat-raised-button — это не директива, а компонент. Просто она хостится не на новый тип тэга, а на существующую
Угу, так и сделали в итоге. Шаблон для содержимого кнопки, и продублировали объявление самой кнопки с ее атрибутами/обработчиками для каждого варианта.
Могу еще пару примеров накидать из реального проекта. Типовые, казалось бы, задачи по расширению существующих компонентов приходится решать обходным путем.
директиву [routerLink]="link" в HTML-код преобразованный с Markdown-кода.
Ха! Мы в итоге написали свой мини-парсер для двух-трех тэгов маркдауна (ссылки, базовое форматирование). И ангуляр-компонент, который умеет рендерить структуру данных с выхода этого парсера.
Но это довольно специфическая задача. Не уверен, что я знаю, как ее можно было проще решить любым другим инструментом.
Эм, я думал, задача — навесить директив внутрь полученного html.
Отрендерить html как есть — тривиально (что отлично продемонстрировано вашим примером)
А, сорри :). Я имел в виду, что поскольку этот наш компонент принимает на вход не html, а распарсенную структуру, он знает, как рендерить каждый тип блока (ссылка, выделение, простой текст). И при рендеринге блока типа "ссылка" использует routerLink. Примерно так
<a *ngIf="block.type === 'link' [routerLink]="block.path">...</a>
<ng-container *ngIf="block.type === 'text'>{{block.text}}</a>Кстати, сразу вспомнил про еще одну насущную проблему с TS в шаблонах — ngIf/ngSwitch не поддерживают type narrowing. Привет type assertions.
И из за этого пришлось вешать обработчик клика через renderer2.listen, что в общем то тоже не красиво, но зато дешево написать обработчик :)
<section class="d-flex flex-wrap justify-content-center">
<jobs-contract-card
*ngFor="let job of jobsMatches"
class="col-12 col-md-6 col-xl-4 mb-3 mb-xl-0"
[job]="job"
[navigateTo]="'/jobs/view/' + job.id"
></jobs-contract-card>
</section>
Как вы можете видеть, я поместил компонент в флекс-контейнер. Компонент работает как и ожидалось, тоесть как дочерний элемент.
Сложности начинаются, когда надо внутренности jobs-contract-card завернуть, например, в ссылку. Но так как между ссылкой и section будет ещё один промежуточный элемент jobs-contract-card, то привет костыли в css.
Только вот никакой компонент не может добавлять дополнительные директивы хостовому элементу, из-за чего их все приходится перечислять в каждом месте использования без какой-либо надежды на инкапсуляцию. Вообще, по сути, все компоненты в ангуляре — не более чем директивы, так как компонент слабо контролирует хостовой элемент.
Да, именно так.
Директивы не могут навешивать другие директивы, из-за чего невозможно сделать новую директиву как композицию из двух имеющихся.
Например, кастомная директива ссылки на сущность, которая принимает сущность как инпут и навешивает routerLink и matTooltip (или даже просто routerLink плюс класс для стандартной стилизации)
Приходится делать компонент-обертку над <a>.
Уж не хотите ли вы сказать, что ангуляр дураки проектировали? Вы не должны этого хотеть!
Нет, конечно же, это не то, что я хочу сказать. В ангуляре хватает хороших и интересных решений. Но несколько моментов мне видятся прямо вот очень неудачными. И статичность директив — один из них. И это не только моя хотелка. Ишью на гитхабе открыто с 2016.
В моем идеальном мире ангуляр скрещивается с реактом (компоненты пишем на jsx; инфраструктура и DI из ангуляра) :)
Хм. У меня был в голове конкретный пример. Стал его разбирать — проблема не во флексе, оказывается. Коротко передать проблему не выходит, но это не столь важно. Вероятно, то, что я пытался сделать, в некотором смысле нарушало логическую инкапсуляцию компонента. Вариант от atomic1989 с селектором по атрибуту мог бы помочь в этом конкретном случае.
Либо реализовать suspense-api на базе mobx и форкнуторго mobx-angular. Тогда про асинки со стримами можно забыть как про страшный сон.
Blazor. Net круче всех
Vue — это проект, который появился сравнительно недавно. >
Разница в релизах с реактом меньше года.
Хочется больше конкретики. Что, почему, какие выводы и т.д.
Поиск лучшего фронтенд-инструмента 2021 года