В этом посте я хочу в первую очередь взглянуть на SSR и STR (статический рендеринг), поместив эти методы в более широкий контекст ландшафта веб-разработчиков, а затем сравнив и сопоставив их с CSR (рендеринг на стороне клиента).

Клиентская сторона + статический рендеринг - история двух крайностей

Немного истории

Я начал веб-разработку в 2010 году, в условиях, когда Javascript начал доминировать в сети, и большинство новых веб-сайтов прилагали согласованные усилия, чтобы переместить свои веб-сайты с традиционных веб-платформ и языков и использовать JS для получения все большего количества функций. своих сайтов.

Одной из этих функций было отображение содержимого их приложений (HTML и текст) с использованием Javascript. Предыдущее поколение веб-сайтов было написано в основном на программном обеспечении, таком как PHP (который поддерживает wordpress) или ASP.NET (платформа разработки программного обеспечения Microsoft), которые почти, если не полностью, визуализировались на стороне сервера, а затем передавались клиенту на время выполнения.

JS-приложения «будущего» обещали быть более отзывчивыми, потому что они несли большую часть состояния приложения во внешнем интерфейсе, позволяя веб-сайту быстрее и плавнее реагировать на изменения, вносимые пользователями. Клиентам не нужно было отправлять полные запросы на сервер, если они хотели обновить только небольшую часть страницы. Например, в 2010 году меня даже не учили разнице между этими двумя методами, потому что предполагалось, что приложения с рендерингом на стороне клиента (CSR) - это путь будущего.

Теперь, в 2020 году, наблюдается серьезный откат в другом направлении, когда компании и разработчики начинают более критически относиться к тому, какой шаблон рендеринга работает для них лучше всего, глобально или для определенных сегментов + страниц своего сайта - и веб-фреймворки, особенно Javascript, пытаются дать разработчикам больше свободы выбора в отношении того, какие из этих методов они хотели бы использовать для создания своих веб-приложений.

Понятия и определения

CSR: это означает рендеринг на стороне клиента, и именно здесь многие компании сейчас занимаются веб-разработкой. Это когда ответ на веб-запрос пользователя на вашем сервере - это просто пустой документ HTML и гигантский набор JS. Выполняется JS, который выполняет обратные вызовы API на сервер или другие источники данных, заполняет вашу страницу разметкой, стилями и данными, которые необходимы вашему приложению. Ожидается, что этот метод намного медленнее с точки зрения пользователей, чем другие методы рендеринга - их собственный компьютер выполняет все запросы данных. С другой стороны, преимущество этого метода заключается в том, что он позволяет загружать состояние приложения на клиентском компьютере, что ускоряет последующее взаимодействие со страницей. Вы увидите CSR, описанный в литературе как SPA (одностраничное приложение ), поскольку приложение CSR может даже не отправлять запросы на сервер, пока пользователь просматривает URL-адреса.

STR: это «статический рендеринг», противоположный методу CSR, который я описал выше. Это когда ваш сервер настроен на отправку полностью автономного пакета HTML, JS и CSS обратно клиенту. Это означает, что эта страница была полностью отрисована и готова к запуску ДО того, как был сделан запрос. Это невероятно быстро по сравнению с CSR, поэтому желательно, если это возможно. Однако это будет работать только для контента, который не зависит (или почти не зависит) от пользовательских данных (целевая страница, которая показывает один и тот же контент всем, кто ее посещает, будет отличной страницей для статической визуализации).

SSR: это «рендеринг на стороне сервера», и это более классический метод, используемый такими фреймворками, как ASP.NET и PHP. Это баланс между STR и CSR, больше склоняющийся к STR, чем к первому. Когда ваше приложение запрашивает страницу с сервера, сервер фактически делает запрос к источнику данных, а затем полностью отображает страницу перед возвратом каждого запроса. Это отличается от статического рендеринга, потому что запрос данных выполняется ВО ВРЕМЯ ЗАПРОСА. На изображении ниже сравниваются и противопоставляются SSR и STR.

Что мне использовать сейчас?

Ответ, как всегда, зависит от обстоятельств.

Если возможно, вы хотите предварительно загрузить как можно большую часть рендеринга вашей веб-страницы, переходя от SSR к STR, когда это возможно, и вам нужно будет масштабировать это обратно, поскольку контент, с которым вы работаете, фактически становится больше динамичный и сложный.

Если возможен статический рендеринг, это ВСЕГДА самый быстрый путь, хотя он не будет работать, если у вас есть контент, который очень динамичен или изменяется очень часто. SSR по-прежнему быстрее, чем CSR, очень силен, когда дело доходит до SEO, и способен обрабатывать динамический контент. CSR, как правило, не рекомендуется, хотя он может быть очень полезен, если у вас невероятно динамичная веб-страница, например, карты Google.

Спасибо, что прочитали, надеюсь, что это было ценным, и хорошо проводите время кодирование в карантине.

PS: Недавно у меня была возможность сделать перерыв в моей карьере с 9 до 5 и сосредоточиться на изучении некоторых новых технологий, которые появились недавно. Я заметил несколько основных тенденций:

  1. Статические и / или отрисованные на стороне сервера приложения
  2. Более крупномасштабные фреймворки для создания приложений Javascript с более самоуверенной архитектурой.
  3. GraphQL и альтернативные протоколы запросов к REST (например, GROQ)
  4. Возникновение Vue.js как альтернативного фреймворка уровня представления
  5. Рост стека JAM и инструментов для его решения
  6. Новые и более простые процессы развертывания, которые абстрагируют большую часть работы, которая классически выпадала бы на арену «разработчиков».
  7. "Безголовые" CMS

Я начинаю серию статей, посвященных этим новым тенденциям во Front-end разработке. Не стесняйтесь делиться со мной мнениями о том, что писать дальше, я с нетерпением жду их всех вместе с вами в ближайшее время!