Комментарии 18
Посмотрите на современные социальные сети, такие как Twitter, Facebook или Pinterest.
После небольшого скроллинга, мы будем иметь десятки тысяч DOM-узлов, эффективно взаимодействовать с которыми — задача не из легких.
Для меня это никогда не было проблемой. Это, скорее, не оптимальная разработка, навешивание лишнего, костылей. Допустим, нередко видел как для изменения содержания поля вешают целую библиотеку JQery, вместо строчки document.getElementById(«input»).value = 'value'.
ммм… то есть вы думаете что если разработчик при реализаци фичи делает N операций с DOM то от того что он заменит одно API другим что-то сильно поменяется?
Ну да, узкое место это установка значений (к слову у вас там вопервых ошибка, во вторых если это надо сделать один раз то можно что угодно использовать, проблема когда это делается в цикле, а если вы подобное делаете в цикле то это еще хуже чем использовать jquery, выборки по селекторам проще реюзать сохранив ссылку на элемент в переменной).
Вот такие вот вещи хэндлит за вас виртуальный DOM. Перестраивайте там все хоть по 10 раз в цикле, виртуальный DOM это все заоптимизирует и попробует максимально эффективно применить к реальному DOM. В итоге достигается основная цель, сделать нормальный сложный интерфейс выходит сильно дешевле.
document.getElementById(«input»).value = 'value'.
Ну да, узкое место это установка значений (к слову у вас там вопервых ошибка, во вторых если это надо сделать один раз то можно что угодно использовать, проблема когда это делается в цикле, а если вы подобное делаете в цикле то это еще хуже чем использовать jquery, выборки по селекторам проще реюзать сохранив ссылку на элемент в переменной).
Вот такие вот вещи хэндлит за вас виртуальный DOM. Перестраивайте там все хоть по 10 раз в цикле, виртуальный DOM это все заоптимизирует и попробует максимально эффективно применить к реальному DOM. В итоге достигается основная цель, сделать нормальный сложный интерфейс выходит сильно дешевле.
Не убедительно. Хотите сказать, что повесить библиотеку и дописать на ней, фактически, такое же количество кода будет быстрее самого кода на чистом JS?
Дело не в количестве кода, а удобстве для пользователя, у которого браузер будет меньше лагать. Главное — это пользователь
Дело не в библиотеке, а в подходе.
Как написали выше, подход с использованием виртуального DOM помогает экономить на обращениях к обычному DOM, за счет чего и достигается прирост производительности — чем сложнее интерфейс, тем больше экономим.
Вам никто не запрещает реализовать этот подход самому и не использовать библиотеки.
Как написали выше, подход с использованием виртуального DOM помогает экономить на обращениях к обычному DOM, за счет чего и достигается прирост производительности — чем сложнее интерфейс, тем больше экономим.
Вам никто не запрещает реализовать этот подход самому и не использовать библиотеки.
Я думаю, изначально VDOM — это компромис или абстракция над DOM операциями. Чтобы разработчик не думал о том как эффективней вставить элемент, а занимался совсем другим — композицией данных и компонентов.
10 лет пишу код и точно могу сказать, что любая библиотека это потеря производительности. Библиотека никак не способствует приросту производительности.
Буквально вчера писал код, который после перетаскивания объекта (jquery.ui dropping) должен перетаскиваемый объект переместить внутрь того, на который его бросаем.
$(obj).detach();
$(destination).append(obj);
Всего пользователь может перетащить порядка 20 объектов сразу друг за другом. где-то после 5-го броска chrome и firefox начинают надрываться.
Без контекста сложно понять зачем делать изменения в DOM, но задача была не портить ранее написанный код и применить для выравнивания объектов css (float:left). Лень двигатель прогресса :)
$(obj).detach();
$(destination).append(obj);
Всего пользователь может перетащить порядка 20 объектов сразу друг за другом. где-то после 5-го броска chrome и firefox начинают надрываться.
Без контекста сложно понять зачем делать изменения в DOM, но задача была не портить ранее написанный код и применить для выравнивания объектов css (float:left). Лень двигатель прогресса :)
Реальная крутизна virtual-dom чувствуется, когда ты начинаешь работать со всем документом как с целым значением. Т.е. не ищешь элемент который надо поменять, а тупо генеришь заново весь виртуальный документ целиком. Это очень удобно, так как логика поведения приложения превращается в последовательность состояний документа (с точки зрения кода). А как точечно применить изменения за тебя думает virtual-dom. Конечно, все это не без ньюансов, но в целом идея очень многим нравится.
Ну так и что, есть пример перемещения 1.000 div-ов, с использованием Virtual DOM?
Понимаю, что перевод, но:
В Pinterest никаких тысяч, а тем более десятков тысяч элентов не будет. Там всегда около 100-150 элементов и при скроллинге одни удаляются и вставляются новые или просто содержимое заменяется.
Посмотрите на современные социальные сети, такие как Twitter, Facebook или Pinterest.
После небольшого скроллинга, мы будем иметь десятки тысяч DOM-узлов, эффективно взаимодействовать с которыми — задача не из легких.
В Pinterest никаких тысяч, а тем более десятков тысяч элентов не будет. Там всегда около 100-150 элементов и при скроллинге одни удаляются и вставляются новые или просто содержимое заменяется.
Если не удалять/заменять то как раз таки тысячи и будут. Суть именно в оптимизациях.
Так ведь, как раз «React is a JavaScript library for creating user interfaces by Facebook and Instagram.»
facebook.github.io/react/docs/why-react.html
facebook.github.io/react/docs/why-react.html
По поводу конкретно Pinterest — есть такое упоминание:
React is a Facebook project and is what fuels FB’s comment system and most of FB’s projects. It’s also largely used on Pinterest, AirBnB, Khan Academy and a plethora of other startups. Atom, the “hackable editor”, is now built on it and I heard Microsoft is also supporting the project.Все они используют подобный подход, иначе бы было именно так, как написал автор.
Наткнулся на ссылку «Virtual DOM Benchmark».
Возможно, будет интересно: vdom-benchmark.github.io/vdom-benchmark
Рассмотреные реализации:
Возможно, будет интересно: vdom-benchmark.github.io/vdom-benchmark
Рассмотреные реализации:
- uix
- cito.js
- Bobril
- React
- virtual-dom
- mithril
- maquette
- dom-layer
Смотреть на цифры в этом бенчмарке, не имея глубокого представления о том как работают либы в этом бенче не имеет смысла, этот бенч больше для разработчиков вдом либ, чем для окружающих.
React создает легковесное дерево из JavaScript-объектов для имитации DOM-дерева.
Подскажите, а в чем суть такого "легковесного" дерева и чем оно отличается от обычного? Если вам известно. Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Что такое Virtual DOM?