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

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

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

Не только, но и это тоже. Например события типа 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 лет как не нужно.