Мысли о природе и преимуществах интерфейсных фреймворков. В частности, случай виртуального DOM для тех, кто ненавидит виртуальный DOM.
Это основано на моем собственном опыте и по определению не является репрезентативной выборкой опыта в отрасли.
В течение достаточно долгого времени мемом, окружающим интерфейсные фреймворки, была поддержка или деконструкция фразы «DOM медленный, виртуальный DOM быстрее. Чтобы быть ясным, я все еще считаю, что эта фраза на первый взгляд нелепа, вы все равно должны отразить свои изменения в DOM, и вы должны заранее выполнить diff. Однако с тех пор я пришел к тому, что, как мне кажется, могло послужить источником вдохновения для такого утверждения.
Чтобы быстро избавиться от проблемы, многие реализации vDom обеспечивают гораздо более быстрый доступ для чтения к тому, что было раньше, где обычные свойства элемента DOM, это фактически действует как быстрый кеш для более медленного носителя и на самом деле имеет реальные преимущества для приложений с тяжелое свойство DOM читает.
Однако сегодня мы смотрим на другой конец спектра: как именно vDom может ускорить работу приложений с большим количеством мутаций? Короткий ответ: если вы оптимальным образом закодируете такие обновления, их не будет. Длинный ответ заключается в том, что вы, вероятно, не оптимальным образом кодируете эти обновления, и vDom может уловить ваше намерение и выполнить его быстрее, чем вы на самом деле закодировали его.
Это равносильно тому, как сегодня работают оптимизирующие компиляторы. Вы МОЖЕТЕ получить более высокие скорости, перейдя на сборку, но только если ваш код оптимален по сравнению с тем, что может сделать компилятор. Количество людей, которые могут постоянно это делать, невелико, а количество команд, в которых каждый участник может это делать, еще меньше.
Сколько раз я видел код, который восстанавливает список узлов в событиях ввода окна поиска, просто головокружительно. Количество раз, когда я видел, как «опорожнить контейнер и снова наполнить его с нуля», просто шокирует. Иногда мы делаем это для скорости разработки. «Это не будет выполняться все время, поэтому я могу сделать это быстро и грязно. Иногда для простоты. С другой стороны, эти предположения могут быть нарушены в любой момент. Будущий член команды находит ваш аккуратный неоптимальный компонент и решает использовать его по всему проекту? Внезапно у вас появляются ненадежные замедления, которые вы должны отслеживать.
Все это к тому, что я наткнулся на то, что для многих, наверное, было очевидным. Что, хотя vDom в большинстве случаев технически медленнее, чем прямые обновления DOM, для переворота сценария требуется только один экземпляр наивных обновлений.
Спасибо, что прочитали мой мини-момент эврики, надеюсь, у вас отличный день!
