DOM медленный?
 

Уже в нескольких местах читаю, мол дом медленный. А есть какой-то пример, где можно посмотреть, что DOM медленный?

Я веду к тому, что это экономия на спичках или действительно проблема? Т.к. я с подобным не сталкивался, то хотелось бы знать где и при каких условиях подобное может возникнуть?

обычно такое возникает в циклах

Есть задачи, но в большинстве случаев тормозит из-за кривых рук.

Это слишком абстрактно, чтобы о чем-то говорило.

Вот bes, привел пример: Если вставить десять тысяч и более строк(tr + td или что-там jq вставляет) посредством jq, то будут тормоза. Вот по подобной причине я так понял, что ONLYOFFICE™ сделан на канвасе и отрисовывает только нужную часть.

Хотелось бы всё таки примеры. Я с подобной проблемой не сталкивался, т.к никогда не выводил за 1 раз более тысячи-двух строк основанных на DOM, поэтому мне и интересны примеры.

Да море их: рисование сложных графиков и графов, игры, различные гриды.

Вот последний пример из моей практики: SPA приложение, переход по ссылке со страницы А на страницу Б: если делать в лоб удаление старого DOM и построение нового то очень часто видны "тормоза" - фриз страницы на 200-300 мс, что недопустимо, поэтому фреймворк дробит задачи очистки мусора и рендеринга на потоки и делает всё постепенно, т.е. также делает сам браузер, когда мы переходим по страницам, но в случае SPA это перекладывается на фреймворк.

В большинстве случаев тормоза вызваны не оптимальными изменениями и вставками в DOM, а также не оптимальной работы с событиями.

есть такое дело. Например, такая ситуация:

object.isVisible = {Boolean};

в шаблоне в зависимости от флага показывается/скрывается элемент.
Флаг может меняться в ту или иную сторону, пока "не устаканится" :) Псевдо код

var i = 10; 
while(--i) {
    object.isVisible = Math.random() > 0.5;
}

Соответственно, если бы приложение рендерилось после каждого изменения, были бы жуткие лаги.

nerv_,
Ты по анимацию? Её нужно оптимизировать.

A и Б - страницы рендерится с нуля? Насколько сложный в страницах DOM? В SPA может быть частичное изменение DOM, внутри одного раздела не обязательно рендирить страницу с нуля.

Это ты про то, что лучше обработчик вешать на контейнер, а не на кучу вложенных элементов?

С нуля, т.к. абсолютно разные страницы. Частичные изменения в рамках страницы это частный случай.

Разный. Пока не ввёл многопоточный рендеринг фризы возникали часто.

Ясное дело, что мой пример очень специфичный, но он из реальной жизни.

Не только, но и это тоже. Например события типа mousemove и т.д. лучше вешать по требованию и снимать после работы, например, зажали мышку -> навесили -> отпустили мышку -> сняли.

Что-то я не догоняю. Это точно SPA? Я написал штук 10 разных SPA с совершенно различным назначением и только в одном из них приходилось рендерить (Частично!!!) больш`ую часть страницы и только там были заметны эти 200мс на которые можно было совершенно спокойно забивать болт, т.к. переходы между этими страницами редки и вряд ли могут быть недопустимыми. Очень похоже, что ты там веб-ОСь пилишь, а не SPA.

Я думал, что это очевидно должно быть всем?!

Думаю я понял твое высказывание про кривые руки.

Подитожим: DOM медленный, если руки из жопы или если нужны большие вставки/удаления DOM постоянно.

SPA - SPA рознь. Ты просил пример из жизни - я привёл. Но нет, не веб-ось :)

Сам пример: форум, открыт тред, бесконечный скролл пролистан вниз на 5-6 страниц и юзер жмакает перейти в настройки профиля. Между этими страницами общего только хедер и футер (и то частично) + различные виджеты вне страницы, как "чат-окошко" личных сообщений и т.д.. - это разумеется рендерить заного нет смысла, но сами страница абсолютно разные и этот переход реально фризит. Таких примеров много, как и переходов, т.к. у меня реально большой сайт с кучей страниц и всё работает в рамках SPA.

Ну, мы же это делаем не от хорошей жизни ;) Я лично был бы рад, чтобы браузер сам хитрил с оптимизациями, а я мог писать как проще.

В общем да. Хотя ещё можно добавить, если само дерево ОЧЕНЬ большое, то будет тормозить, хотя это редкий кейз и встречается опять таки в различных табличных процессорах (например, таблица 10е5 на 10e5 ячеек).

***

Возможно, когда выйдут новые поколения браузеров на всяких Servo, Blink 2 и т.д. то многие оптимизацию станут не нужны.

Вот ещё немного про DOM: http://habrahabr.ru/post/235333/

Safort, единственный недостаток insertAdjacentHTML - он сволочь длинный. И параметры у него длинные.))

Я перестал читать эту заметку после слов: Ключевое слово тут обычно. Так вот обычно это было лет 5 назад, а сейчас это древний баян. innerHTML сносит все обработчики и подобным способом просто невозможно адекватно пользоваться.

Ага, и называются странно. Не beforestart, а beforebegin :)

Мне вот интересно, какое максимальное количество обработчиков здешние гуру вешали в своих самых сложных веб-приложениях(и что это были за приложения такие)? Как это сказывалось на производительности?

По разному, я стараюсь не злоупотреблять. Сколько виджетов на странице, приблизительно столько же и обработчиков +- типы(click, dblclick, mouseEvenst ...). У меня в fj можно вешать и на data-item (дочерние элементы), но если их много 20 и более, то лучше все же повесить на родителя и отслеживать по target-у.

ситуации разные бывают
если вешать на родителя, то чем тебе плох innerHTML?
говоря "древний баян", имеешь в виду другие способы стали намного быстрее?

Да можно отстрелить себе ногу, зажарить и съесть, вместо того, чтобы почистить и зажарить картошку. Но зачем?


А ты значит считаешь, что нужно вместо добавления к родителю, вырезать из родителя все дочерние узлы, со всей их вложенностью и затем рендерить опять?

Может перестанешь глупости писать? Очевидно, что добавление к родителю быстрее, чем перерендеринг старых эл+навешивание на них заново событий, если это вообще возможно, и рендеринг опять вместе с новыми.

Да это баян, дикий, ДРЕВНИЙ баян! Раньше небыло выхода, но стрелять себе в ногу уже минииум 5 лет как не нужно.

слишком абстрактно

про отрисовку каких старых элементов идёт речь, если все они должны быть уничтожены и заменены новыми?
про навешивание обработчиков каких событий идёт речь, если они навешаны на родителя?

Ты когда делаешь цитаты, делай пожалуйста так, чтобы было понятно, что ты имеешь в виду. Мне лень читать весь тред, чтобы понять что ты имеешь в виду обработчики, а не элементы.

То ты меня цитируешь сообщениями целиком, то вырезаешь неполными кусками выдирая из контекста. Ты уж определись.

Тебе никто не запрещает использовать innerHTML, но по моему мнению, удаление элементов и вставка должны быть разделены. Это 2 действия, а не одно.

К элементам могут быть прикреплены ссылки и обработчики. Задумываться каждый раз будут или не буду я не собираюсь. Это приведет лишь к лишним ошибкам, которые можно избежать не использую innerHTML.

Помимо всего прочего может сохраниться немалая доля мусора в других, не DOM объектах, которые нужно будет искать и очищать, т.к. сборщик никогда их не найдет.