Уже давно в разных чатиках @xbgnx высказывает мысль о том что реакт и все остальные библиотеки для рендеринга медленные не потому что в них не достаточно оптимизаций, а потому что их там слишком много и они в своей сумме только тормозят конечное приложение. "Правильный путь" - ререндерить все на каждый чих и не пытаться по дороге что-то мемоизировать. В заголовке поста есть ссылка на похожие мысли от Доддса.
Недавно у меня состоялся еще один разговор, где мне показали очень быстрый фреймворк для построение интерфейсов на Rust - github.com/emilk/egui. В первом же примере ридми сразу бросается в глаза такой код: age += 1. А как потом библиотека понимает что нужно перерисовать места отображения age? А никак, весь шаблон приложения просто целиком пересчитывается с нуля. И это не тормозит!
Как такое может быть и если это правда, почему такой подход ещё не стандарт, спросите вы?
Любое кеширование стоит ресурсов: помимо занимаемой памяти нужно больше процессорных ресурсов на ее обслуживание (GC) и инвалидацию кеша. В продвинутых реактивных системах под капотом используются графы по которым нужно бегать, иногда, по несколько раз.
А зачем нужно кеширование? Для предотвращения избыточных вычислений (если они идемпотентны). И вот в чем хитрость. Алгоритмы обслуживания кешей или реактивных графах выполняются достаточно быстро, кешировать их в вакууме незачем. Те кто познали этот дзен уже достаточно опытные и хорошо понимают что такое сложность алгоритма и как писать оптимальный код. Когда такие люди пишут примеры кода фичи / приложения без кеширования, что бы сравнить перф, их наивная реализация уже является оптимизированной версией, по сравнению с кодом рядового разработчика из массы.
Те если кто-то пишет быстрый код без кеширования, скорее всего он заранее, специально или по привычке, продумал оптимальные структуры данных и алгоритмы их обхода и получившийся результат действительно может быть быстрее того что пишет средний разработчик на оптимальном фреймворке, Но это не объективное сравнение, тк условия разные - разные уровни разработчиков.
По моему опыту, большинство разработчиков пишут не оптимальный код и о его производительности просто не могут беспокоится в должной мере: что-то не знают, на что-то сейчас нет времени. Не важно на каком фреймворке / библиотеке - перегоняться из фичи в фичу или от слоя к слою данные будут с квадратичной сложностью.
Например. У вас есть приложение на редаксе и какой-то маппинг данных не замемоизирован или мемоизация сломана (частый кейс). Ну список чего-то там. При изменени любых других данных: инпута, нотификация пришла, лайк поставили - этот маппинг будет пересчитываться. У среднестатистического разработчинга в таком мапинге будет лежать линейная или квадратичная сложность. Опытный разработчик будет использовать константные мапы или ленивые итераторы и не будет понимать зачем ему все это кеширование.
someList.map(({id}) => anotherList.find(el => el.id === id))
VS
someList.map(el => anotherMap[el.id])
И тут нужно понять, не получится множество разработчиков научить писать всегда быстрый код, хотя бы потому что мерить и контролировать в автоматическом режиме это очень сложно. Но можно дать им библиотеки, которые сами будут пытаться делать какие-то оптимизации - снимать ответственность и позволять плохокодить.
Это не эффективный подход, но это продуктовый подход и в большенстве своем он работает. Если вы дадите толпам джунов / мидлов писать код без его принудительного кеширования оно очень быстро перестанет хоть как-то ворочиться, я это видел.