Нужно фоном какую-нибудь музычку запускать. Будет веселее.

Ура, наконец-то новый выпуск!

Давно не писал комментарии, но я не смог сдержаться )

Не запоминать конкретную “карточку” или что-то еще – это не бред. В этом случае не нужно хранить оригинальные данные. Достаточно сделать хеш (засолить/пересолить) и хранить его, и сравнивать хеш от новых данных с известными. Вот и вся “магия”.

По поводу доклада Антона Виноградова. Они опираются на БЭ, и было утверждение, что это лучший вариант для идеи. Хотя утверждение спорное. А насчет React было обратное, что вероятно можно, но сложно. Основной поинт, почему БЭМ – потому что там все описывается не деклативно, и можно получить на выход и html, и svg, и все что угодно. В случае с React мы как бы описываем конечный html и не можем получить что-то другое. Хотя по факту это не совсем так. Да, описывается html, но он превращается в абстрактную структуру известную как Virtual DOM. По факту из нее можно получить не только DOM, но и все что угодно. По сути так обеспечивается изоморфность в React, в одном случае на выходе генерируются DOM ноды, в другом – строки. Но проблема не только в получении svg из html, но и переборе состояний. В случае с БЭМ вроде как есть известные модификаторы и можно перебрать (сгенерировать) состояния, да и сам деклативный подход к этому располагает. В случае с React разметка генерируется javascript’ом и предсказать возможные состояния без его исполнения невозможно, что крайне затрудняет перебор состояний, если не делает его невозможным. Но это проблема не только React, а любой шаблонизации, которая связана с использованием javascript или любого императивного языка для получения конечной разметки.

Еще меня удивила реакция на доклад Бориса Каплуновского про их DOM шаблонизатор. Когда я рассказывал про эти подходы года два назад, реакция была спокойной. Сейчас же вызывает восторг. Видимо популяризация DOM шаблонизации тем же самым React’ом и остальными сделало свое дело и люди стали проявлять к ней больше интереса 🙂

Тем не менее, после вашей дискуссии появилось сильное желание сделать доклад – “Никто не знает про DOM-шаблонизацию”. Потому что многие тезисы являются заблуждением. Давайте по порядку.

Производительность: быстрее React в 3 раза. Тут конечно, за что купили – за то продали. Но тем не менее. Начнем с того, что большинству опытных разработчиков очевидно, что micro benchmark’и – это конь в вакууме. И когда сравнивается одно с другим нужно учесть, что код выполняется в неестественной среде, и в боевом окружении будет немного иная картина. И так же все зависит от браузера. Но в любом случае, сравнивая важно сравнивать одинаковую функциональность, что в тестах Бориса не совсем так. В его докладе три теста сравнения: создание DOM фрагмента, обновление с полным изменением всего и обновление без изменений.

Создание. Если говорить про Temple, то он лишь создает DOM фрагмент и возвращает интерфейс к нему. Это все, что он делает. Например с событиями он не работает, это уже делается вне шаблонизатора и затраты на эту работу не попадают в тест. Наверняка делается еще что-то, что так же в тест не попадает. Так же в нем нет поддержки старых браузеров, и разруливания работы с ними. Но в React, например, делается все необходимое, в том числе для работы с событиями, и после этого никаких манипуляций больше не требуется. Тем не менее, в Chrome и Firefox разница между Temple и React не такая радикальная, меньше 1.5 раза. А вот в Safari – да, те самые 3 раза. Я еще добавил в тест basis.js. Он работает схожим образом с Temple, но делает все необходимое. В Chrome они на равне, в Firefox basis.js немного быстрее, в Safari basis.js проигрывает Temple в 2 раза. В целом можно заключить, что в Safari cloneNode медленнее чем createElement/createTextNode (что странно), в остальных браузерах наоборот (как и должно быть). Тест: http://jsperf.com/init-temple-vs-react/3

Обновление с полным обновлением значений. На этой задаче React явный аутсайдер, это его ахилесова пята. Превзойти его не сложно. Так как, на каждую смену состояния вызывается метод render, который сначала генерирует новый фрагмент Virtual DOM, затем этот фрагмент сравнивается с уже известным и только после этого вносятся изменения в DOM (если нужно). Да можно использовать хаки и оптимизировать сравнением, но это не сильно поможет и явно “не спортивно”. В Temple изменения сразу прокидываются в DOM, так как для каждого значения уже сгенерирован код, который описывает что должно быть изменено в DOM фрагменте. Как результат – Temple выигрывает значительно (от 10 до 100 раз в зависимости от браузера). basis.js делает практически тоже самое, только в нем есть дополнительная логика, например обработка значений (если значение особо типа, “шаблон” может сам подписаться на его изменение), что дает оверхед и в результате проигрывает Temple в Chrome и Safari (в 2-3 раза). Но, как ни странно, немного выигрывает в Firefox. Тест: http://jsperf.com/hard-update-temple-vs-react/2

