Допустим, у нас есть группа разработчиков на PHP, которые знают чуть чуть JS и jQuery. Что самое простое мы можем сделать, чтобы начали писать браузерное приложение, и были продуктивны немедленно
( Read more... )
Думаю, мне придется опять собрать свой тест, как я это делал несколько лет назад. Когда я измерял, разница была в десятки раз. Могло, конечно, что-то поменяться с тех пор, но это не правильно измерять микротестом, как в приведенных статьях, добавляя один div.
Когда мы в бэкбон разворачиваем шаблон в текст, и присваиваем его в innerHTML, во-первых, обработки событий не трогаются вообще, потому, что они висят на корневом узле, а во-вторых, рендеринг и расчет лэйаута происходит один раз.
Когда мы вставляем узлы по одному, происходит многократный рендеринг видимой области, потенциально - с перестройкой лэйаута. Эти микротесты устроены так, что они изолируют эту проблему, и это незаметно. Если же мы начнем ковыряться где-нибудь в недрах сложного и красивого документа, расклад должен быть уже совсем другим. Или, например, добавление одной строки таблицы в простом случае приводит к вычислению размеров ее колонок заново, так, что рендеринг через добавление узлов получает сложность O(N^2).
Сейчас без всякого теста - что я вижу в своем приложении, которое во многих местах делает render при обновлении в стиле бэкбон. Он делается моментально, пока я не добавляю в шаблон кастомные тэги x-tag, которые разворачиваются через DOM-манипуляцию. И вместо кина я вижу слайд-шоу. Я искренне надеюсь, что дело здесь не только в DOM-манипуляции, иначе нам не поможет выпиливание x-tag и замена view-layer на React.
И на то, что React делает ее не так тупо. React, по крайней мере, не будет делать лишних манипуляций, когда ничего в DOM не поменялось.
Вроде бы если вставить N узлов внутри одной js-функции, и не спрашивать в процессе у вставленных элементов clientWidth/Height/scrollOffset и прочие штуки, которые триггерят лайаут, рендеринг тоже вызовется один раз, по выходу из функции.
А что за обработки событий, которые висят на корневом узле?
> Вроде бы если вставить N узлов внутри одной js-функции, и не спрашивать в процессе у вставленных элементов clientWidth/Height/scrollOffset и прочие штуки, которые триггерят лайаут, рендеринг тоже вызовется один раз, по выходу из функции.
Это лучше, но все равно плохо. Особенно, если хочется мелкие виджеты использовать, здесь явно не обойдешься одной функцией. x-tag и polymer, например, не могут, и разворот тэгов в реальном приложении тормозит нечеловечески.
Если бы был явный интерфейс, чтобы делать транзакции на DOM-дереве, это бы помогло. Что, в общем, и происходит при присваивании innerHTML. Он и есть такой интерфейс, пусть немного кривой. Впрочем, почему немного. Сильно кривой.
> А что за обработки событий, которые висят на корневом узле?
При повторном рендеринге, когда DOM-дерево удаляется, браузер снимает обработчики событий с элементов поддерева, и если их много - это реально медленно.
Бэкбон же вешает обработчики на корневой элемент, которому меняет innerHTML, так что при обновлении не надо ни от чего отписываться, и все происходит быстро. Это не имеет большого значения, если использовать DOM-манипуляцию, насколько я понимаю - ничего не удаляется. А если имеет - никто не мешает делать так же.
> Это лучше, но все равно плохо. Особенно, если хочется мелкие виджеты использовать, здесь явно не обойдешься одной функцией.
Речь об одной top-level функции, внутри вложенность может быть какая угодно.
Кстати я правильно понимаю что backbone это только initial rendering, живое приложение на нем не сделать? Скажем, если у корневого элемента добавился класс, весь шаблон перерендеривать и переприсваивать innerHTML же не станешь?
> x-tag и polymer, например, не могут, и разворот тэгов в реальном приложении тормозит нечеловечески.
Это проблема конкретных фреймворков, не самого DOM API?
>> x-tag и polymer, например, не могут, и разворот тэгов в реальном приложении тормозит нечеловечески.
> Это проблема конкретных фреймворков, не самого DOM API?
Когда я увижу конкретные фреймворки, полагающиеся на DOM API, лишенные этих проблем в реальном приложении, не на микротестах, я соглашусь. Пока чо-та везде одни проблемы конкретных фреймворков, да куча советов как это ускорить, сводящихся к "не рендери слишком много". А быстро все только теоретически.
И кроме того, про то, что браузер обновляет DOM только при попадании в глобальный цикл, здорово бы было увидеть пруфлинк. Еще несколько лет назад я в тестах своими глазами видел, что это не так.
Когда мы в бэкбон разворачиваем шаблон в текст, и присваиваем его в innerHTML, во-первых, обработки событий не трогаются вообще, потому, что они висят на корневом узле, а во-вторых, рендеринг и расчет лэйаута происходит один раз.
Когда мы вставляем узлы по одному, происходит многократный рендеринг видимой области, потенциально - с перестройкой лэйаута. Эти микротесты устроены так, что они изолируют эту проблему, и это незаметно. Если же мы начнем ковыряться где-нибудь в недрах сложного и красивого документа, расклад должен быть уже совсем другим. Или, например, добавление одной строки таблицы в простом случае приводит к вычислению размеров ее колонок заново, так, что рендеринг через добавление узлов получает сложность O(N^2).
Сейчас без всякого теста - что я вижу в своем приложении, которое во многих местах делает render при обновлении в стиле бэкбон. Он делается моментально, пока я не добавляю в шаблон кастомные тэги x-tag, которые разворачиваются через DOM-манипуляцию. И вместо кина я вижу слайд-шоу. Я искренне надеюсь, что дело здесь не только в DOM-манипуляции, иначе нам не поможет выпиливание x-tag и замена view-layer на React.
И на то, что React делает ее не так тупо. React, по крайней мере, не будет делать лишних манипуляций, когда ничего в DOM не поменялось.
Reply
А что за обработки событий, которые висят на корневом узле?
Reply
Это лучше, но все равно плохо. Особенно, если хочется мелкие виджеты использовать, здесь явно не обойдешься одной функцией. x-tag и polymer, например, не могут, и разворот тэгов в реальном приложении тормозит нечеловечески.
Если бы был явный интерфейс, чтобы делать транзакции на DOM-дереве, это бы помогло. Что, в общем, и происходит при присваивании innerHTML. Он и есть такой интерфейс, пусть немного кривой. Впрочем, почему немного. Сильно кривой.
> А что за обработки событий, которые висят на корневом узле?
При повторном рендеринге, когда DOM-дерево удаляется, браузер снимает обработчики событий с элементов поддерева, и если их много - это реально медленно.
Бэкбон же вешает обработчики на корневой элемент, которому меняет innerHTML, так что при обновлении не надо ни от чего отписываться, и все происходит быстро. Это не имеет большого значения, если использовать DOM-манипуляцию, насколько я понимаю - ничего не удаляется. А если имеет - никто не мешает делать так же.
Reply
Речь об одной top-level функции, внутри вложенность может быть какая угодно.
Кстати я правильно понимаю что backbone это только initial rendering, живое приложение на нем не сделать? Скажем, если у корневого элемента добавился класс, весь шаблон перерендеривать и переприсваивать innerHTML же не станешь?
> x-tag и polymer, например, не могут, и разворот тэгов в реальном приложении тормозит нечеловечески.
Это проблема конкретных фреймворков, не самого DOM API?
Reply
> Это проблема конкретных фреймворков, не самого DOM API?
Когда я увижу конкретные фреймворки, полагающиеся на DOM API, лишенные этих проблем в реальном приложении, не на микротестах, я соглашусь. Пока чо-та везде одни проблемы конкретных фреймворков, да куча советов как это ускорить, сводящихся к "не рендери слишком много". А быстро все только теоретически.
Reply
Reply
Leave a comment