@fetis26
Ну, за фронтенд!

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

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

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

Как вы решаете вопрос где можно рендерить на клиенте, где нельзя. И что конкретно выводите.
  • Вопрос задан
  • 4464 просмотра
Пригласить эксперта
Ответы на вопрос 8
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Идеальная ситуация - клиент и сервер - разные приложения. Это значит что у нас частично дублируется логика и т.д. и т.п. Так же реализация клиента усложняется а реализация сервера упрощается до простой rest api.

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

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

Я лично на Angular только web-приложения делаю. Там не нужно парится сильно с индексацией. Сайты делать на нем в большинстве случаев смысла не вижу, тут проще делать динамичными только отдельные элементы которые на самом деле этого требуют.
Ответ написан
smanioso
@smanioso
Отмечайте ответы на свои вопросы!
С точки зрения UX надо просто оптимизировать скорость загрузки, кеширование и прочие аспекты работы сайта/приложения.
С точки зрения SEO есть куча готовых решений, например https://prerender.io
Ответ написан
Комментировать
Если вы пишете на ангуляре, то рендерить что-либо на сервере в большинстве случаев не имеет смысла.

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

Так что сейчас нету особых проблем с сео таких приложений.
Ответ написан
Комментировать
amerov
@amerov
Web Developer
Сейчас можно с React рендерить на обеих сторонах.
https://github.com/enaqx/awesome-react#server-side...
https://www.youtube.com/watch?v=cKYGPGlUfc4
Ответ написан
Комментировать
@ElianL
javascript-разработчик
Сейчас активно продвигается идея изоморфных приложений, когда первая страница рендериться на сервере, а последующие на клиенте.
Тут есть два подхода, либо использовать так называемые full-stack фреймворки(на nodejs), на подобии derbyjs или meteor. Очень интересные инструменты, но привязаны к mongo. При этом подходе и сервер и клиент пишутся на JS.

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

Уже сейчас есть эксперементальные инструменты например от Ebay https://github.com/appsforartists/ambidex
Думаю скоро нас накроет волной подобных решений. И тогда подобные вопросы сами собой отпадут =)
Ответ написан
Комментировать
dmitry-polushkin
@dmitry-polushkin
Инженер программного обеспечения
Самый лучший способ использовать true isomorphic архитектуру. Рендерить на сервере, потом синхронизировать через virtual dom на клиенте. Таким образом решается сразу же несколько проблем... и даже больше, чем несколько. Как минимум:

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

Основываюсь на собственном опыте. С react.js работает всё гораздо шустрее, прозрачнее и модифицируемее.
Ответ написан
Комментировать
xeLL
@xeLL
Fullstack web developer
Ember.js будет иметь встроенную возможность рендерить на сервере emberjs.com/blog/2014/12/22/inside-fastboot-the-ro....
Ответ написан
Комментировать
@lega
Разделяйте проекты на сайты и веб-приложения (с последним думаю все понятно - одна страница, все в ней).
Но смущает, что поисковики не будут ничего видеть. Да и юзеру вроде как не комфортно, открыл страничку а там ничего, пока скрипты не отработали.
Считаю что с поисковиками проблем особо нет (phntomjs/prerenderio), а вот скорость загрузки - это существенно, поэтому я считаю что основной контент должен прилетать сразу с сервера, чтобы пользователь уже мог читать, а доп. функционал, всякие формы, кнопки, др. плюшки уже через клиентские фреймворки. Например VK, большая часть прилетает сразу, а остальное - поиск, подгрузка уже через js (хотя подгружаемые посты ренедрились на сервере).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы