Comments 19
UFO just landed and posted this here
В первом варианте страница первоначально генерируется сервером, при каждом запросе на обновление от клиента в ответ приходят данные, с помощью которых javascript должен сгенерировать некоторый html и встроить его в страницу. Получается, генерация html будет происходить и на стороне сервера(построение изначальной страницы), и на стороне клиента(response клиентской части на обновление от сервера).
Вариант 4
Изоморфные фреймворки
Очень много таковых появилось для NodeJS. При первом запросе компоненты генерируются на сервере, в браузере происходит лишь инициализация компонент, далее компоненты могут отсылать/запрашивать данные, и обновлять себя, и рендерить другие компоненты.
Изоморфные фреймворки
Очень много таковых появилось для NodeJS. При первом запросе компоненты генерируются на сервере, в браузере происходит лишь инициализация компонент, далее компоненты могут отсылать/запрашивать данные, и обновлять себя, и рендерить другие компоненты.
интересно. не подскажете какую-нибудь статью по теме, чтобы ознакомиться?
Может на статью хорошую кто и укажет, дам пару ссылок на фреймворки: Derby, Meteor, React тоже можно запускать и рендерить на ноде. Ну и мы тоже немного разрабатываем такой подход: MaskJS, в целом это фронтэнд фреймворк, но также есть модуль который те же компоненты рендерит на ноде, а далее в браузере восстанавливает компоненты, как если бы они рендерелись на клиенте. Может немного запутано, но можно посмотреть несколько примеров в репозитории: Mask.Node
добавлю ещё bnsf на БЭМ стеке:
github.com/apsavin/bnsf
github.com/apsavin/bnsf
ИМХО, то, что ваш сервер в одном ответе возвращает разнородные данные (подписчики и новости) уже неправильно.
Да и пункты у вас по сути не отличаются. Ответ с сервера и обработка Javascript.
Разница только в том, кто оборачивает ответ в HTML, сервер или клиент — вставляет в любом случае JS.
Да и пункты у вас по сути не отличаются. Ответ с сервера и обработка Javascript.
Разница только в том, кто оборачивает ответ в HTML, сервер или клиент — вставляет в любом случае JS.
Разнородные данные — только для примера, надеюсь, я никого не побудил так весело реализовывать передачу данных в настоящем проекте :)
А по второму пункту — мне как раз было интересно, как и чем лучше оборачивать в html, в этом и есть смысл публикации.
А по второму пункту — мне как раз было интересно, как и чем лучше оборачивать в html, в этом и есть смысл публикации.
Лучше вообще не оборачивать, по крайней мере руками. Почитайте про data binding. По сути все тот же «всемогущий javascript», но сильно упрощает и ускоряет разработку.
Простите, но я снова БЭМ вставлю. Очень хороши их декларативные шаблонизаторы bh и связка bemtree+bemhtml. Рендерятся также универсально в браузере или nodejs.
Это называется sideloading.
В своих проектах я использовал вперемешку сразу все три варианта с небольшими отличиями)
Смесь вариантов 1 + 2а удобна тогда, когда надо сначала сгенерировать HTML, который увидят в том числе и поисковые роботы, а после этого динамично обновлять это содержимое через получение событий-команд с сервера примерно в таком же формате, как в варианте 2а. Получили команду — обновили изначально сгенерированный DOM.
Вариант 2 удобен для быстрого и динамичного перехода между страницами сайта, т.е. для аякс-навигации. Я тоже как-то пытался использовать его именно в таком виде, в каком он описан в статье: через передачу данных в формате JSON, но на практике это оказалось слишком затратно: браузеру приходилось сначала спарсить огромную JSON-строку и потом еще рендерить на основе этих данных новую страницу. Короче, браузер даже на глаз тормозил на компьютерах средней мощности, и чем больше страница, тем больше тормозов. Итого, мы тогда пришли к более простому варианту: сервер стал отправлять чистый HTML, который потом просто заменял содержимое центрального контейнера с основным контентом страницы, и плюс в конец страницы добавлялось несколько JS-команд, через которые заменялся заголовок страницы и какая-то другая мета-информация.
Поздравляю, вы почти изобрели React!
facebook.github.io/react/docs/reconciliation.html
facebook.github.io/react/docs/reconciliation.html
В последнем варианте к минусам можно дописать возможные проблемы индексирования поисковыми машинами таких страниц, не все роботы еще умеют выполнять клиентский JS.
В копилку изоморфных фреймворков: CatBerry.
Из фишек, прогрессивный рендеринг — клиенту начинает отправляться html как можно быстрее. Таким образом браузер может уже работать с head, когда последний блок на странице еще не сгенерирован сервером. (Минус этой фичи: код ответа сервера всегда строго 200)
Из фишек, прогрессивный рендеринг — клиенту начинает отправляться html как можно быстрее. Таким образом браузер может уже работать с head, когда последний блок на странице еще не сгенерирован сервером. (Минус этой фичи: код ответа сервера всегда строго 200)
Веб-приложение всегда должно использовать только метод 3. Более того, должно быть хорошо задокументированное API.
Веб-сайт может использовать все, что угодно, но лучше конечно прийти к методу 3, но без «дублирования», т.е. структура страницы и основной контент создаются сервером (для поисковиков и пр. урезанных клиентов), а динамический контент подгружается из API.
Веб-сайт может использовать все, что угодно, но лучше конечно прийти к методу 3, но без «дублирования», т.е. структура страницы и основной контент создаются сервером (для поисковиков и пр. урезанных клиентов), а динамический контент подгружается из API.
Ну, дублирование — это не DRY. Толстые ответы с рендерингом всей страницы — а зачем тогда Ajax? Вы через turbolinks получите примерно похожее.
Даже не знаю, второй подход — это как в рельсах писать все запросы на SQL, когда есть ActiveRecord. Неоправданно, в общем.
Третий — то, для чего эти запросы и нужны, собственно, обмен JSONами с сервером, быстро и эффективно, и обновление информации real-time, с различными красивыми fadeIn и прочим.
Первый случай еще имеет место быть, но только в одном случае — когда это реально экономит вам время и деньги. Второй — просто не стоит биндить рендер страницы на один эвент.
P.s — простите за русско-английский, с телефона не торт писать.
Даже не знаю, второй подход — это как в рельсах писать все запросы на SQL, когда есть ActiveRecord. Неоправданно, в общем.
Третий — то, для чего эти запросы и нужны, собственно, обмен JSONами с сервером, быстро и эффективно, и обновление информации real-time, с различными красивыми fadeIn и прочим.
Первый случай еще имеет место быть, но только в одном случае — когда это реально экономит вам время и деньги. Второй — просто не стоит биндить рендер страницы на один эвент.
P.s — простите за русско-английский, с телефона не торт писать.
Минусы подхода:
> Высокая нагрузка на компьютер пользователя;
С современными браузерами нагрузка не такая высокая.
> Возможна избыточность — часть знаний клиентской части об отображении может так и остаться невостребованной, если какие-то события не наступят;
Не надо просто грузить все скрипты сразу. Загружать нужно только то, что необходимо для отрисовки.
Самый настоящий минус в 3-ем подходе — это необходимость доработки сайта для индексации в поисковиках.
> Высокая нагрузка на компьютер пользователя;
С современными браузерами нагрузка не такая высокая.
> Возможна избыточность — часть знаний клиентской части об отображении может так и остаться невостребованной, если какие-то события не наступят;
Не надо просто грузить все скрипты сразу. Загружать нужно только то, что необходимо для отрисовки.
Самый настоящий минус в 3-ем подходе — это необходимость доработки сайта для индексации в поисковиках.
Sign up to leave a comment.
Динамическое обновление веб-страницы