DOM медленный?

[kobezzza]

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

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

Насколько сложный в страницах DOM?

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

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

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

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

[Gozar]

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

фриз страницы на 200-300 мс, что недопустимо

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

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

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

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

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

[kobezzza]

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

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

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

Я думал, что это очевидно должно быть всем?!
Думаю я понял твое высказывание про кривые руки.

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

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

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

***

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

[Safort]

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

[Aetae]

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

[Gozar]

Вот ещё немного про DOM

Я перестал читать эту заметку после слов:

кусок HTML-кода в виде строки, полученной через AJAX-запрос, обычно в таком случае мы помещаем этот код в родительский элемент через свойство innerHTML:

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

И параметры у него длинные.))

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

[Safort]

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

[Gozar]

какое максимальное количество обработчиков

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

[bes]

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

то лучше все же повесить на родителя и отслеживать по target-у.

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

[Gozar]

ситуации разные бывают

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

если вешать на родителя, то чем тебе плох innerHTML?

innerHTML сносит все обработчики

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

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

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

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