Насколько широко сейчас можно применять рендер на клиенте?

Question

[fetis26]

Никак не могу провести границу. Современные фреймворки дают широкие возможности для клиентского рендера. Вроде как можно все это дело вообще с сервера убрать или сильно минимизировать.

Но смущает, что поисковики не будут ничего видеть. Да и юзеру вроде как не комфортно, открыл страничку а там ничего, пока скрипты не отработали. Если пишем какую-то закрытую систему, то такие вопросы вроде как неактуальны. А если делаем общедоступный сайт? Или что-то вроде личного кабинета, для такого сайта.

Как вы решаете вопрос где можно рендерить на клиенте, где нельзя. И что конкретно выводите.

Comments

[Yustas Alexu]

Чтобы не иметь проблемы с SEO, лучше вообще оставить все эти ангуляры и прочие и рендерить по старому на серваке.

[Сергей Протько]

Uxus Greenwood: Как-то уж сильно консервативно...

[Дмитрий Полушкин]

В последних проектах использовал react.js для рендеринга на сервере, при открытии клиентом отрендеренного контента синхронизировался ещё раз (virtual dom же), таким образом получается что вёрстка в процессе "ререндеринга" не меняется... т.е. и поисковики довольны, и клиенты (они получают в начале версию без JS, потом накладывается JS после ререндеринга).

Answer 1

[Сергей Протько]

Идеальная ситуация - клиент и сервер - разные приложения. Это значит что у нас частично дублируется логика и т.д. и т.п. Так же реализация клиента усложняется а реализация сервера упрощается до простой rest api.

По поводу грани - ее выставляете вы. Просто оцените по времени, сколько вам будет по времени занимать проект какой-нибудь с классическим подходом и на том же AngularJS. Например бложик написать, обычный такой бложик. По сути тут нет никакой логики. Сервер может просто закешировать и отдавать HTML. Нет смысла делать динамические переходы так как 95% страницы всеравно заменится, да и происходит это не часто.

Что до поисковиков - это так же добавляет хлопот. либо подключать сервисы типа prerender.io либо реализовывать что-то подобное на базе phantom.js

Я лично на Angular только web-приложения делаю. Там не нужно парится сильно с индексацией. Сайты делать на нем в большинстве случаев смысла не вижу, тут проще делать динамичными только отдельные элементы которые на самом деле этого требуют.

Comments

[fetis26]

Ок, а как вы определяете что веб-приложение, а что нет. По наличию Single Page Application?

Answer 2

[smanioso]

С точки зрения UX надо просто оптимизировать скорость загрузки, кеширование и прочие аспекты работы сайта/приложения.
С точки зрения SEO есть куча готовых решений, например https://prerender.io

Answer 3

[Никита Гущин]

Если вы пишете на ангуляре, то рендерить что-либо на сервере в большинстве случаев не имеет смысла.

Что касается сео - я сам интересовался некоторое время назад, посмотрите тут: Индексация сайта при использовании AngularJS

Так что сейчас нету особых проблем с сео таких приложений.

Answer 4

[Marat Amerov]

Сейчас можно с React рендерить на обеих сторонах.
https://github.com/enaqx/awesome-react#server-side...
https://www.youtube.com/watch?v=cKYGPGlUfc4

Answer 5

[Илья Агарков]

Сейчас активно продвигается идея изоморфных приложений, когда первая страница рендериться на сервере, а последующие на клиенте.
Тут есть два подхода, либо использовать так называемые full-stack фреймворки(на nodejs), на подобии derbyjs или meteor. Очень интересные инструменты, но привязаны к mongo. При этом подходе и сервер и клиент пишутся на JS.

Второй подход заключается в том, что у нас есть сервер с которым мы работаем по API(пишите на чем хотите), а фронтэенд имеет скажем так прослойку на nodejs.
С появлением ReactJS рендерит одну и туже страницу на сервере и на клиенте стало очень просто.

Уже сейчас есть эксперементальные инструменты например от Ebay https://github.com/appsforartists/ambidex
Думаю скоро нас накроет волной подобных решений. И тогда подобные вопросы сами собой отпадут =)

Answer 6

[Дмитрий Полушкин]

Самый лучший способ использовать true isomorphic архитектуру. Рендерить на сервере, потом синхронизировать через virtual dom на клиенте. Таким образом решается сразу же несколько проблем... и даже больше, чем несколько. Как минимум:

- Быстрая загрузка страниц для клиента
- Быстрая загрузка страниц для поисковиков
- Шаринг кода между клиентом и сервером
- С React.js ещё и ускорение разработки, т.к. тестирование занимает меньшее время, да и побочных эффектов гораздо меньше, чем при использовании binding-ов.

Основываюсь на собственном опыте. С react.js работает всё гораздо шустрее, прозрачнее и модифицируемее.

Answer 7

[Pavel Demyanenko]

Ember.js будет иметь встроенную возможность рендерить на сервере emberjs.com/blog/2014/12/22/inside-fastboot-the-ro....

Answer 8

[lega]

Разделяйте проекты на сайты и веб-приложения (с последним думаю все понятно - одна страница, все в ней).

Но смущает, что поисковики не будут ничего видеть. Да и юзеру вроде как не комфортно, открыл страничку а там ничего, пока скрипты не отработали.

Считаю что с поисковиками проблем особо нет (phntomjs/prerenderio), а вот скорость загрузки - это существенно, поэтому я считаю что основной контент должен прилетать сразу с сервера, чтобы пользователь уже мог читать, а доп. функционал, всякие формы, кнопки, др. плюшки уже через клиентские фреймворки. Например VK, большая часть прилетает сразу, а остальное - поиск, подгрузка уже через js (хотя подгружаемые посты ренедрились на сервере).