Comments 13
Много опечаток в тексте. Если такое небрежное отношение к своей публикации, то и в остальных деталях оно будет проявляться. В том числе и по предметной области. Кстати говоря, по существу вопроса, ничего особо нового. Можно было не переводить тексты, а просто сбросить ссылку на википедию или документацию одного из фреймворков. Более того это уже мода какая-то прятаться за переводами, что-то вроде, — Если перевести любой текст, то и претензий нет. Не я же писал. Это он, я лишь перевёл. Вот и рвутся все переводить, что попало. Но среди иностранщины более чем много посредственного материала.
<form>
<label for="fname">First name:</label><br>
<input type="text" id="fname" name="fname"><br>
<label for="lname">Last name:</label><br>
<input type="text" id="lname" name="lname">
<input type="submit" value="Submit">
</form> А какие показатели FCP и FIP для такого веб-приложения? Неужели vue, angular и react настолько медленные, что проигрывают старому HTML 4 тысяча-девятьсот-какого-то года разработки?
Слушайте, проблема производительности гидратации не в том, что она плохо влияет на метрики. А в том, что популярные Фреймворки в упор не видят проблемы и не пытаются ее решить, предлагая костыльные решение в виде ленивой гидратации, которая также не решает проблему на 100%. Если ставить вопрос глобально, то jquery работает все равно быстрей, чем реакт. И дело именно в том, как ядро реакта написано.
Если интересно, посмотрите мою статью, я там разобрал вопрос производительности и добился очень хороший цифр при этом без ущерба функционалу.
И в оригинале статьи были мало того, ошибочные определения, которые пришлось заменять информацией из других источников. Также, там было только одно предложения с two pass rendering в react: использование hydrate() и render() методов библиотеки.
Цель статьи в понимании процесса, который стоит за этим термином. Оптимизация и производительность, как следующий шаг, который является хорошей темой новых статьей.
И немного про jq, его не любят не за то что он устарел, а за то, что благодаря своей простоте использования вырастил поколение «фронтендеров», которые пихают даже в пример выше с формой фреймворк и на каждый чих грузят «ещё один плагин» и при этом «лапша» что при нем, что в современных фреймворках.
Разве современным поисковикам не все равно, на клиенте или на сервере рендерится страница?
Если все равно, то гидратататация не просто костыль, но еще и на 90% бесполезный костыль.
Так же, стоит упомянуть то, что SSR положительно влияет на рендеринг, делая его не только быстрым, но и стабильным, т.к., в случае CSR, рендер происходит за счет мощностей клиента и, если на мощном компьютере все будет хорошо, то вот на слабеньком телефоне все может быть очень плохо.
Еще мысль: hydration с точки зрения задержки time to interactive — это как https://youtu.be/uRGljemfwUE (смотреть с 7:50)
SPA — делать по человечески, с клиентским рендерингом и без ssr-костылей.
SEO-странички — делать классическим способом, т.е. генерацией серверных шаблонов на бекенде.
Как правило, весь богатый ui функционал (всякие личные кабинеты, дашборды) спрятан за страничкой авторизации. Этот богатый ui-функционал, т.е. сам продукт, и не должен индексироваться.
А вот сама страничка входа/авторизации, какие-то начальные странички/лендинги на основном сайте, которые описывают/рекламируют сам продукт, как раз таки должны индексироваться. Вот их можно делать на серверных шаблонах с jquery.
Что, черт возьми, такое гидратация и регидратация?