Планировщик задач: не замораживаем вкладку при открытии страницы

[BigDflz]

почему нельзя сформировать полностью готовую страницу на сервере? а уж если что-то юзер вводит обрабатывать. а то получается передаем заготовку, передаем данные, и загружаем их в заготовку. причем не используем innerHTML. какая разница серверу формировать сразу строку html, и ещё json, передавать клиенту, а там парсить json, заполнять объекты? для браузера проще и быстрее обработать одну строку html. не делать т.н. серверный рендеринг, тратя время на формирование json, а потом преобразовывать в html, а сразу строить конечный html, уж если гонимся за милисекундами , то надо во всей системе, а не кровати двигать

[mayorovp]

Используемое в статье слово "гидратация" как раз и подразумевает, что начальное состояние страницы формируется полностью на сервере.

[ru1z]

Гидратация — это вывод генерируемой сервером страницы? А «гидрировать» — это применять гидратацию на клиенте? Ну точно «Иван Тулуп», поиск в интернете становится все более запутанным.

[skeevy]

Гидратация - инициализация скриптов на клиенте, потому что изначально они выполнились на сервере, а точнее - "довешивание" отсутсвующих событий и т.д.

[victor-homyakov]

https://letmegooglethat.com/?q=что+такое+гидратация+React

Даже здесь на Хабре можно найти какое-никакое описание: https://habr.com/ru/post/515100/

[ru1z]

Мой коммент вообще не об этом, погуглите «гидрировать», к примеру. Душность заключается в том, что оригинальный термин, ну, так себе, захламляет поиск нужного значения, кто-то обязательно поймет не так как нужно, и он становится еще более странным при переводе на русский. Вот у вас в комментарии ниже, более логичное использование, имхо.

[victor-homyakov]

не делать т.н. серверный рендеринг, тратя время на формирование json, а потом преобразовывать в html, а сразу строить конечный html

Вы неправильно понимаете смысл термина "серверный рендеринг" (SSR). Именно про это в статье и написано - на сервере SSR, клиенту отдаётся строка HTML. Никакого JSON. Но на полученный HTML надо навесить обработчики, оживить реактовые компоненты. Это называется "гидрация" или "гидратация". Так вот гидрация может быть тяжёлой, и пока она не закончится - браузер может не реагировать на пользовательский ввод.

[BigDflz]

на сервере SSR, 

ssr - это преобразование чего-то, в html. а зачем это "чего-то" ? почему нельзя сразу в html?
>>Но на полученный HTML надо навесить обработчики - это ж сколько обработчиков надо навешать?
вообще то обработчики располагаются в конце страницы и вступают в действие когда вся страница уже отрендерена браузером.
>> оживить реактовые компоненты. это ж надо городить ещё такое, что б ещё и оживлять.

[BigDflz]

как раз я правильно понял, да на сервере создается строка html, но она создается в два приема, сначала строится нечто вроде json, а потом "эмуляцией" браузера формируется html. но это двойная работа сервера. как вариант - html строку таблицы практически любой сложности можно сформировать в sql запросе и это не будет большой нагрузкой на sql-сервер (проверено).
повторно, по навешиванию обработчиков. - сколько их? к примеру на таблицу любых размеров достаточно 2-х обработчиков - клик и дблклик, для доступа к любой ячейки. это такого добавления никаких тормозов не будет. сколько ещё ? ну 10-15 на остальные элементы, но и это не тормоз.
а если использовать template - то и больше обрабатываемых элементов можно использовать без торможения страницы.
следовательно - (если читать вики: Гидрата́ция (от др.-греч. ὕδωρ «вода») — присоединение молекул воды  ) эти действия и есть присоединение воды, а точнее переливание из пустого в порожнее.

[mixsture]

Смотрю я на это и мне все больше кажется, что производительности скриптового языка тут уже не хватает. Да, каждый из пунктов статьи хорош, но принципиально картина поменяется только от задействования честной многопоточности. Да, это усложнит работу с общими данными, но при этом отодвинет потолок производительности в разы. Добавим еще современную тенденцию к увеличению числа ядер заметно бОльшую, чем рост производительности на ядро. Думаю, что переход хотя бы к какому-то варианту многопоточности неизбежен в контексте 20 лет.

[saege5b]

Эту тему достаточно давно жуют.
А дальше упирается в разнородность архитектур, на которых это всё безобразие крутится.

[Sigest]

Вот интересно, разность архитектур кому мешает? Многие языки уже умеют мультипоточность на всевозможных платформах, да даже тот же JS умеет, насколько я знаю. Но браузерная разработка до сих пор держится всеми клешнями в однопоток. Вот кто бы рассказал почему так происходит. Я только одну причину вижу - это заставит разработчиков ответственнее подходить к разработке, если они хотят ускорить работу своего приложения.

[Revertis]

Лет 20 назад, когда я писал на Delphi свои утилитки, мне иногда надо было во время тяжёлой обработки чего-то в цикле не блокировать работу с окном. Так я просто внутрь цикла добавлял Application.ProcessMessages();, и окно оставалось максимально отзывчивым.

Может вместо всех этих адовых планировщиков, каналов с сообщениями и так далее, надо просто сделать ручку в виде window.processInput();, которая бы любые события в своей внутренней очереди браузера обрабатывала?