Шаблоны на стороне клиента или на стороне сервера (какой?)

В последнее время я читал несколько очень интересных статей о рендеринге между клиентом и сервером в целом.

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html < / а>

http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

Я был немного фанатом, когда дело касалось стороны клиента, но после того, как я прочитал эти статьи, к моему удивлению, некоторые моменты начали проявляться в пользу рендеринга на стороне сервера ... Основные моменты были:

  • 1) Вы можете обновить свой сервер, но не свое пользовательское устройство. Это означает, что да ... вы контролируете сервер, поэтому, если он не работает вы можете выбрать обновление / масштабирование. Вы не можете заставить пользователей обновить свои устройства.

  • 2) Первая отрисовка по сравнению с последней отрисовкой - теперь по ссылке experimentally verified... выше отображается, когда пользователи впервые видят страницу (первая отрисовка) и когда пользователи могут использовать страницу на 100% (последняя отрисовка). Теперь из того, что я могу представить, когда пользователь видит страницу, его мозгу требуется некоторое время, чтобы обработать сигналы от зрительной коры до лобной коры, а затем до коры головного мозга, где пользователь фактически начинает щелкать пальцем, т. Е. конечно, если сначала отображается html, поэтому мозгу есть что обрабатывать, пока загрузка происходит в фоновом режиме (файлы js, привязка и т. д.).

Что меня действительно поразило, так это то, что твиттер сообщил, что у людей есть время загрузки до 10 секунд для рендеринга на стороне клиента, никто никогда не должен испытывать этого! Это своего рода высказывание: «Что ж, если у вас нет достаточно хорошего устройства, извините, вам просто нужно подождать.».

Я подумал, не существует ли хорошего способа использовать как клиентскую, так и серверную механизмы шаблонов, и при котором и клиент, и сервер используют один и тот же механизм шаблонов и код . В этом случае нужно только выяснить, может ли благодетель предоставить клиенту визуализированную страницу или позволить клиенту визуализировать ее самостоятельно.

В любом случае поделитесь своими мыслями о моих высказываниях и статьях, если хотите. Я весь во внимании!


person basickarl    schedule 26.03.2015    source источник
comment
Как бы мне ни было любопытно, что люди отвечают, и сколь бы увлекательной ни была эта дискуссия, это не соответствует цели SO. Это означает, что я застрял, вот что я пробовал, вот что я ожидал, почему это не сработало? вид сайта. Вы спрашиваете мнение и, возможно, лучше подходит для сообщения в блоге, где вы публикуете свое собственное мнение и спрашиваете мнение читателя.   -  person GregL    schedule 26.03.2015


Ответы (2)


UPD: делайте это, только если он вам действительно нужен

(4 года и 2 изоморфных корпоративных приложения спустя)

Если вы обязаны использовать SSR, прекрасно. Если вы можете пойти с простым SPA - сделайте это.

Почему так? SPA легче разрабатывать, проще отлаживать, дешевле и проще в эксплуатации.

Сложности разработки и отладки очевидны. Но что я имею в виду под «дешевле и проще в эксплуатации»? Ну, угадайте, что, если 10K пользователей попытаются открыть ваше приложение одновременно с вашим статическим HTML-сайтом (то есть встроенным SPA), вы этого даже не почувствуете. Однако, если вы используете изоморфное веб-приложение, TTFB увеличится, использование ОЗУ увеличится, и в конечном итоге вам придется запустить их кластер.

Поэтому, если вам не требуется показывать сверхнизкое время TTFB (которое, вероятно, будет происходить из-за агрессивного кеширования), не усложняйте свою жизнь.

Оригинальный ответ от 2015 года:

По сути, вы ищете изоморфное веб-приложение, которое использует один и тот же код для внешнего и внутреннего интерфейса.

Изоморфный JavaScript

Приложения JavaScript, которые работают как на стороне клиента, так и на стороне сервера. Изоморфные фреймворки JavaScript - это следующий шаг в эволюции фреймворков JavaScript. Эти новые библиотеки и фреймворки решают проблемы, связанные с традиционными фреймворками JavaScript.

Готов поспорить, этот парень объясняет это намного лучше, чем я.

введите описание изображения здесь

Итак, когда пользователь заходит на страницу, сервер отображает полную страницу с содержимым. Таким образом, он загружается быстрее и не требует дополнительных запросов ajax для загрузки данных и т. Д. Затем, когда пользователь переходит на другую страницу, используются обычные методы для одностраничных приложений.

Итак, ПОЧЕМУ МНЕ БЫЛО ЗАБОТИТЬСЯ?

  • Старые браузеры / Слабые устройства / Отключенный Javascript
  • SEO
  • Некоторые улучшения загрузки страницы

Старые браузеры / Слабые устройства / Отключенный Javascript

Например, IE9 не поддерживает History API. Итак, для старых браузеров (и если пользователь также отключит javascript), они будут просто перемещаться по страницам, как в старые добрые времена.

SEO

Google утверждает, что поддерживает SPA, но вряд ли появляются в топе результатов поиска Google?

Скорость страницы

Как было сказано, первая страница загружается одним HTTP-запросом, и все.

OK, so

Об этом много статей:

Но ДОЛЖЕН ЛИ Я ЗАБОТИТЬСЯ?

Конечно, решать вам.

Да, это круто, но чтобы переписать / адаптировать существующее приложение, потребуется много работы. И если ваш бэкэнд находится в PHP / Ruby / Python / Java / любом другом, у меня для вас плохие новости (это не обязательно невозможно, но близко к этому).

Это зависит от веб-сайта, вы можете попытаться собрать некоторую статистику, и если процент пользователей со старыми устройствами невелик, это не стоит проблем, так почему бы и нет ...

ПОЗВОЛЬТЕ ИМ СТРАДАТЬ

Если вас интересуют только пользователи со старыми устройствами, то давайте, это 2015 год, и это проблема вашего пользователя, если он использует IE8 для просмотра веб-сайтов с iPod Touch 2. Например, Angular отказался от поддержки IE8 в версии 1.3 примерно год назад, так почему бы вам просто не предупредить пользователей, что им нужно обновить;)

Ваше здоровье!

person Alexander Mikhalchenko    schedule 22.11.2015
comment
Сейчас 2017 год. Webpack правит миром. встряхивание дерева и объединение кода в chunks являются важными частями создания пользовательского интерфейса. Плюс компиляция с опережением времени (AOT). Компиляция на стороне сервера становится менее привлекательной. ИМХО, SEO - главный аргумент. Это единственный аргумент? ... - person Alex Klaus; 21.06.2017

Все разговоры на эту тему упускают один момент. Байты отправлены клиенту. Страницы, отображаемые на сервере как HTML, намного меньше. Меньше передаваемых байтов лучше для всех, как для сервера, так и для клиента. Я видел затраты на полосу пропускания на облачных сайтах, и даже 10% сокращение может быть огромной экономией. JS-страницы на стороне клиента всегда толстые.

person Experienced Programmer    schedule 22.04.2016