Стрим завершен с успехом. Запись доступна (в теле поста эта же ссылка). Спасибо @Alexblbl за интересно проведенное время. С ним мы вместе напишем наши послестримные мысли в этой теме.
Скорее всего будем повторять этот опыт, возможно в другом составе так что если нравится - пишите об этом, подписывайтесь, оставляйте свои темы/вопросы где удобно.
Во время подкаста поднимался вопрос по поводу оптимизации и уже доступен ответ:
Oleksandr Tserkovnyi, [May 19, 2019 at 9:27:54 PM]: @PaulMaly Паша привет, давеча слушал несколько раз 54 выпуск, про svelte первый вопрос, который сразу же бросился на язык и думал его зададут, но так и не услышал его это:
Не просто так выдумали Virtual DOM, он решал помимо прочего проблему того что операции с DOM очень тяжеловесны и именно reconcile (и его подобия) делали это оптимизированно, так чтобы App работал как можно быстрей с операциями DOM. Так как же svelte решает эту задачу?
Pavel Malyshev, [May 19, 2019 at 9:55:22 PM (5/19/19, 9:55:38 PM)]:
Решает с помощью AoT-компиляции
Pavel Malyshev, [May 19, 2019 at 10:51:28 PM (5/19/19, 10:52:17 PM)]:
Ещё развить тему дальше , «тяжеловесны» операции в DOM, только если действовать по принципу чистой функции от параметров. На чем собственно основан Реакт. Тогда да, если на любое изменение стейта делать ререндеринг всего компонента сразу в реальный DOM, тогда рехнёшься на чуть более динамичных приложениях. Поэтому реакт делает этот полный ререндер в относительно дешёвом vdom и с помощью сравнения с предыдущим рендером определяет какие вещи реально поменялись и требуют манипуляций с реальным DOM. Это своего рода change detection на деревьях. Svelte, с помощью статического анализа и AoT компиляции, выкидывает максимум рантайм вычислений в билдтайм. Поэтому его change detection в рантайме сводится к проверки заранее подготовленных строгих сравнений. Если сравнение проходит, то происходит заготовленная манипуляция в DOM по заранее закешированным элементам, то есть нет даже querySelector операции.
