Комментарии 31
А можно ссылку на Ваше расширение?
По поводу кеширования нодов: лично я когда делал микробенчмарков то у меня клонирование элементов было не быстрее чем создание с нуля + патчинг, а на некоторых моментах даже медленнее. Учитывая геморрой который сопровождает клонирование элементов, я так и не понял в чем бонус. Буду рад ссылке на подробное исследование этого момента.
Не понял о каких трудностях связанных с клонированием (учитывая что этот код не нужно каждый раз писать) идёт речь. Я, наверно, плохо описал как именно используется шаблонизация, уделив больше внимания собственно реализации. О каких проблемах идет речь?
Например, value у input/textarea не клонируется
Во первых клонируется.
О том, что при клонировании нодов свойства объектов (являющихся интерфейсом к dom node) не клонируются я писал. Если нам очень надо клонировать свойство, то это надо делать либо как я описал выше, либо через setAttribute().
Во вторых зачем клонировать эти свойства из шаблона, если мы их меняем их и пользуемся в экземпляре?
О том, что при клонировании нодов свойства объектов (являющихся интерфейсом к dom node) не клонируются я писал. Если нам очень надо клонировать свойство, то это надо делать либо как я описал выше, либо через setAttribute().
Во вторых зачем клонировать эти свойства из шаблона, если мы их меняем их и пользуемся в экземпляре?
Клонирование корневого нода структуры было медленней, чем result_node.innerHTML = '.....' или медленней чем
var div = document.createEment('div');
var pp = document.createEment('p');
div.appendChild(pp)?
Т.е. такое поэлементное воссоздание даже для большой структуры
будет быстрее чем клонирование каким-нибудь таким кодом?
var div = document.createEment('div');
var pp = document.createEment('p');
div.appendChild(pp)?
Т.е. такое поэлементное воссоздание даже для большой структуры
Реальный код из приложения
<div class="playlist_panel" pv-nest="plarow">
<div class="playlist-actions">
<div class="pla-panel">
<span class="pla-button" pv-anchor="btrow-multiatcs" pv-events="click::switchPart:row-multiatcs" pv-type="way-point">● ● ●</span>
<span class="pl-settings-button" title="Playlists settings" pv-anchor="btrow-pl-settings" pv-events="click::switchPart:row-pl-settings" pv-type="way-point"></span>
</div>
<div
pv-anchor="row_context"
class="pla-row-content has-dark-buttons hidden"
pv-class="pla-row-content has-dark-buttons {{!active_part && 'hidden'}}"
style="position:relative">
<span class="rc-arrow hidden" pv-anchor="arrow" pv-props="style.left: {{arrow_pos}}" pv-class="rc-arrow {{!active_part && 'hidden'}}">
<span class=" rc-s-arrow arrow-part"><span class="rc-s-arrow-bg arrow-part"></span></span>
</span>
<div class="pla-row hidden" pv-nest="context_parts for_model:row-multiatcs" pv-class="pla-row {{!active_view && 'hidden'}}">
<div class="left-buttons-group">
<span class="button-hole">
<a
pv-events="click::makePlayable"
pv-type="way-point"
class="search-music-files nicebutton lang localize-playlist-getmp3">Find files for compositions</a>
</span>
<!-- href="http://seesu.me/generated_files/seesu_playlist.m3u"-->
<span class="button-hole">
<a
pv-events="click::makeExternalPlaylist"
pv-type="way-point"
class="open-external-playlist nicebutton lang localize-playlist-export">Save playlist to *.m3u file</a>
</span>
</div>
</div>
<div class="pla-settings hidden" pv-nest="context_parts for_model:row-pl-settings" pv-class="pla-settings {{!active_view && 'hidden'}}">
<label class="dont-rept-pl">
<input type="checkbox" pv-anchor="dont-rept-pl"/>
<span class="lang localize-dont-rept-pl">Do not repeat playlist</span>
</label>
</div>
</div>
</div>
<div
class="loader_disallowing_desc hidden"
pv-class="loader_disallowing_desc {{!loader_disallowing_desc && 'hidden'}}"
pv-text="{{loader_disallowing_desc}}"
></div>
</div>будет быстрее чем клонирование каким-нибудь таким кодом?
var samples = {};
var getSourceNode = function( sample_name ){
if (!samples[sample_name]) {
samples[sample_name] = $( '.' + sample_name )[0];
}
return samples[sample_name];
};
var instance1 = getSourceNode('playlist_panel').cloneNode(true);
var instance2 = getSourceNode('playlist_panel').cloneNode(true);
var instance3 = getSourceNode('playlist_panel').cloneNode(true);
Чем document.createEment('div');, конечно. Я пробовал использовать cloneNode для «шаблонизации» небольших элементов списка (элементов 10) и в результате код с клонированием + модификации работал не быстрее воссоздания элементов с нуля.
Именно клонирование корневого элемента с помощью cloneNode(true)? где true значит «клонировать, но только сам нод, но и всё дерево»
Где-то есть на jsperf.com код?
Я готов написать свою часть которая будет отвечать оговорённым требования шаблонизации по результату и возможностям, вроде
1) какая-то большая структура
2) нужно будет получить 100 экземпляров
3) при передаче новых данных в экземпляр соотствествующие части будут автоматически обновлены
Можно договориться об этих требованиях и кому интересно — предоставят реализации для тестирования. Ну и соответственно потом замерять скорость получения первого экземляра, скорость получения последующих, скорость применения изменений.
Где-то есть на jsperf.com код?
Я готов написать свою часть которая будет отвечать оговорённым требования шаблонизации по результату и возможностям, вроде
1) какая-то большая структура
2) нужно будет получить 100 экземпляров
3) при передаче новых данных в экземпляр соотствествующие части будут автоматически обновлены
Можно договориться об этих требованиях и кому интересно — предоставят реализации для тестирования. Ну и соответственно потом замерять скорость получения первого экземляра, скорость получения последующих, скорость применения изменений.
я не видел шаблонизаторов, основанных на клонировании нодов, поэтому каких-то чужих тестов не видел, а свои тесты не делал
мне кажется, или это ну уж очень похоже на ангуляр..?
в чём плюсы относительно ангуляра?
в чём плюсы относительно ангуляра?
Похожа только часть отвечающая за представление.
Для меня плюсы заключаются в том, что у меня реальное разделение на MVC в отличии от angularjs, и нет проблем с производительностью при работе со списками.
Angularjs, построен так, что просто отрендерить большой список и изменить какое-нибудь поле у одного из элементов выливается в геморой с производительностью (он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всё)
Для меня плюсы заключаются в том, что у меня реальное разделение на MVC в отличии от angularjs, и нет проблем с производительностью при работе со списками.
Angularjs, построен так, что просто отрендерить большой список и изменить какое-нибудь поле у одного из элементов выливается в геморой с производительностью (он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всё)
а можно поподробнее про «реальное разделение на MVC»?
т.е. где в AngularJS оно нереальное, и как оно должно быть на самом деле..?
По поводу проблем с производительностью — не совсем правда, т.е. проблемы возникают при ну оочень больших списках, и есть способы с этим бороться. Вот, к примеру, реализация таблички — gdepourtales.github.io/ng-cells/performance.html#?rows=5000&cols=1000
Для личного развития — я всецело «за». Но преимуществ перед более-мнее сложившимися фреймворками не вижу.
т.е. где в AngularJS оно нереальное, и как оно должно быть на самом деле..?
По поводу проблем с производительностью — не совсем правда, т.е. проблемы возникают при ну оочень больших списках, и есть способы с этим бороться. Вот, к примеру, реализация таблички — gdepourtales.github.io/ng-cells/performance.html#?rows=5000&cols=1000
Для личного развития — я всецело «за». Но преимуществ перед более-мнее сложившимися фреймворками не вижу.
В том примере скроллинг не нативный; шаг скроллинга не пиксел, а целая строка, что точно не плюс. «не совсем правда», «есть способы с этим бороться» — не хотелось бы заниматься борьбой с фреймворком и постоянно решать одну и туже проблему (даже если решение известно, хотя то, что по ссылке точно не решение)
Чтобы понять как должно быть организовано реально разделение на MVC нужно представить как использовать angularjs в системе, где ядро приложения (с моделями) находится в отдельной области видимости от представления (где вьюхи) и они могут общаться между собой чем-нибудь вроде window.postMessage, вьюха может быть полностью уничтожена, и иногда её нужно полностью воссоздать заново. Представить как использовать angularjs в системах, которые построенный на этом принципе, таких как www.appcelerator.com/titanium/. Нужно понять как во view будет передаваться структура/взаимосвязи моделей, их состояний, как будут передаваться оперативные обновления состояний, структуры во вьюхи, и как будет поставляться обратная связь из вьюх в модели.
Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.
Пока никому не предлагаю использовать свой «велосипед». Действительно трудно найти преимущества, когда я о них не рассказываю :)
С другой стороны непонято — о каких именно «более-менее сложившихся фреймворках» идёт речь в контексте рендеринга? О каких фрейморках с выдающейся системой рендеринга вы знаете? Я знаю только шаблонизацию angularjs и шаблонизацию facebook react (это не mvc фрейморк), но facebook react опубликован 25 мая 2013 github.com/facebook/react/tree/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4, а я начал внедрять декларативную шаблонизацию в стиле angularjs примерно в феврале 2013 (при этом у меня уже было до этого атомарное изменении DOM) и к концу апреля 2013 у меня была работающее в декларативном стиле решение, покрывающее большинство вещей, требующихся мне. И с тех пор я в той части занимался в основном оптимизациями. Какой выбор был тогда у меня и какой сейчас?
Чтобы понять как должно быть организовано реально разделение на MVC нужно представить как использовать angularjs в системе, где ядро приложения (с моделями) находится в отдельной области видимости от представления (где вьюхи) и они могут общаться между собой чем-нибудь вроде window.postMessage, вьюха может быть полностью уничтожена, и иногда её нужно полностью воссоздать заново. Представить как использовать angularjs в системах, которые построенный на этом принципе, таких как www.appcelerator.com/titanium/. Нужно понять как во view будет передаваться структура/взаимосвязи моделей, их состояний, как будут передаваться оперативные обновления состояний, структуры во вьюхи, и как будет поставляться обратная связь из вьюх в модели.
Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.
Пока никому не предлагаю использовать свой «велосипед». Действительно трудно найти преимущества, когда я о них не рассказываю :)
С другой стороны непонято — о каких именно «более-менее сложившихся фреймворках» идёт речь в контексте рендеринга? О каких фрейморках с выдающейся системой рендеринга вы знаете? Я знаю только шаблонизацию angularjs и шаблонизацию facebook react (это не mvc фрейморк), но facebook react опубликован 25 мая 2013 github.com/facebook/react/tree/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4, а я начал внедрять декларативную шаблонизацию в стиле angularjs примерно в феврале 2013 (при этом у меня уже было до этого атомарное изменении DOM) и к концу апреля 2013 у меня была работающее в декларативном стиле решение, покрывающее большинство вещей, требующихся мне. И с тех пор я в той части занимался в основном оптимизациями. Какой выбор был тогда у меня и какой сейчас?
Так я и не понял из Вашего объяснения, чем AngularJS — не MVC, и что там сделано не так, как должно быть.
жаль.
жаль.
Если вам нравится дата-байндинги, посмотрите на библиотеку KnockoutJS. мне очень нравится то, что она предоставляет именно шаблонизатор и ничего больше и в этом случае её можно удобно интегрировать в свой фреймворк.
он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всёМожно сделать директиву которая будет «точечно» обновлять по команде без проверок изменений, просто обычно этого не требуется.
Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.Ну, ещё и директивы.
Посмотрите в сторону shadow dom и вообще веб-компонентов, полимер тут в самый раз.
Вы-то это можете, у вас все под вебкит тут заточено последний.
Если рассказывать кратко — та же изоляция на уровне дом-дерева, но при этом гораздо более удобный интерфейс.
Вы-то это можете, у вас все под вебкит тут заточено последний.
Если рассказывать кратко — та же изоляция на уровне дом-дерева, но при этом гораздо более удобный интерфейс.
Есть полезные статьи от Google и Opera на эту тему:
Optimizing JavaScript
Minimizing reflows
Efficient JavaScript
Там также есть примеры оптимизации кода.
Optimizing JavaScript
Minimizing reflows
Efficient JavaScript
Там также есть примеры оптимизации кода.
о других реализациях техник оптимизаций на системном уровне о которых вы знаете
В местах где jQuery вызывается часто, можно заменить jQuery на что-нибудь полегче, либо на «нативные» вызовы, т.к. иногда создание «jQuery объекта» дороже вызова целевого метода. Пример.
Таким методом я ускорил одно толстое приложение в 2 раза.
Метод хороший, но не уверен, что тест показательный. В каком реальном проекте вам нужно выбирать теги 500000 подряд? Смысл этого, ведь достаточно, как правило 1 раза :). Да и странновато — подключать angular light с fquery для вызова нативных методов. А в целом да, писать нативно с полифилами лучше, чем писать jQuery.
В каком реальном проекте вам нужно выбирать теги 500000 подряд?Но jQuery используется не только для выборок, вот пример выборка + замена текста, 5 тыс итераций. Т.е. сэкономить все же можно.
Да и странновато — подключать angular light с fquery для вызова нативных методов.Согласен, просто тут он оказался под рукой (для вывода результатов).
Вместо «эвАлюционировал» надо «эвОлюционировал». Проверочное слово: «Mitsubishi Lancer EvOlution».
Статья очень крутая! Такого количества оптимизаций и такого сложного продукта ждешь скорее от какого-нибудь софтверного гиганта, чем от разработчика, ковыряющего это в свободное время. Во всем ангуляре поди оптимизаций меньше :) Легко представить аналогичного уровня статью, например, «как мы делали чтобы Яндекс.Музыка не тормозила в браузере». Хотя по ощущениям она и попроще, и по-тормознее будет.
Анимация, 2 кадра. Прогрессивный рендеринг: сначала гарабиты, потом детали. Словить момент, и запечатлить первую часть удалось только в режиме отладки, отчего видно затемнение.
Если так быстро рисуется, стоит ли заморачиваться с прогрессивным рендерингом?
иногда список может быть большой, иногда нужно полностью восстановить большую DOM структуру
Например, тут chrome.google.com/webstore/detail/seesu-music/nhonlochieibnkmfpombklkgjpkeckhi когда popup закрывается его document удаляется, и при новом открытии приходится работать с новым документом
Например, тут chrome.google.com/webstore/detail/seesu-music/nhonlochieibnkmfpombklkgjpkeckhi когда popup закрывается его document удаляется, и при новом открытии приходится работать с новым документом
кроме того оптимизация реализована, и мне не нужно об этом думать :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка