Comments 19
Удваиваю, отличная штука, простая, удобная и при желании расширяемая (скажем, можно добавить свою версию .prop(), сохраняющую значение в localStorage или вызывающую колбек). Да и Flarum написан на Mithril, о чём-то это да говорит.
Заинтересовало, спасибо.
И да, переведённая документация — было бы очень даже неплохо.
Судя по документации Mithril, его autoredraw равнозначен вызову this.forceUpdate() в корневом компоненте React. И перегенерации всего vdom tree. А происходит это на каждый чих.
Если беспокоит именно размер загружаемых скриптов – можно использовать preact. Он вообще 3 кБ весит.
С той же страницы:
«Mithril также может избежать автоматической перерисовки, если частота запрашиваемого рендеринга превышает один кадр анимации (обычно около 16 мс). Это означает, например, что при использовании быстрых событий, таких как onresize или onscroll, Mithril автоматически регулирует количество перерисовок, чтобы избежать лагов».
То есть, пусть считает когда надо, на скорость UI не повлият.
При желании вы можете отключить autoredraw c помощью
function clickHandler(e) {
// теперь redraw не запустится при вызове обработчика
e.redraw = false
}
Также он не пересчитывает VDOM для компонентов, которые в данный момент не отображаются на уровне роутера. В итоге, не так уж и много считать выходит.
Опять же, бенчмарки подтверждают скорострельность инструмента, а в Chrome Development Tools видно, что страницы не грузят процессор.
По сравнению с React, думаю, тут вопрос в том числе и в том, на что уходят циклы процессора при использовании различных дополнительных библиотек для управления состоянием.
Согласен про preact, но Mithril умеет все, что нужно «у целом», в отличие от того же preact, который копирует зону ответственности React, и будет требовать дополнительной обвязки.
Такой расклад.
То есть, пусть считает когда надо, на скорость UI не повлият.
Почему не повлияет? Да, множество запросов стекаются в один и рендерятся только во время рендеринга кадра, но из-за большого дерева вполне может тормозить. То есть, скажем, у нас дерево рендерится 500 мс. Да, если вызвать
forceUpdate трижды, то рендер будет длиться 500 мс, а не 1500. Но это не значит, что ЮИ не тормознет.В идеале — если поменялись пропсы/стейт компонента — этот компонент нужно перерендерить, при этом у его дочерних компонентов перерендеривать только те, у которых поменялись пропсы/стейт. Тогда будет минимум пересчетов.
Также он не пересчитывает VDOM для компонентов, которые в данный момент не отображаются на уровне роутера
Ну это само собою разумеется.
Опять же, бенчмарки подтверждают скорострельность инструмента, а в Chrome Development Tools видно, что страницы не грузят процессор
Бенчмарк странный — он в цикле кликает на 50 элементов, соответственно нету смысла перерисовывать по одному элементу и перерисовка всей страницы выгоднее.
В реальной жизни будет происходить клик по одному элементу 50 раз и в реальной жизни в Мифриле будет в 50 раз больше перерисовок, чем в Реакте
Я всё также за Riot.js в большинстве случаев. Очень простой, очень маленький, всё что надо делает. У нас довольно большой проект на нём написан, уже пару лет как всё работает, обновились уже с первой версии на третью — по мелочам поправили кое-какие места, но по большей части ничего даже править не нужно было.
Как подключить? Просто 6кБ gzip:
<script src="https://unpkg.com/mithril"></script>
Лучше все-таки указывать версию, чтобы ненароком ничего не сломалось: https://unpkg.com/mithril@1.1.5
Если искать маленькие SPA-фреймворки, то стоит посмотреть еще и на choo.
В нем все так же есть компоненты, встроенные роутер и store. Тоже интересная альтернатива
Мне вот всегда было интересно, чем люди объясняют использование микро-фреймворков именно при разработке SPA? Я понимаю, если на нем реализована только небольшая часть страницы.
Помню, тут была статья от DevExpress, как они используют Preact в своих виджетах.
Ну или мобильный сайт 2gis. Но прелесть Preact именно в совместимости с "большим братом" вплоть до библиотек.
Такие либы, как choo и mithril выглядят круто! Их разработчики заслуживают уважения.
Но если писать целый сайт, то размер собственного кода достаточно скоро превысит размер фреймворка. И будет уже без разницы, 40 кб кода + 20 кб Vue или 40 кб кода + 5 кб микро-фреймворка. А заплатим мы за это странными багами в незрелой либе и повышенным порогом вхождения в проект.
Все верно вы рассказываете. Если веб-приложение большое, пишется целой командой разработчика, то ±40 Кб кода фреймворка погоды не сделают.
А если приложение маленькое, и код пишется одним человеком, возможно будет оптимальнее взять фреймворк поменьше.
Еще mithril и choo и компания очень хорошо смотрятся для встраиваемых виджетов. Тащить большой фреймворк туда не с руки, а что-то маленькое заходит идеально.
При этом я не призываю пересаживаться умеющих готовить React, это не за чем.
Но, к примеру, если у вас есть другие интересы кроме фронтенда и вы хотите делать современное приложение, потратив минимум времени на изучение и внедрение, да еще и с хорошим темпом разработки, то Mithril — это реально хороший инструмент.
При этом у вас получится расширяемое и поддерживаемое приложение при наличии минимальной способности декомпозировать код.
Конечно, есть риск, что при смене парадигмы придется переписывать. Но ведь переписывали с ванили на JQuery, с JQuery на Backbone, потом на Angular 1, потом, скорее всего, на React. Но на самом Реакте сколько раз вы переписывали c Реакта на Реакт? Можете не отвечать: несколько раз. Потому что FB делал рендерер ленты. И сделал его. А все остальное по ходу пьесы. Сначала Flux, потом Redux, потом новое решение — MobX. Не используйте ref. Используйте функциональные компоненты. И так далее.
Знаете, сколько раз в день я открываю документацию Mithril во время разработки? Ни разу. Столько же и StackOverflow. Потому что не за чем. Если вы понимаете JS, вы знаете Mithril. Потому что он построен на простых концепциях. У Angular 2/3/4/5 постоянно что-то не так с документацией, недавно тоже была статья о том, что люди лезут в исходники чтобы понять, что происходит и как надо делать. А это потеря времени и денег.
Кстати, Mithril тоже работает с Redux, но он работает и без него, при этом вы можете использовать те же подходы.
Я написал про Mithril, потому что верю, что такая вещь, как обработка пользовательского ввода, не должна занимать «бОльшую половину» мозга. Пусть останется место и время для чего-то большего. Peace, folks.
У вас кривые бенчмарки. Первый вообще для mithril ничего не оказывает, а второй работает, но замеряет лишь синхронные операции. Всё, что исполняется отложенно он не учитывает.
Вот правильный бенчмарк, замеряющий полное время рендеринга: http://mol.js.org/app/bench/#bench=https%3A%2F%2Feigenmethod.github.io%2Ftodomvc%2Fbenchmark%2F/sample=angular2_es2015~mithril~mol~typescript-react/sort=fill
Я обновил (локально) TodoMVC для Mithril (ведь он на 0.2 для существующих бенчмарков) до 1.1.5 с применением описанного в статье подхода. Будет время, дооформлю и сделаю пулл реквест в основной репозиторий. Прогнал ваш тест у себя на ноуте. Вот цифры, получившиеся при создании и завершении 200 задач. Упорядочено по возрастанию (меньше — лучше):
Вариант Создание + Заврешение, мс
$mol 1151
Angular2+ 4451
TypeScript & React15 5257
Riot.js 6112
Mithril (1.1.5) 6847
Elm 7118
Vue.js 8833
AngularJS 9394
jQuery 23809Пару нижних вариантов для сравнения оставил. Время холодного старта здесь не учитывается.
Просто огромное спасибо за статью.
За что я люблю именно Mithril (он же MithrilJS)