Обновление без изменения значений. У React те же проблемы, поэтому его результаты предсказуемы. В Temple не хнанится информация об уже записанных значениях в DOM. Поэтому когда приходит значение, даже которое уже есть в DOM, то это приводит к тем же действиям что и при установке нового значения. Браузеры по большей части не делают оптимизаций, когда в DOM вносится значение, которое в нем уже есть (например, если в атрибуте указано значение “foo” и мы пишем в атрибут это же значение, это равносильно присвоению нового значения со всеми вытекающими). Поэтому затраты те же, что и при полном изменении данных. basis.js хранит значения, которые записывает в DOM, а когда приходит новое значение делается сравнение с тем, что было записано ранее. Если значения совпадают, то действий над DOM не происходит (вообще не трогается DOM). Как результат в этом тесте basis.js абсолютный лидер во всех браузерах (обгоняет Temple в 2-20 раз). Тест: http://jsperf.com/soft-update-temple-vs-react/2

В реальных приложениях данные постоянно обновляются с сервера. На чаще всего они меняются неначительно, либо не меняются вовсе. Тут стоит заметить, что, например, в basis.js в случае если данные не изменились, то до шаблона дело даже не дойдет – понимание что не нужно ничего менять появится намного раньше, еще на уровне данных.

“Temple быстрее React из-за малой глубины вызовов”. Очевидно, что дело не в глубине вызовов (размере стека), а просто React делает гораздо больше работы. В частности необходимо создать Virtual DOM (больше действий, дополнительная память etc) и делать сравнение (обход, сравнение, замена etc). И только после этого делать или не делать операции над DOM. В Temple нет Virtual DOM, в нем поэлементно создается фрагмент (для каждого экземпляра шаблона, это важный нюанс), и возвращается карта методов, которые точечно меняют необходимые узлы. Никакого Virtual DOM, сравнения, поиска, определения дельты – это делает его быстрее. Шаблонизатор basis.js делает все тоже самое, только в нем еще есть дополнительная логика и информация. И проигрывает он Temple скорей из-за этого, чем из-за большей вложенности. И еще один важный нюанс, basis.js создает поэлементно только эталонный DOM фрагмент, а дальше он клонируется (cloneNode(true)) при создании экземпляра шаблона – это позволяет нивелировать оверхед дополнительной логики и не сильно отставать на создании от Temple (а в некоторых браузерах даже выигрывать).

“Temple генерирует Virtual DOM…”. Как я писал выше, Temple не имеет Virtual DOM и в нем нет такого понятия как render (как и в basis.js). Соответственно нет необходимости в сравнениях и какого либо сложного рантайма (он вообще не нужен). Если говорить про Glimmer (Ember.js), то там ситуация немного сложнее. Да, они ввели понятие Virtual DOM, как некоторый stage, из которого потом можно получать и DOM, и html (в виде строки). Но механизм его несколько иной, там нет сравнений как в React. И для определения изменений используется другая модель (шаблоны описываются деклативно, без js), которая базируется на концепциях самого Ember (computed properties и пр.). Хотя в случае с Glimmer могу ошибаться, так как еще не до конца разобрался в механизме его работы (он только вот недавно стал стабильным). Но про Glimmer по большей части говорили верно.

“В Angular могли бы применить такой подход…”. Кажется это архитектурно невозможно. В разметке используется вкропления кода, а так же директивы (по сути внешний код), которые делают непредсказуемой финальную разметку. То есть без исполнения всего “навешанного” кода мы не знаем, что получится и не можем это как то оптимизировать. Так же проблема Angular, что он постоянно взаимодействует с DOM напрямую (даже “инструкции” берет из него), а это большой оверхед. Virtual DOM тут вряд ли поможет, так как многое завязано на особенности DOM, но кажется это возможно. Но в таком случае получится более дорогой аналог React, с теми же проблемами.

Еще хочу заметить, что DOM шаблонизация – это не только производительность. Про это у меня уже было несколько докладов (http://www.slideshare.net/basisjs/), но пока меня не слышат 🙂 Это непаханное поле для адаптивных представлений (когда разметка подстраивается под данные и форм-фактор динамически), оптимизаций как итогового результата (сборки), так и самого процесса разработки и много чего другого. Для сложных приложений нужны инструменты, а практически все текущие шаблонизаторы ничего на этот счет не предоставляют. У React и Ember есть плагины для Chrome, которые предоставляют некоторую информацию, но этого явно недостаточно. У basis.js есть инструменты, которые позволяют получать практически полную информацию о шаблоне, понимать откуда что пришло и почему это выглядит так как выглядит, с быстрым переходом к исходнику и т.д. и мы активно развиваем это направление. Еще есть наследование шаблонов, изоляция стилей, live update (обновление шаблона без перезагрузки страницы), локализация, темы, анализ и т.д. Сейчас работаем над тестированием. Чтобы все это уметь, шаблонизатор должен быть устроен определенным образом. И некоторые моменты безусловно его замедляют, но не так радикально, если сравнивать с плюсами.

У Temple нет ничего кроме создания DOM фрагмента и расстановки значений в него – это крайне мало. Работает только с DOM, потому с изоморфностью сложнее. Основная фишка – он предельно прост и потому для определенных задач вполне может подойти (например, для мобильных приложений самое то, наверное). Но он явно не серебренная пуля.

Быть не может новый выпуск

По поводу темы “как уследить за новостями”, вот есть интересные ресурс
http://uptodate.frontendrescue.org/